Editor’s note: This use case tutorial and template was last updated on 3 August 2024.
For requirements collection and high-level stakeholder communication, product managers need to be able to describe how a consumer will interact with a system or product. This can include a description of the product’s users, how they interact with the product, and what it does.
A great way to visually represent this information is by creating a use case.
In this guide, we’ll define what a use case is, describe the elements therein and what they are designed to do, and walk through how to build a use case step by step.
We’ll also look at some use case examples to show what they look like in practice.
A use case is a description of how a user interacts with a system or product. Companies build use cases to establish success scenarios, failure scenarios, and any important variants or exceptions.
Many organizations leverage use case modeling tools — such as Miro, LucidChart, and SmartDraw, for some examples — to write or visually represent a use case.
Use cases are frequently employed in software development environments to simplify complicated concepts, but they can be just as important in project management for gathering requirements and defining a project’s scope.
Product management, product development, and product testing domains all use the use case methodology. Product managers and developers employ use cases in a similar manner: as a design tool to specify how the system will react to user activities. However, there are some key differences.
Product managers typically document user-focused use cases whereas developers document product-focused use cases. The user-focused use cases are primarily concerned with the user and their objectives. These are then passed to developers to guide decision-making during the product development process.
Product developers frequently add technical and design elements to provide crucial context. This set of improved use cases gives the development team the insight it needs to start designing, creating, and testing the product and its features.
A use case is designed to reveal system demands early on in the process.
Use cases concentrate on the system’s users rather than the system itself. A user case should be understandable to all stakeholders, not only developers and testers, because they are mostly narrative prose. This includes customers, users, and executives.
During the early planning stages, you should involve whichever roles are best suited to solve the problem at hand. This encourages end users to buy into the solution and reduces surprises once the system is put into place.
Each use case is designed specifically to cover only one application of the system. That said, a key advantage of use case modeling is that it also covers all potential problems. Finding minor requirements early on in the project saves a ton of time by identifying exceptions to a successful scenario.
Finally, after you create a use case, you can use it to guide the creation of many other software development components, such as object models, test case definitions, user documentation, and project planning (cost, complexity, and scheduling estimations).
As a product manager, one of the best justifications for creating use cases is that they serve as genuine connecting points. They should be truly understandable to both business and technical users so that everybody can comment on them.
Business analysts leverage use cases as a communication tool to align people to take a common approach and share a common understanding of what the software aims to accomplish.
A technical product manager, on the other hand, might employ use cases to reach business stakeholders without using tech jargon — talking more about what the system does than how it does it. When you get down to the dirty work of coding, this will really help you accelerate and clarify communication to ensure that you’re building what the business genuinely needs and desires.
Let’s break down the components of a typical use case and explain the purpose and objective of each.
Actors are the people or things that interact with your system. An actor could be an individual, a company, a team, or something else entirely. Anything that exists outside of a system and engages in some sort of interaction with it qualifies as an actor.
The stakeholder who gets the ball rolling with an interaction to achieve a goal using your system is known as the primary actor.
Your system, which some people refer to as a scene, is composed of a number of decisions and interactions made by your actors.
The results of an actor’s interactions with the system are your goals.
Your system may produce several outputs in some circumstances while only producing one in others. Before continuing, consider modifying your method if you encounter any barriers to achieving your goal.
Preconditions are assertions or realities regarding what must occur prior to and following the use case.
Often, software developers are aware of the actions that must come before the next one.
For example, let’s say an online shopper clicks on a product to get a detailed description and customer feedback. The Add to cart button won’t show up until the item is in stock and accessible at the warehouse.
A use case that operates flawlessly and exactly as intended with no exceptions or mistakes in the run is known as the fundamental flow or main success scenario. This frequently serves as a starting point when developing various features.
Knowing how a typical scenario operates can help you write accurate code and come up with alternative flows.
A deviation from the primary success scenario is known as an alternative path or alternative flow. This typically manifests when a system-level error occurs.
In this section of the use case, you frequently list the most probable or noteworthy exceptions an actor might make. Alternative flows in the ecommerce example might include:
In a use case diagram, stick figures are the most typical way to depict actors.
The use cases/goals you create will be horizontal ovals with a few words of text inside detailing each activity; you can use various colors to indicate different goals.
Associations that depict the connections between components use solid and dotted lines.
Each set of use cases within a system are grouped together by system boundary boxes, which are rectangles.
An example of a use case diagram for a medical clinic application might look something like this:
To write a use case, complete the following steps:
You can use the template below to assist you in writing your own use case:
To use this use case template, click here and make a copy by selecting File > Make a copy from the top menu bar.
To show how the steps outlined above work in practice, let’s look at an example use case of a housekeeper doing laundry:
The basic flow for this use case example is as follows:
The housekeeper comes to the laundry room on Friday. They organize the available laundry. After that, they clean and then dry each load. They fold the articles that need folding, then iron and hang the wrinkled items
Alternative flows:
Here are a few examples of how use cases can be applied in different industries:
In the healthcare industry, use cases can streamline patient care processes and enhance communication between medical staff. An example use case:
In the finance sector, use cases can help in outlining the user interaction with financial systems. An example use case:
In the ecommerce industry, use cases can improve the user shopping experience. An example use case:
In software development, use cases can assist in understanding user interactions with the software system. An example use case:
A use case example could be a customer interacting with an ecommerce website to search for a product, add it to the cart, and proceed with the checkout process.
To write a use case, you need to define the actor, the goal, the preconditions, the main success scenario, and any alternative flows.
The main components of a use case include the actor, system, goal, preconditions, main success scenario, and alternative flows.
Use cases are important because they help to understand the requirements of a system from the user’s perspective, ensuring that the final product meets user needs and expectations.
Use cases help product teams understand a system’s functions from the viewpoint of distinct users. They help stakeholders across the organization visually understand the various flows and how user groups interact with the system.
Use cases also support the development team when generating concepts and assessing the viability of the use cases. Use case definition is a crucial phase in the software development process and is a critical skill for any product manager.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
To help demystify stakeholder management, you can use tools that introduce a structured approach for your product team.
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
2 Replies to "What is a use case? Definition, template, and how to write one"
ok. This was useful
Thank you for this