A use case describes how an actor interacts with a system to achieve a goal, including the system’s responses and relevant alternative outcomes. It helps teams discuss functional behavior in a specific context.
A play script names the characters, their goal, and what happens as each person acts. A use case similarly lays out an interaction without prescribing every visual detail.
Name the actor and goal
An actor may be a person, another service, or a role that interacts with the system. State the outcome they want and the conditions that start the interaction. Keep the use case focused enough that its success and boundaries can be understood.
Describe the main and alternate flows
Write the steps as an exchange between actor actions and system responses. Include relevant alternatives such as invalid information, unavailable service, or cancellation. These flows expose requirements that a single success path can miss and help teams decide what needs explicit handling.
Keep scope and assumptions visible
Note prerequisites, permissions, data, and what happens after the use case ends. Avoid embedding unsupported assumptions about every user’s behavior. If multiple roles or goals differ, separate them where that improves clarity instead of creating one long scenario that hides important distinctions.
Connect use cases to design and verification
Use cases can inform interface flows, acceptance criteria, and tests, but they do not define the visual design by themselves. Check whether the experience supports the goal for different people and devices. A complete written scenario is not proof that the implemented system is usable or reliable.
Frequently asked questions
Key takeaways
- Describe an actor, goal, and starting conditions.
- Include system responses and meaningful alternate flows.
- Make assumptions, permissions, and scope explicit.
- Use cases inform design and tests but do not replace evaluation.