The term “use case” is a common source of misunderstanding because it is often used to mean different things. Sometimes people use it to describe:
- a stakeholder’s high-level goal
- a step by step description of system action
- the flow of how users interact with a system
If a team talks about use cases and everyone means the same kind of use case, it is a great opportunity to make sure the team designs and develops the right software for the right people. As designers and users researchers, we usually mean the third kind, i.e. the flow of how users interact with a system. These use cases are in a plain written format that can be understood by everyone in the product team. The use case should neither be written on a level too high, nor on a level too low. It is written on the “action-level” of the user, from a user’s perspective and describes the ideal interaction between a user and a system. If you are writing a use case for a leave request system, for example, you would title your use case “booking vacation days” instead of “decide to go on vacation” or “determine number of vacation days”. The user and the system would both be included in the use case as well as any additional people involved, such as a manager who has to approve the leave request. Use cases should always be based on user research results and existing knowledge within the team; they should include innovative ideas. Failures or consequences when the use case goal is not achieved can also be captured.
There are several notation styles for use cases (e.g. diagram style, unified modeling language, text format). Whatever notation is used should be easy to understand. You can use templates, like the ones from Alistair Cockburn, but it is also an option to use what fits best for your team, since you need to work with it.
Who benefits from use cases? – Just about everyone.
- Product owners – who need to develop requirements and document what the system is going to do
- User interface designers – who need to understand the users’ goals and how they will use the system to achieve these goals
- Developers – who need to understand what the system needs to do in order to develop it
- Technical writers – who need to know what the system is supposed to do so that they can describe it and document how the system is used
- Pre-sales employees– who need to create customer demos
- Project managers – who need to have an overall understanding of what the system will do in order to effectively plan and monitor the project
- Customers – who need to be sure that the system that is getting built is the one they want
Use cases are a communication tool and just about everyone benefits from them, so do not hesitate but try it out in your next project.