Authors: alexandra.matz and panagiotis.germanakos
“Use case” is a term widely used in the business world. Stakeholders refer to uses cases in various contexts: business analysts describe “use cases” in their reports, politicians claim that there is or isn’t a “use case” for a decision or a project. Each time people assign a different meaning to the term.
In companies, a “use case” is often synonymous with a business case, a process or a scenario which could be implemented as a product or part of a product. When we talk about “use cases” in the context of user experience (UX), we are referring to the documentation of possible interactions between users and a system. Use cases in UX are a very important tool for user research and user experience design. In a design-led development process, they show the purpose and the objectives of a system and its associated user roles by expressing a sequence of their steps and interactions towards a specific, common goal.
Now, with all the focus on user experience, why would anybody other than user experience professionals work with use cases? The answer is that use cases can be used extensively and continuously beyond the design phase, specifically in development and quality assurance, with various benefits:
Technology-independent documentation style
Use cases are technology-independent in the way they describe the user and system interaction. Thus, we can make a clear distinction between the actors, their interaction with the system and the flow of information. This enables cross-functional teams to collaboratively evaluate, discuss and validate the use case without needing to write a single line of code. A detailed, validated use case is an ideal point of reference and gives clear guidance to the team on how to design, develop and test the interaction of the application. As such, use cases are equally valuable for UX, development and quality assurance.
Provision of alternative and failure cases
To ship a feasible, desirable and high-quality product, it is very important to design the product not only for success cases but also include possible failure cases and alternative flows in a user interaction. In use cases, these can be documented easily without the need to go into every detail. In a second step, and after the main success use case has been created, the product team can then consider the details of the alternative cases and – depending on the complexity – create separate use cases for those scenarios.
Thus, product architects and developers receive a well-documented and agreed-upon basis of necessary and possible interactions. This provides a good overview and insights into what must be built and what might need to be built.
Information architecture and use-case hierarchy
A use case is rarely standalone. In addition to alternative flows and failure cases, parent and child use cases and other related cases emerge during use case work to complete the bigger picture.
Most frequently a use case hierarchy consisting of a parent use case with multiple children, failure cases etc. evolves. However, related use cases which might have been created by another product team can also be documented in the hierarchy. These could be because different user roles execute the same task across business scenarios or even products, and so these use cases can be reused in several use case hierarchies, even across business scenarios or even products.
A use case hierarchy helps development teams understand system functionalities before they go into the implementation phase. Clear and structured interactions can be used in architecture design as well as in backlog planning since use cases are easier to break down into manageable packages and backlog items. In addition, it enables project teams to make more accurate time and cost estimations and improve resource allocations for design, development and testing.
Data binding of UI data
One benefit of use cases is that you can include UI data at each interaction step, be it for the user or the system side. To make use cases technology-independent, easy-to-read, and understandable for all product team members, a use case shows which data elements must be on the screen. Even though not in data dictionary format, it expresses the inputs from and outputs to the user.
Database architects and developers can do the data binding for the UI development based on this information, without iterating or discussing repeatedly which data fields are meant to be on the UI.
User Assistance
As use cases can be created and understood by all product team members, it is also the ideal medium for user assistance experts to sketch out possible terminology questions and concerns. Depending on the complexity of the business scenario, some use cases or actions within a use case might need to be documented in a more assistive way. On the one hand this enhances the quality of the use case, and on the other hand it ensures the seamless inclusion of user assistance expertise in the design and development process.
Derive your test scenarios and demo scripts from use cases
Use cases are based on user research information from interviews and observations, with the end-user in mind. Therefore, use cases are also an ideal basis for creating test scripts for usability tests, test scenarios for quality assurance as well as demo scripts to showcase a product.
In addition to the user/system interaction steps, each use case defines exactly who the user is, and what the interaction goal and trigger are. Combining this with the usability study goals and critical elements which need to be tested, a very good guidance for the test script is already in place.
Going further into quality assurance, the module integration or scenario tests of implemented software products will also benefit from use cases. It is easier and faster to define the related test data and quality criteria since use cases represent a clear step-by-step interaction with the system, formulating a good basis for setting up test scenarios.
Finally, use cases are also an asset when creating realistic product demos. With appropriate example data, the demos will be based on and represent valid end user scenarios.
These are the reasons why we believe use cases bring value to all stakeholders in a product team. What about your projects, are you using use cases beyond UX activities? Let us hear about your thoughts and business cases!
Further Reading
#designmistakes – Designing without Use Cases
Learn more about how to write use cases with Build's Learning Card for use cases
- SAP Managed Tags:
