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.
If you’d like to write your own use case while following along with this article, here is a free use case template. To use the template, select File > Make a copy from the top menu bar.
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 e-commerce 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 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 folds the articles that need folding, then iron and hang the wrinkled items
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.
Real user monitoring is the process of collecting information about how users interact with your product as they’re interacting with it.
In product management, unconscious biases can impact decision making in various activities like designing and user research.
Michelle Monaco, Vice President of Product Management at Truepill, discusses her experience leading fully remote teams.
In this article, we’ll discuss outcome-driven roadmaps and why they can actually be more efficient and productive than feature-driven ones.