Use cases
A use case is a written description of a users task within a (digital) product. A use case is written from the users perspective. All use cases of one product combined describe the entire functionality of that product. You should write use cases to map (all) the desired actions, before designing flows or screens. Use cases, like personas or storyboards, are a method to keep the design process user centred. Use cases can be used as a starting point for designing use flows.
How to
For each use case
- Choose one of the users of the product you have identified earlier.
- Define the task the user wants to execute with the product. Each task should be written as a separate use case.
- Write out the basic steps the user has to perform to complete the task. Describe what the user does and how the system responds.(But no screen-details yet.)
- Expand the use case by adding alternate steps the user might have to take to complete the task.
Repeat 1-4 until all tasks for all users are described.
Tips
- Use cases can be written as a ‘basic flow’ with exceptions. In this way you don’t have to write an entire use case for every exception flow.
- Use cases in themselves do not say anything about what will be built and in what order. You can use a scope session (e.g.) to negotiate about scope with your stakeholders.
- The difference between use cases and user stories. User stories are mainly used for planning in Scrum processes. Anytime a change needs to be made, a new user story is written. So the total of user stories does not describe the entire product. However, use cases describe all functionalities of a product, without a planning hierarchy.
- Use cases do not describe one action, but a sequence of steps to complete a task.
- Use cases do not describe the solution (how will the product solve the task) but the requirements (what task should be solved with the product).