Create a use case scenario: how to think like users to improve products

Whether working on an app or setting up a sandwich shop, your project needs a reason for existing. And the best way to validate a project to stakeholders (and make sure your creation is a hit) is to show them why and how the intended audience will use it.

A use case scenario describes how a user might interact with a system to achieve a goal. It’s typically used in software development as part of the functional requirements document/plan, but use case scenarios aren’t just for developers.

Let’s take a closer look at what a use case is and how it can help you.

What is a use case?

Explaining how a user will interact with a system is a must if you’re going to a) get buy-in from stakeholders and b) create something the user wants to use.

Like a user story, a use case describes how a user will interact with a system to achieve a goal but on a slightly more granular level. It’s typically written as a sequence of steps, each representing a different action the user takes.

For example, let’s say you’re designing a new e-commerce website. A use case for this project might be something like this:

• A user goes to the website and browses through the product catalog.
• The user adds a product to their shopping cart.
• The user checks out and pays for the product.
• The system sends a confirmation email to the user.

As you can see, a use case is still quite high-level and isn’t meant to be a detailed design document.

Why create a use case?

Use cases are a great way to start a project because they help you understand the user’s needs and how the system will fit into the user flow. By creating a use case, you can:

• Gather requirements from users.
• Define the scope of a project.
• Create a roadmap for development.

Everyone from project managers to developers can use them to understand better how a project works and what needs to happen behind the scenes to make it all run smoothly. You can also use them to create a shared understanding of the project among stakeholders.

How to write a use case

Writing a use case scenario is relatively simple. You just need to answer three questions:

1. Who is going to use the product?
2. What are they going to use it for?
3. How are they going to do it?

Let’s say you’re designing a new software application. Your first step is to identify the user. In this case, it’s someone who wants to book a hotel room.

Next, you need to understand what they want to do with the product. In this case, the user wants to find a hotel room that meets their needs and book it.

Finally, you need to explain how the user will achieve their goal. In this case, they’ll use the software to search and book.

What to include in a use case scenario

The use case can be detailed or basic, depending on the intended audience and system. Either way, the document should establish and identify a few key components:

• System: a system is a collection of hardware, software, and people that work together to achieve a specific goal. In this case, the system is the software application you’re designing.
• Actor: an actor is someone who interacts with the system. In this case, the actor is the user who wants to book a hotel room.
• Goal: a goal is something that the actor wants to achieve by interacting with the system. In this case, the goal is to find and book a hotel room.
• Preconditions: preconditions are conditions you need to meet to complete the use case. In our current example, the precondition is the user’s need for lodging.
• Postconditions: postconditions are conditions that need to be met after completing the use case. In our example, the postcondition is the user confirming a hotel reservation.
• Extensions: extensions are alternative sequences of events that can happen during the use case. In this example, an extension might be something like the user leaving the site before booking or inquiring about the room.
• Use case: the use case outlines the success and failure scenarios that can happen when the actor interacts with the system. During this section, you’ll establish the main success scenario (MSS) and alternative paths that explain what happens in the event of a failure.

What’s the difference between a use case and a use case scenario?

A use case is a set of steps needed to accomplish a specific goal. There can be multiple paths to reaching that goal, and each one of those is considered a use case scenario.

For example, let’s say you have a use case for adding products to a shopping cart. A use case scenario might look something like this:

• A user goes to the website and browses through the product catalog.
• The user attempts to add a product to their shopping cart, but discovers the product is out of stock.
• The user contacts customer service to inquire about the product.
• The system sends a notification to the customer service team.
• The customer service team responds to the user.
• The user receives a notification that the product is back in stock.
• The user adds the product to their shopping cart and completes the purchase.

Use case scenarios (a.k.a. alternative flows) can add a lot of detail to a use case. They can help you understand how the user might interact with the system and what could go wrong. Armed with this level of detail, you can identify and mitigate issues before launch.

How to create a use case scenario

Creating a use case scenario is a four-step process:

1. Identify the actors.
2. Describe the use case.
3. Outline the success and failure scenarios.
4. Diagram the use case scenario.

Let’s go through each of these steps in more detail.

1. Identify the actors

The first step is to identify the different actors that will be interacting with the system. An actor is anyone or anything that interacts with the system. For example, for an e-commerce site, the actors will be the customers. You can make this as granular as you like, such as customers who use TikTok or men in the state of California.

2. Describe the use case

The next step is to describe the use case. This description should be a high-level overview of what the use case is and what it involves.

For example, the description for the customer adding a product to their shopping cart might be: “the customer browses the product catalog and adds a product to their shopping cart.”

Look at things from the user’s perspective to keep your system customer-focused. A typical format to follow might look like this:

• As a <type of user or role>, I want <goal> so that <reason>.

3. Outline the success and failure scenarios

Once you’ve described the use case, you’ll need to outline the success and failure scenarios. A success scenario is a sequence of events that results in the successful completion of a use case. A failure scenario is a sequence of events that prevent the use case from completing successfully.

For example, the success scenario for the customer adding a product to their shopping cart might run as follows:

• The customer browses the product catalog and finds the product they want to buy.
• The customer adds the product to their shopping cart.
• The customer checks out and pays for the product.
• The customer service team ships the product to the customer’s address.
• The customer receives the product.

On the other hand, a failure scenario might run like this:

• The customer browses the product catalog and doesn’t find the product they want to buy.
• The customer abandons the cart and leaves the website.

Or

• The customer adds a product to their shopping cart.
• The customer checks out and pays for the product.
• The customer decides they don’t want the product before it ships.
• The customer service team cancels the order.

As you can see, some failure scenarios are out of your hands. However, your website or app must be prepared to handle all eventualities.

4. Diagram the use case scenario

The last step is to diagram the use case scenario. This will help you visualize the different steps involved in the scenario and see how the actors interact with each other.

You can do this in a few different ways:

• Drawing sketches by hand
• Using the shapes and lines in word processing or slideshow software
• Using a diagramming tool, like Cacoo (the best option, in our opinion)

Why is diagramming software the best option? You can grab ready-made templates and drag-and-drop shapes to build your diagram. You can also share the use case scenario with the rest of the team in real-time and collaborate in the same file. Not to mention, your entire team can add comments and attach files from one convenient hub.

When creating a use case diagram, you’ll need to consider the following:

• Use cases: what functionality do you want to model?
• Actors: who will be interacting with the system?
• Sequences: what is the order of the steps in each use case?
• Relationships: how are the use cases related to each other?

Use case diagrams are a great way to visualize how a system works, but you can also use them to create detailed documentation for any project.

Use case diagram tips and tricks

When creating a use case diagram, there are a few best practices to keep in mind:

1. Keep it simple: use case diagrams should be simple and easy to understand.
2. Avoid duplication: use case scenarios should be unique and not duplicate the functionality of other use cases/scenarios.
3. Be specific: use case scenarios should not be vague. Run your scenarios past other people to make sure you haven’t missed any steps.
4. Focus on the user: use cases should focus on the user and their interactions with the system.
5. Use standard notation: use standard UML notation to make your diagrams easy to understand.
6. Use project management tools: cloud-based project management tools mean you can create user stories, set up project milestones, and edit and share your use case diagrams from anywhere, whether your team is in the same room or on a different continent.