How to Optimize Product Development With Use Cases: Identifying the Criteria of a Good Tool

Hi everyone! I’m Nata, a UX/UI designer at Red Collar. I’m here to speak about Use Cases, a methodology that can improve communication within your team and, therefore, the entire process of working on a product. If you’ve never heard of Use Cases before, I ensure you’ll find an explanation and a template below.

In an ideal world, Use Cases are prepared by a Systems Analyst based on a set of rules identified by a Business Analyst once they’ve spoken to the customers. However, a team may not have those roles covered due to time and/or budget constraints. Regardless, it’s still essential to hand over information about the project. In such a case, the task of putting use cases together is taken by other team members like Product Managers or UX/UI Designers.

Why Should You Write Use Cases?

A short answer would be: so that all team members have a unified vision of how the system will work.

If you have a team of over five members and the project is scheduled for more than three months ahead, you risk facing miscommunication at some point in time. The examples might be:

• Developers didn’t understand the user scenarios correctly and implemented the features differently from what was planned;
• During a lengthy discussion with the team members, you drifted away from the initial idea and now are unable to recreate it;
• Designers created functional components which weren’t initially planned;
• The same case was interpreted and implemented differently in different places, which caused an increase in development time and made UX more complicated;
• During testing, considerable errors are left unnoticed;
• The team changes: new members are introduced while the team’s leading members have already left.

What is a Use Case?

A use case describes how a user interacts with the system. It is a list of consecutive actions a user performs to achieve a specific result. Basically, it is a metamodel that doesn’t illustrate a system itself but rather a set of requirements for this system.

The methodology was developed in the ’80s by a guy named Ivar Jacobson. For everybody who wants to dig deeper into this, there is a free book called Use-Case 2.0. I’ll leave this and some other useful links on the topic at the end of the article.

For clarity, a use case can be compared to a tennis match: one player is the user, and the other is the system. The user hits a tennis ball, i.e., performs an action. Then the ball passes to the system, and it replies to that action. The only difference is that in a use case, a user can perform more than one action consecutively.

Use Cases come in two equivalent forms: a UML diagram and a text document. The form depends on two things: what tools the team is used to and what’s more comfortable for them to work with. If you wish, these forms can be combined. Further in this post I’ll provide use case examples as text documents.

Two Use Case forms: a text document and a UML diagram

What Use Cases Consist of

While studying materials and talking with colleagues, I realized there’s no unified way to write Use Cases. Each company makes its own decision on what layout to use and how detailed it should be. Based on my personal experience and publicly available information, I’ve put together the main writing principles.

1. A clear heading, preferably containing the outcome of the use case. Like, “Post a request.”
2. The leading users or participants. You can identify them as one of the following:

• “The user and the system.” E.g., during authorization;
• “A few users and the system.” E.g., if you’re describing communication in a chat;
• “The system and the system” if you’re describing internal processes of the system;
• “A few systems and the system”;

3. A sequence of actions as a scenario;

4. The result. In other words, where the user or the system will end up.

Below you can see a simple use case of a registration process that includes all the main elements. The steps were numbered to make it easier for the team members to reference a specific stage should there be a discussion.

A simple Use Case example

It looks simple, right? But in reality, the cases can be much more complicated. That’s why it’s best to provide additional information:

• context of use,
• where the user came from to arrive at this use case scenario,
• additional conditions,
• the trigger,
• the goal.

You can add a list of input fields for the use case in the description, if needed, for a better understanding of the scenario.

Here is an example of a more complicated use case:

An example of an extended Use Case with clarification

These were the original (successful) use case scenarios. But what happens if there’s an error? Or if the user encounters difficulties? For these reasons, we create an alternative use case where the result of the original one isn’t achieved. Imagine the user couldn’t sign up because the username had already been taken.

Usually, we set up a separate spreadsheet for the alternative use cases. Still, if the scenario is short, I prefer to include it in the original use case.

An example of a Use Case with alternative scenarios included in the main one

The Criteria of a Good Use Case

Earlier, we figured out that use cases are primarily needed to improve communication within a team. And now, it shouldn’t be a problem for you to write a use case of your own. But remember that it’s also essential for the use case to be clear.

Below, I put together some criteria to help you write a use case that’s easy to understand.

How Do You Start Writing, and How to Streamline the Process

Ideally, use cases are written at the design stage, at the same time as planning the product and its core features. But often, the need for use cases is uncovered much later. Typically, it’s when designs are already finished and some part of the product has been developed.

Suppose you already have a design. Then, before putting together use cases, you should study all the materials, list the sections and how users can interact with them. Do it with the Product Manager, Designer, and other team members involved in the planning and design of the product.

Here are a few tips to speed up the writing process:

1. Create one template for all the project’s use cases. It’s not bad if it changes in the future. But you should have one so that your team won’t create a new layout for every new use case. Otherwise, your use cases will be hard to write and even more difficult for others to understand.
2. Create a glossary for the terminology used. Suppose your team actively uses some specific language or works on a project in a particularly narrow niche. Then you should definitely create a glossary to include the terms and their definitions. Refer to it each time someone from your team writes a use case.

Do You Need a Use Case?

The final point. It’s important to understand that use cases are a tool. And the goal of any tool is to ease your working process. If you’ve implemented this methodology and haven’t noticed any changes — you waste resources when you continue using it. Think of reconsidering your methods of documentation and trying out other formats.

Go make fantastic products!

Useful links:

1. Use Case template in Google Docs
2. A website with articles and free e-books on use cases by Ivar Jacobson, the creator of this methodology
3. A short video on the topic of use cases on YouTube
4. An article by Usability.gov