How to create use cases

Research strategy

6 min read Max Koh

Whether you’re working in software development or product management, it’s important that you have a way to plan and test whatever ideas you have brewing in your mind. But is there a way to map out particular tasks your users perform, and find problems they might encounter along their journey? This is where use cases fit in, and if you haven’t had a chance to employ one into your planning processes yet, now’s your chance to learn the basics.

What is a use case?

Use cases are written and often illustrated descriptions for how people would actually use your system when trying to complete tasks (systems here are websites, applications, or software). An example of this is someone completing a sale on an ecommerce site. Use cases are usually (and best) introduced whenever you’re designing or re-designing a system.

The main goals of use cases are to:

Map out actions for a particular goal
Identify issues that are associated with reaching that goal
Determine how to fix these issues and how much time/money is needed to do this
Make the route to that goal a lot easier for future users

Although they can involve a bit of hard work, use cases are extremely beneficial:

They can help you identify problems people may run into using your system, and eliminate or minimize these issues
They can help you communicate these problems to others people in an easy-to-understand format (for example, people in other roles at your company, clients, or even customers)
They can help you identify what your system needs to do, rather than just what it is currently able to do (helpful for product management and roadmapping)
They can be used in other areas of business, such as user documentation and assistance or project management/planning.

Additionally, use cases in user experience design definitely have a warranted place. As use cases can help to identify problems that people may run into, they’re perfect for user experience design, and fixing and testing those issues. Once you have defined your cases, you can find out what information people need to complete each task and make their overall experience better.

For example, let’s say you ran an online store for outdoor and camping equipment. One of your use cases might be for a customer to place an order for a five-person sized tent.

In order to do this, a user would need to login (or maybe signup in the first place), find the tent, place the order, then make the payment. While analyzing these tasks, you might discover that your login or signup forms are extremely hard to find. Perhaps your product categories are a mess and users can’t locate the products they want through navigation. In these cases, Treejack and OptimalSort could help you improve the functionality of these parts of the site, and therefore, your use cases.

This is a use case diagram for creating a use case diagram

How to create use cases

Depending on the project you’re working on, use case development can take up a lot of time and research. There are likely a number of use cases you want to analyze, and there’s a lot of thought and planning that goes into each one.

Use cases are made up of a number of elements:

An actor: The person carrying out the use case. This is one of your typical users.
The system: What kind of system is this use case based on? Is it an application, a website, or something else? What is the system doing during each step the actor is taking? For example, when the actor logs in, the system might be verifying the login information.
Goals and actions: Your actor needs something to fulfil, so give them a goal. In the above use case description example, the actor’s goal is to complete a purchase for a five-person sized tent. You also need to think about how the actor will complete his or her goal. Remember to keep your use cases in simple English — stay away from technical jargon.
Basic and alternative flows: Ivar Jacobson International, whose founder is said to be the inventor of use cases back in the 1980s, states each use case should have two flows: basic flow and alternative flows. The basic flow is what should happen, while alternative flows are other events that can happen (or things that can go wrong). Looking at the camping store example, perhaps an alternative flow could be the actor’s card was invalid or not supported.

Use case examples

Use case diagrams look like flowcharts and typically contain stickfigure drawings and text bubbles that outline each goal. Text is very minimal and only there to describe goals and actions. There shouldn’t be more than a few words for each action, a title, and a few labels in your use case.

There are many tools available to help you create use cases, and some even offer a use case tutorial or guide to get you started.

Here are a few we’ve found:

Use cases versus user stories

Although they look pretty similar on paper, use cases and user stories are not the same thing.

User stories are descriptions written from the perspective of a user, detailing a goal and a reason or benefit for their goal when using your system.

For example, a user story for the camping and outdoor store may be “As a consumer, I want to store multiple address details in my account so I can switch between work and home deliveries.” In this example, the following is identified: the user (consumer), the user’s goal (store multiple addresses in their account), and a reason (so they can switch between work and home delivery addresses).

User stories are kept short and lightweight, as changes are usually meant to be implemented quickly. It’s a good idea to give each user story a priority ranking so when it comes time to analyze and implement them, you know which ones are “must dos” and “nice to haves”.

Remember, the main goal for user stories is to help identify what your system needs to do for the people who use it. On the other hand, use cases help you to figure out the problems people may encounter when using your system.

Got any great examples of use cases or user stories? Comment below!