What is a use case? Definition, template, and how to write one

Editor’s note: This post was last updated on 20 January 2025 to include a downloadable template, updated examples, and a focus on real-world applications.

For requirements gathering and high-level stakeholder communication, product managers need to understand and articulate how a consumer will interact with a system or product. A use case serves as a crucial tool for this by providing a structured description of the product’s users, how they interact with it, and what it does.

In this guide, I’ll define what a use case is, describe its elements and what they are designed to do, and walk through how to build a use case step-by-step.

I’ve also included some real-world examples of use cases from different industries and built a downloadable template for you!

What is a use case?

A use case is a detailed description of how a user interacts with a system or product to achieve a specific goal. It outlines the step-by-step flow of actions that lead to a desired outcome and can help identify potential issues, such as failure scenarios or exceptions.

While often used in software development, use cases can serve as essential tools in various fields, including project management and business analysis, to clearly define requirements, user needs, and system behaviors.

Uses cases come in two primary types:

• Business use cases — Focus on the big picture and how a system or process helps the business achieve its goals. These use cases typically look at how the system ties into broader business strategies. For example, a business use case for an ecommerce site might describe the overall process of a customer purchasing something — like payment and shipping — without getting into too many technical details
• System use cases — Zoom in on the specifics of how a user interacts with a system to complete a task. These are more technical and break down the exact steps the user takes and what the system needs to do in response. So, for the same ecommerce site, a system use case would dive into how the user selects products, enters payment details, and receives confirmation — focusing on the mechanics of the checkout process

What is NOT a use case

It’s important to remember that use cases are different from other tools you might come across in product development. They’re not the same as user stories or basic feature lists.

While both user stories and feature lists describe what a system can do, they don’t provide the same level of detail as use cases, which outline the full interaction process — errors, exceptions, and all:

• User stories focus on a single feature or capability from the user’s perspective but don’t dive into the details of how the interaction works. For example, a user story might say, “As a user, I want to check out my shopping cart,” but it won’t explain the steps involved in that process
• Feature lists are just a list of what features the system should have, but they don’t show how the user will actually interact with those features

Use cases, on the other hand, go beyond just listing features. They provide a full roadmap of how the user will interact with a system, including what happens in different scenarios, what to do if something goes wrong, and how things should flow to meet the goal.

Who creates use cases?

Use cases are a valuable tool across different areas of product management, development, and testing. You’ll find product managers, developers, and even business analysts using them, but each group tends to use them in slightly different ways:

• Product managers typically focus on the user side of things. They document use cases that highlight how users will interact with the product and what their goals are. These are “user-focused” use cases, and they serve as the foundation for the design process. Once these are in place, they’re passed along to developers to guide their work
• Product developers take these user-focused use cases and start adding technical and design details. They translate the user interactions into concrete steps the system needs to take. These “product-focused” use cases help developers figure out how to build and test the product such that it meets user expectations
• Business analysts also play an important role, especially when it comes to traceability and testing. They take these use cases and track them throughout the project to ensure all the requirements are met and that no steps are missed. They ensure everything works out as expected by making sure the use cases cover all scenarios, including edge cases or potential errors

In short, everyone contributes to use cases in their own way. Product managers focus on the user’s perspective, developers refine them with technical details, and business analysts make sure everything stays on track and gets tested properly.

What is a use case designed to do?

A use case is designed to reveal the system’s demands early on in the process, helping everyone get on the same page from the start.

Use cases focus on how users interact with the system, not just the system itself. They’re written in plain language, which means they’re understandable to everyone involved, not only developers and testers, because they are mostly narrative prose. This includes customers, users, and even executives — so it’s a great way to get all stakeholders aligned.

When you’re in the early planning stages, it’s important to bring in the right roles — like business analysts or product managers — who can help solve specific problems. This helps get end users on board with the solution and reduces the chance of unexpected surprises later on.

Each use case typically covers only one application of the system. The real value here is that use cases also shine a light on potential issues right off the bat. By identifying these exceptions and edge cases early, you save time and effort in the long run. This is especially useful for improving software resilience because considering alternative flows helps prepare the system to handle things that might go wrong.

Once you’ve created a use case, it can guide the development of other important components, like object models, test case definitions, user documentation, and project planning (think cost, complexity, and scheduling estimations).

And this is where traceability comes in. Use cases connect the dots between business requirements and testing frameworks, making sure that what’s being built aligns with what’s needed.

Elements of a use case

Let’s break down the components of a typical use case and explain each component’s purpose and objective. I’ll also talk about some advanced elements to help you build more comprehensive use cases:

Actors

Actors are the people, teams, or systems interacting with your system. An actor could be:

• A person — like a patient in a healthcare app
• A team — like a fraud detection team in a finance system
• Another system — like a third-part API handling payment processing

The primary actor is the one initiating the interaction to achieve a goal using your system.

Systems

Your system is the framework within which actors interact to achieve their goals. It’s like the stage on which your actors perform. Examples could be a patient portal, an online banking platform, or the checkout process on a retail website.

Goals

The results of an actor’s interactions with the system are your goals. Examples of goals could be:

• A patient scheduling a doctor’s appointment through a portal
• A customer transferring funds between accounts
• A user completing a purchase and receiving an order confirmation

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

Preconditions are assertions or realities that specify what must already be true or set up for the use case to proceed.

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 appear until the item is in stock and accessible at the warehouse.

Preconditions like these ensure that the system and user are in the right state for the use case to function correctly.

Triggers

Triggers are the events or conditions that initiate a use case. These can be user actions, system processes, or external events. I’ll take a few examples:

• For a healthcare app, a trigger might be a patient clicking “Schedule Appointment” after browsing doctor availability
• A user pressing “Transfer Money” to move funds, or
• A user selecting “Proceed to Checkout” after adding items to their cart

Triggers like these mark the start of the interaction flow and are essential to define when a use case begins.

Basic flow

The basic flow, or the main success scenario, outlines the steps where everything works perfectly as intended with no exceptions or mistakes. This frequently serves as a starting point when developing various features.

A basic flow for a healthcare app would be a patient scheduling an appointment, getting confirmation, and receiving reminders. For a finance app, it would be — a customer successfully logs in, transfers funds, and gets a transaction receipt.

Knowing how a typical scenario operates can help write accurate code and develop alternative flows.

Alternative flows

Alternative flows describe deviations or exceptions to the basic flow. They typically manifest when a system-level error occurs.

In this section of the use case, you list the most probable or noteworthy exceptions an actor might make. Alternative flows might include:

• On a finance app, the transfer fails due to insufficient funds, and the system suggests reviewing account balances
• The doctor’s schedule updates while the patient is booking, prompting them to select a new time
• A credit card payment is declined, leading the user to choose another payment method

If you’re including alternative flows to your system, you ensure it can handle unexpected scenarios gracefully.

Post-conditions

Post-conditions define the state of the system after the use case is completed — whether successfully or not. Some examples could be:

• After scheduling, the appointment appears in the user’s calendar, and the doctor’s availability is updated
• After a successful transfer, both account balances are updated, and a receipt is saved in the system
• Once an order is placed, the inventory adjusts, and a tracking number is generated for the user

Post-conditions confirm the outcome of the use case and ensure the system transitions smoothly to the next state.

What does a use case diagram look like?

A use case diagram visually represents how actors interact with your system and the goals they aim to achieve. The most common elements include:

• Stick figures to depict actors
• Horizontal ovals for use cases (goals), labeled with a few descriptive words inside detailing each activity; different colors to indicate different goals
• Solid and dotted lines for associations, showing relationships between components
• System boundary boxed (rectangles), grouping related use cases with a specific system

An example of a simple use case diagram for a medical clinic application might look something like this:

A more complex use case might look like this:

Tips for creating use case diagrams

Creating effective and clear use case diagrams can be a bit tricky. Here’s how to keep it simple and useful:

• Stick to UML standards — Use stick figures, ovals, and rectangles; nothing fancy, just what’s standard; just make sure every actor, goal, and system boundary is clearly labeled
• Pick the right tool — There’s Lucidchart (super easy to use and comes with handy templates), Draw.io (free and great for teams working together), Visio (if your team already uses Microsoft tools), Creately (great for quick collaboration and sharing)
• Don’t overcomplicate it — Focus on the most important actors and use cases. If things get messy, break it into smaller diagrams. And use colors to highlight key paths, like success flows or alternative scenarios
• Collaborate — Share drafts with your team (business analysts, developers, testers, whoever needs to weigh in) to make sure you’re covering all the bases

How to write a use case

A lot goes into writing a use case. It starts with the basics — understanding your users and their goals — and extends to advanced techniques that ensure your system is robust and ready for the real world.

Here’s a step-by-step guide to writing use cases, complete with practical tips, advanced steps, and common pitfalls to avoid.

Basic steps

1. Determine the target audience — Identify who will use your product. This could be end users, business teams, developers, or external systems
2. Select a specific user — Focus on one user type at a time
3. Identify their goal — Determine what, exactly, the user wants to do with the product. Each goal should have its own use case
4. Outline the typical flow — Map out the main steps the user will take to achieve their goal, along with the system’s responses
5. Describe the primary flow in detail — In the use case description, describe the fundamental course. Give examples of what the user performs and what the system responds with so that the user is aware of both
6. Expand with alternative flows — Think about what might not go as planned. Document deviations from the primary flow, such as errors or user-initiated detours
7. Find connections — Look for links between different use cases. For example, completing one use case might trigger another
8. Repeat for all other users — Go back to step two and create use cases for every key user or external system

Advanced steps

Identify edge cases and uncommon flows

Doing this is important to ensure system resilience. While the primary flow addresses typical user behavior, edge cases cover unusual or unexpected scenarios. To identify them:

• Consider actions users might take that fall outside typical behavior
• Account for system limitations, like handling peak loads or unsupported inputs
• Brainstorm “what if” scenarios. What if a user loses their internet connection? What if a payment gateway times out?

Map use cases to test case design

Use cases are a goldmine for creating test cases that cover both typical and atypical system behavior. To do this:

• Break each step of the use case into individual test scenarios
• Cover the primary flow, alternative flows, and edge cases
• Include expected inputs, outputs, and validations for each step

Writing use cases for APIs and complex systems

When working with APIs or complex systems, use cases should clearly define interactions, focusing on what each actor expects and delivers. Here’s how:

• Define actors as API clients, such as mobile apps, web apps, or external systems
• Specify preconditions like authentication requirements or required headers
• Include a step-by-step flow for request and response interactions
• Document error handling scenarios like rate-limiting or invalid inputs

Common pitfalls to avoid

• Overloading use cases with detail — Too much detail can overwhelm stakeholders. Focus on high-level interactions instead of granular technical specifications
• Skipping alternative flows and edge cases — Omitting these can lead to missed bugs and system vulnerabilities. Always think about “what could go wrong”
• Too many actors or goals in one diagram — Overcrowded diagrams confuse more than they clarify. Split them into smaller, focused ones if needed
• Vague descriptions — Avoid ambiguous terms like “the system does something.” Clearly describe each action and outcome

Use case template

You can use the template below to assist you in writing your own use case:

Click here to access this use case template (File > Make a copy).

Industry-specific use case examples

Here are a few examples of how use cases can be applied in different industries:

Healthcare

In the healthcare industry, use cases can streamline patient care processes and enhance communication between medical staff. An example use case:

• Actors — Patient (primary), doctor, nurse, receptionist
• Goal — Schedule a medical appointment
• Preconditions — Patient has an existing medical record in the system
• Basic flow — Patient logs into the healthcare portal, selects an available slot, and confirms the appointment
• Alternative flows — Doctor reschedules due to an emergency; patient cancels or modifies the appointment

EdTech

In the EdTech industry, use cases can improve student engagement and streamline learning experiences. An example use case:

• Actors — Student (primary), quiz system, teacher
• Goal — Take a quiz and receive results
• Preconditions — The student is logged in, and the quiz is published
• Basic flow — The student logs into the quiz system, selects an available quiz from the dashboard, the quiz system displays questions one by one, the student answers all the questions; upon submission, the system calculates the score and displays the results
• Alternative flows — the student runs out of time, and the system auto-submits the quiz with the answers provided so far; the student loses connectivity, and the system saves progress for resumption later

Finance

In the finance sector, use cases can help in outlining the user interaction with financial systems. An example use case:

• Actors — Loan applicant (primary), bank officer, credit system
• Goal — Apply for a personal loan
• Preconditions — Applicant has a bank account
• Basic flow — Applicant fills out the loan application form online, uploads necessary documents, and submits the application
• Alternative flows — Applicant receives a request for additional information; application is denied due to insufficient credit score

Ecommerce

In the ecommerce industry, use cases can improve the user shopping experience. An example use case:

• Actors — Customer (primary), ecommerce system, payment gateway
• Goal — Purchase a product
• Preconditions — Customer has an account and is logged in
• Basic flow — Customer searches for a product, adds it to the cart, proceeds to checkout, and completes the payment
• Alternative flows — Customer applies a discount code; customer opts for different shipping options

Software development

In software development, use cases can assist in understanding user interactions with the software system. An example use case:

• Actors — Developer (primary), version control system, continuous integration system
• Goal — Commit code to a repository
• Preconditions — Developer has a feature branch ready
• Basic flow — Developer commits the code, pushes it to the remote repository, and the continuous integration system runs the tests
• Alternative flows — Commit fails due to merge conflicts; continuous integration build fails due to errors

Transportation

In the transportation industry, use cases can simplify booking processes and improve rider and driver satisfaction. An example use case:

• Actors — Rider (primary), driver, ride-hailing system
• Goal — Book a ride to a destination
• Preconditions — Both the rider and driver accounts are active and online
• Basic flow — The rider enters the pickup and drop-off locations in the app, the app calculates the fare and shows ride options, the rider selects an option and confirms the booking, the system matches the rider with an available driver, the driver accepts the request and reaches the pickup location, the driver completes the ride, and the rider makes the payment
• Alternative flows — The assigned driver cancels the trip, and the system matches the rider with a new driver; the rider’s payment method fails, and the app prompts the rider to update payment information

Tools for creating use cases

And, of course, writing use cases can feel a lot easier when you have the right tools to map everything out. Whether you’re sketching simple diagrams or managing complex workflows, there’s a tool for every need. I’ll share some of my favorites and what makes them great:

Miro

Miro is perfect for sketching ideas and building use cases with your team. What’s cool about it:

• Super simple drag-and-drop interface
• Ready-to-use templates for use case diagrams and flowcharts
• Real-time collaboration, so everyone can pitch in at the same time
• Works with other tools like Jira, Confluence, and Slack

Lucidchart

Lucidchart’s for when I need polished, professional diagrams because it:

• Is great for making detailed UML diagrams
• Is easy to use, with tons of shapes and colors to choose from
• Allows to collaborate live and leave comments directly on the diagram
• Has export options for sharing (PDF, PNG, etc.)

SpiraTeam

This one’s a bit more advanced and perfect for tying your use cases to real project tasks and testing. Here’s why:

• Tracks everything from use cases to testing and requirements
• Links easily with testing tools like Selenium
• Built-in reports to keep your project on track
• Central hub for your whole team’s input

Microsoft Visio

A classic for a reason, Visio is great for creating professional diagrams. It:

• Has tons of templates for UML diagrams and more
• Syncs seamlessly with Microsoft apps like Excel and PowerPoint
• Offers advanced styling options for a clean, polished look
• Is ideal for bigger, enterprise-level projects

FAQs

What is the definition of “use case”?

A use case is a detailed description of how users interact with a system to achieve a specific goal. It includes actors, goals, preconditions, and step-by-step flows of events.

What is an example of a 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.

What are some other words for “use case”?

Other terms that might be used interchangeably with “use case” include — scenario, workflow, interaction flow, or user interaction model.

How do you write a use case?

To write a use case, you need to define the actor, the goal, the preconditions, the main success scenario, and any alternative flows.

What are the components of a use case?

The main components of a use case include the actor, system, goal, preconditions, main success scenario, and alternative flows.

What are some advanced modeling techniques for use cases?

Some advanced techniques include:

• Using UML diagrams to visualize complex use cases
• Creating alternate and exception flows to handle edge cases
• Layering use cases to address hierarchical relationships between systems
• Applying data flow modeling to track inputs and outputs

How do use cases help in agile vs. waterfall environments?

In agile, use cases support iterative development by breaking down interactions into manageable chunks. In waterfall environments, use cases provide a structured blueprint for requirements gathering and system design.

What is a use case versus a user story?

A use case provides a detailed breakdown of an interaction, covering all scenarios, preconditions, and flows. A user story, on the other hand, is a short and simple description of a feature from the user’s perspective, often written as: “As a [user], I want [action] so that [goal].”

When should I use a user story instead of a use case?

Use user stories when you need quick, high-level insights into what users want. Use cases are better suited for detailed workflows, especially in complex systems with multiple actors and flows.

Why are use cases important?

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.

Summary

Use cases are a game-changer for aligning teams and building better systems. They make complex processes easy to understand by focusing on user needs and interactions.

For product teams, they clarify goals. For developers, they guide features. For testers, they map directly to test cases, ensuring nothing slips through the cracks — even edge cases and alternative flows. Use use cases for:

• Better communication — everyone’s on the same page
• Fewer surprises — spot problems early
• Smoother development and testing — build and test with purpose

To help you get started, here are some resources:

• Templates for use cases — Download a free use case template
• Diagramming tools — Use Lucidchart or Miro to create interactive diagrams