When we design an interface, it is tempting to describe only the "happy path" — the sequence of steps a cooperative user takes when everything works. Real systems are messier. Users lose network connection halfway through a form, enter names with apostrophes or characters your field rejects, switch languages, use a screen reader, hold the phone in one hand on a moving bus, or abandon a task and return three days later. Enumerating usage paths means systematically walking through a feature and listing every branch it can take, including the rare, boundary, and failure branches that we call edge cases.
This topic builds directly on the use case scenarios you have been writing. A use case set is only as good as its coverage: if an important path is never written down, it will never be designed for, never be tested, and will surface as a defect or a frustrated user. You will practice techniques for generating paths (varying inputs, states, sequences, interruptions, and contexts), for considering user diversity (ability, expertise, language, device, environment), for recording how often each path occurs and how much it matters, and for reviewing a set to judge whether it is reasonably complete.
The videos below approach this from three angles. As you watch, look for: how designers discover paths they did not anticipate (by talking to and observing real users), how a use case diagram makes alternate and exceptional flows visible as explicit structure, and how the needs you uncover get sorted into functional versus non-functional requirements — because many edge cases (performance under poor connectivity, accessibility, error recovery) land on the non-functional side of that line.
A short lesson from Google's UX Design Certificate on why edge cases deserve attention, built around the idea that what you expect users to do with an app is often not what they actually do. It frames edge cases as situations outside the anticipated flow and points to meeting with and observing real users as the way to surface them. Expect concrete framing and examples rather than a formal process.
It is the most direct match for the "What Are Edge Cases?" subtopic, and it comes from a widely used professional UX curriculum, so the vocabulary matches what you will encounter in industry.
A compact lecture distinguishing functional requirements (what the system must do) from non-functional requirements (qualities such as performance, reliability, usability, and security), with examples of each. It is presented in a classroom style aimed at exam and interview preparation, so definitions are stated crisply and contrasted side by side.
Edge cases frequently turn into non-functional requirements, so this video gives you the classification vocabulary needed to document what you find rather than letting it disappear into informal notes.
A thorough tutorial on UML use case diagrams covering actors, use cases, system boundaries, and the relationships between them, including how to represent extensions and included behavior. Lucid Software's walkthrough is aimed at both beginners and intermediate modelers and demonstrates building a diagram step by step.
Use case diagrams give you a visual structure for enumerating paths and attaching alternate and exceptional flows to a base case, which supports both the enumeration techniques and the completeness-review subtopics.
Together these videos extend your ability to compose complete, context-aware use case scenarios (MO1) by pushing past the happy path into alternate and exceptional flows, and by giving you a diagramming notation for organizing those flows. The Google UX video reinforces the observation and user-interview techniques from MO2 as the practical means of discovering paths you would not have imagined at your desk. The functional versus non-functional lecture supplies the classification scheme from MO3, so that the edge cases and context variations you uncover can be written down as properly categorized interface requirements rather than loose observations.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.