Why are use cases useful for the design of interactions? This is a question that often comes up in a discussion, training or workshop among people that represent various roles, have diverse educational backgrounds, working styles or simply share different experiences.
Perhaps the biggest advantage of the design phase, as a process step during a product’s development lifecycle, is that it produces a visible, concrete outcome, based on the scattered pieces of information, requirements, needs or pain-points of a user that could constitute a solution. Until this stage, this information might be only in the minds of each stakeholder, and by looking at a design everyone gets on the same page at a glance, since it bridges the various perceptions of how the solution might look like in the end.
Alternatively, this might convey the feeling that the team is close to the final result, which would be a programmable user interface. In my experience, this is usually the tricky part. People tend to want a visualization of a design at the earliest possible moment (even before finishing the collection of all the user requirements). This desire is often accompanied by statements mostly expressed by the product team like, “The development starts in a month. I don’t have time to create a use case. I need to deliver,” “I know what I want to build, just draw it for me,” or “My use cases are simple. I don’t need to write them down now. I’ll do it later.”
However, by definition (see also Carolin’s article), use cases should drive the design and not follow it!
Use cases reveal the aim and the subsequent objectives of a system and the target user roles (also called actors) by listing the steps and interactions that lead to a common goal. In simpler terms, they shed light on the interaction flow between the end-user and the system, showing how the two should communicate and react at each juncture along the way in response to the actions of the other. When creating a use case, ideally in a collaborative Design Thinking mode, more abstract and high-level descriptions of the user’s activities and tasks (outlined in a previous process step of the project, e.g. in storyboards), are transformed into more tangible interactions between the involved actors. The more precise and detailed a use case is, the likelier it is that the system to be designed will benefit end-users.
Certainly, a design can be created before the use cases are created, resulting in a beautiful user interface that will “wow” the stakeholders. But, the question is to what extent at this stage will the design also “wow” end-users? The concern is that we might not be able to capture all the important interaction details, identify unnecessary repetitions or head-off wasteful dead-ends. These are common pitfalls that many times result in additional effort and an excessive number of design iterations to spot and handle them.
On the other hand, creating use cases first has many advantages. We can be sure that all of the information from the earlier user research phase has been thoroughly considered. The use case presents the specifics of the user-system interaction so that we can ensure usability, understand how the system should behave in specific situations, and even check the evolution of the interaction against the identified personas.
The purpose of the use cases is to ensure that the end-user’s needs and wishes within a given business process are well represented. They can even be reused in later phases of the process as test cases for functional quality tests.
So… as you can see there is a good reason to insist, “we’ll do the use cases first!”