Designing a product takes more than listing features and goals. Before the first smartphone came out, how would you describe the ways users interact with it? Calling it a cellphone you can browse the web on is a good start, but that doesn’t explain the complexity of its systems. To map out the ways users interact with a system, tool, or product, you need a use case.
Use cases are descriptions of the ways users interact with systems to accomplish tasks or reach goals. Mapping these interactions can improve early planning and ensure a smooth development cycle. To help you work them into project planning, we’ll define a use case, explain how to write one, and share examples.
A use case explains how users interact with a product or system. It outlines the flow of user inputs, establishing successful and failed paths to meeting goals. This allows product teams to better understand what a system does, how it performs, and why errors occur. You can write one out or diagram a use case model for visual thinkers.
Use cases vary in complexity depending on your audience or system. But across the board, your use case should identify a few key components. The most important ones include:
Actors, systems, and goals build the foundation for a use case. When you begin tracking system interactions, a few new elements come into play:
Use cases come in two forms: business and system. A system use case is a detailed look at how users interact with each part of a system. It highlights how unique inputs and contexts cause the system to reach different outcomes. This level of detail highlights how a system’s individual functions work in any scenario.
Business use cases paint a more general picture of how a user might interact with your business to reach their goals. Instead of focusing on technical detail, it’s a cause-and-effect description of different inputs. For example, if you run a code debugging platform, your business use case explains how users enter their code and receive error notices.
Some teams like to write a business use case to outline a system’s processes before development. As developers begin their work, a manager will outline more technical system use cases to follow.
Use cases show all the ways a system functions when trying to reach goals, but a scenario only depicts one example. In a scenario, the system can succeed or fail at reaching the user’s goals. Put simply, multiple use scenarios build a use case.
Use cases depict how users interact with a system, and user stories describe features from the user’s perspective. As a result, user stories are much shorter than use cases, typically consisting of brief descriptions teams use as a jumping-off point in development. Additionally, use cases can assist multiple teams in an organization, while user stories help product teams build their tool.
While a use case covers how users and system features work to reach goals, test cases verify if a single feature works correctly. Unlike use cases, test cases look at functionality in isolation.
For example, a test case might involve validating login functionality on an email platform, ensuring users can log in on any browser at any time after creating their account.
Writing a use case sounds complex, but only requires understanding your system and its users. You can write a use case by following these six steps:
Start by describing your system, or the product or service you and your team will build. Focus your description on what your system does for users. In a business use case, you can keep this background general and explain what it accomplishes. For a system use case, give an under-the-hood description of how your product functions.
Define your system by asking:
Actors generally refer to users and customers but can apply to any outside force that engages with your system. Your actor needs well-defined behaviors explaining how and why actors use your system.
Identify actors by asking:
Use cases highlight the outcome actors want from a system. Remember to focus on your actors’ wants over the system’s capabilities to understand why users come to your system. In some cases, customers want to use systems for more than one objective. Listing each of these objectives creates a more robust use case.
In a use case, scenarios are the sequence of actions customers take when using a system and the flow of effects from that interaction. Your basic flows cover scenarios where a system works as intended. A user approaches the system, enters the right inputs, and your system helps them reach their goals.
Start with these successful, basic flows to create a baseline. You can use process mapping techniques to identify potential issues in the next flows.
After writing a successful scenario, write alternate flows that lead to different outcomes. Typically, alternate flows involve the misuse of a system that keeps actors from reaching their goals. However, you can also note internal errors that cause a system to break down or unintended ways systems can reach goals.
Alternate flows show how different actors use a system and succeed or fail. They give a more nuanced view of everything your system can do to help you troubleshoot.
With enough variation of actors, goals, and scenarios, you can show how your system functions. Compiling these flows together gives you a use case, which can improve development and inform other documents like project status reports.
With simple systems, you can change a few elements to see every potential outcome. However complex systems may have too many elements to see each outcome. In cases like this, you can focus on testing the most common interactions. You can also design systems to prevent untested com
Ready to start brainstorming use cases? Try the Figma use case template to break down your systems and find new solutions.
Assume you’re a product manager developing a mobile banking app for your company. Your platform needs to streamline user registration and account setup. Here’s a sample use case format based on this app:
Background information:
Scenarios:
In the planning stage, use cases define your project scope, requirements, and roadmap. Teams can also discuss the best user outcomes and design a path to them. With alternate flows, you can also anticipate risks before they hurt a user’s experience. If that isn’t enough reason to pen one, here are a few other benefits of use cases:
Use cases go beyond describing what your product can do. They give stakeholders and teams a clear picture of user interactions and successful outcomes. Whether adding a new feature, rapid prototyping, or redesigning a system, your planning should start with writing a use case.
The more insights into actors, interactions, and outcomes, the better—which is why it's important to collaborate on use cases with your team and stakeholders. A shared online whiteboard like FigJam streamlines collaboration between remote teams to help you build out comprehensive use cases. Our gallery of 300+ templates can bring teams together at any stage of development.
