Use Cases: Complete Scenarios of Interaction With the System
A use case describes step by step how an actor reaches a goal with the system, with its alternate flows. What it contains, how to write one, and when to use it.
What is a use case?
It is a document that describes a complete interaction. Its central piece is the main flow, the sequence of steps where everything goes right. Around that flow you write the conditions that must hold before starting, the results left afterwards, and the exceptions.
The format comes from software engineering, but it is useful in product design when there are many possible paths. The classic reference is Alistair Cockburn’s Writing Effective Use Cases (2001). A typical specification includes a brief description, the main flow, alternate flows, preconditions, and postconditions, following the RUP template (RUP, “Use Case Specification”).
What does a good use case contain?
A practical template for product work usually includes:
- ID and name. A verb and an object: “Pay a bill”.
- Actors. The primary actor, who pursues the goal, and any secondary ones, such as a payment service.
- Trigger. What starts the case: a click, a date, an incoming message.
- Preconditions. What must be true before starting: the user is signed in, has a saved card.
- Main flow. The sequence of steps where everything goes right, written as a dialogue between actor and system.
- Alternate flows. The paths that depart from the main one.
- Postconditions. What remains at the end: the bill is marked as paid, an email is sent.
The RUP template also adds special requirements (for example performance or accessibility) and extension points. Visual Paradigm uses a “Place Order” example with the precondition “User is logged in”, a five-step main flow, and the postcondition “Order is placed successfully” (Visual Paradigm, “Use Case Guide”).
Why should a designer care?
Because most of the value of a use case sits in the alternate flows. Everyone knows the happy path. What gets forgotten is the declined payment, the session that expires halfway through a form, or the user who doesn’t have the data we asked for.
Featurebase puts it well: a user story is brief and focuses on the outcome, while a use case is detailed and covers variants and errors (Featurebase, “Use case vs user story”). That difference matters when someone has to implement or test the behavior.
| User story | Use case | |
|---|---|---|
| Level of detail | High-level overview focused on the outcome | Step-by-step interactions between user and system |
| Covers | The main success scenario | Happy path, alternatives, and errors |
| Useful for | Planning and prioritizing | Documenting, implementing, and testing complex behavior |
Writing a use case also forces you to name the actor and the precondition. Many screens that looked obvious turn out to be different cases once someone writes down who does what and in which state.
How do you write alternate flows?
The RUP template says simple alternatives can be written inside the flow of events, and complex ones deserve their own subsection. It also states that when an alternate flow ends, the main flow resumes unless stated otherwise (RUP, “Use Case Specification”).
In practice, ask at every step of the main flow: what could the actor do here that is not expected? What could fail? Each answer is an alternate flow, with its own ending.
Example
Illustrative example: a “Pay a bill” use case in a banking app. The main flow has five steps: choose the bill, confirm the amount, select the account, authorize with fingerprint, and see the receipt. There are three alternate flows: insufficient balance (the system offers another account or cancel), fingerprint not recognized (the PIN is requested), and a payment that takes longer than ten seconds (the screen shows “in progress” and notifies when it finishes). With that written down, the designer knows the feature needs four error screens, an intermediate state, and a later notification. None of that appeared in the happy-path mockup.
When NOT to use them
- For a simple product or a small feature. A three-step use case is paperwork. A user story or a sketch is enough.
- When the team won’t read them. A document nobody consults goes stale without anyone noticing.
- As a substitute for research. A use case describes how something should happen, not how it does happen. Validate it with user interviews or observation.
- To describe the interface. A use case says what happens, not how it looks. For that, use wireframes and user flows.
Common mistakes
- Writing the main flow with interface details: “the user clicks the blue button”.
- Forgetting preconditions, such as the user being signed in.
- Leaving alternate flows without an ending: not saying how the case returns or how it finishes.
- Creating one case per screen instead of one per user goal.
- Updating the mockup but not the use case, or the other way around.
How to start tomorrow
Pick a task in your product that involves payments, permissions, or long forms, where mistakes are costly. Write the main flow in six steps at most, as a dialogue: “The user chooses…”, “The system shows…”. Then walk through each step and note what could go wrong. That list gives you the alternate flows. If the same task also needs a story for planning, the job stories format helps you understand the situation before you describe the behavior.