What is a Use Case?

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.

What is a use case

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:

• Actor: anything exhibiting behavior that interacts with a system, such as a single user, a team, or another piece of software
• System: the product or service with defined functionality
• Goal: the purpose or objective users reach with a system’s features

Actors, systems, and goals build the foundation for a use case. When you begin tracking system interactions, a few new elements come into play:

• Stakeholder(s): someone with a stake or interest in a system’s performance
• Primary actor: the actor who initiates a system’s function to reach a goal
• Preconditions: underlying factors required for the use case to happen
• Triggers: events that begin a use case
• Basic flows: use cases where systems work as intended to reach a goal
• Alternate flows: different outcomes based on when and how a system veers off course

Types of use cases

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 scenario vs. use case

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 case vs. user story

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.

Use case vs. test case

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.

How to write a use case

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:

1. Describe your system

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:

• What form does it take: product, service, or software?
• What features does it offer?
• What goals can you accomplish with it?
• How does it meet those goals?
• What can you learn about the system from other documents like project charters?

2. Identify the actors

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:

• Are they individuals, teams, hardware, or another system?
• Will primary and secondary actors share the same behavior?
• Will stakeholders take on the role of actors in your use case?

3. Define your actors’ goals

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.

4. Create a scenario

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.

5. Consider alternate 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.

6. Repeat steps 2–5 to compile your use case

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

Use case example

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:

• System: a mobile banking app
• Primary actor: customers who want to open an account
• Secondary actor: underwriters and automated tools calculating interest rates and maximum principal balances
• Goals: save time on account registration and onboarding
• Stakeholders: the CEO and product VP of your company
• Preconditions: users download the app and meet account requirements
• Triggers: the user chooses to create a new account from the app

Scenarios:

• Basic flow: Users download your app and choose to create a new account. The application collects information about the user’s other accounts and credit scores. From there, it automatically shares the accounts they qualify for and their interest rates. The user finds an account that suits their needs and registers.
• Alternate flow 1: Users enter their financial information and the app quickly generates account options. However, each account defaults to the highest interest rate their financial background allows. So, users abandon the app to find a lower rate.
• Alternate flow 2: The onboarding process works as intended, but the app faces compliance issues such as Know Your Customer (KYC) requirements. While the app can provide account options, extra compliance steps slow the process.
• Alternate flow 3: Because the app only looks at other accounts and credit scores, it can’t offer a full range of account options. For example, it can only offer credit cards and lines of credit. So, customers looking for mortgages have to go elsewhere.

Benefits of use cases

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:

• Explains value: Use cases explain a system’s features in plain terms. So, when pitching your plans to stakeholders, a use case makes your system easier to understand.
• Predicts costs: A use case outlines the complexity of a system. More complexity may come with additional features or safeguards. By learning how complex your system is, you can estimate development costs.
• Improves planning: Without a use case, designers and developers focus on what a system does, not how it does it. However, use cases help teams consider all the ways to implement features and safeguards.
• Shares alternative uses: Not all alternative flows in a system lead to failed outcomes. Mapping out different scenarios finds new solutions to old problems or expands your understanding of what a system can accomplish.