Use Case is a method that is often used in UX/UI design agencies to work on new projects. From this post, you’re going to discover what it is and how to use it when doing your projects.

What Is a Use Case?

When you’re trying to understand what a Use Case is, you need to know there are different definitions. According to Coburn, it is “an agreement on the behavior of the system in question.” Coburn produced a whole book just to reveal and clarify his definition.

In simple words, a Use Case is a text or a diagram describing the scenario of interactions with the system that leads to a meaningful result.

This definition tells us from the beginning that a Use Case should be kept clear and straightforward. Here are some rules:

• You should include the result in the heading.
• The Use Cases describes the system and actors and external systems that interact with the central system. It also states who’s the leading participant.
  
• Mentions actions as they happen step-by-step.
  

What Use Case Consists Of

Depending on the complexity, the Use Case may contain the following elements:

• Name: short, clear, reflecting the essence.
• Brief Description is a text that describes this Use Case.
  
• Participants (Actors) is a list of participants in the interaction. Often consists of one person.
  
• Preconditions are the conditions that must perform before the implementation of this Use Case.
  
• Trigger - An event or condition that forces the user to proceed with the Use Case.
  
• Basic scenario (Basic Flow) - a sequence of actions that the participant performs to achieve the goal successfully. Also called Normal Flow, Primary Scenario, and Happy Path.
  
• Alternative Scenarios (Alternative Flows) are the description of alternative scenarios for the use of Use Case. An essential condition for alternative scenarios is that the participant ultimately successfully reaches the goal.
  
• Exceptional Flows are all that can lead a member to fail to use a case.
• Post-Condition (Post Conditions) - the result after the Use Case.
  

Fortunately, in practice, it is not always necessary to use all the points. UX/UI designers have different approaches to writing Use Cases. It all depends on why and for whom you are writing it.

How to Write a Use Case

Where do you start? Open any text editor, for example, Google Docs, which is convenient to share with colleagues.

When developing a user case, you should not impose premature design restrictions. It should not contain any details about screen sizes and control elements of the interface. Is a user going to choose an option from the drop-down list or by clicking a button? It doesn’t matter now; you should postpone decisions at this level. Please do not do the work of a designer, because he will do it better than you.

In general, when choosing information to include in a Use Case, the main criteria should be ease of perception. For the sake of it, you can sacrifice rules, detail, sometimes even accuracy. The main thing is that the Use Case is understandable on the go. If it’s hard to understand on the fly, then it isn’t a good one.

Do not try to stuff everything into one Use Case — different users, different scenarios - different Use Cases.

Working With Multiple Systems

One of the central concepts in the Use Case methodology is the “system under consideration” (also called SuC (System under Consideration), or SuD (System under Development).

Use Cases imply that we are working with predictable and limited systems. You build a network and then interact with it in clear, describable ways. Everything in nature divides into complex systems, and what’s outside of them. So, the interaction happens between an organized system and the outside world. This approach can be called “unicellular.” We focus on what happens in the cell membrane and ignore everything else.

However, what happens when systems interact with each other? How do we describe that? For instance, businesses usually consist of different departments, which interact with each other to perform business functions. A UX/UI designer must satisfy the needs of both of these departments, not just one, and provide a tool for user-friendly business communication.

Consider the systems we modify participants in the interaction with the same rights and limitations as all the others.

Using this approach, you’re entitled to extract a set of functional requirements for each system individually. You can add functionality for both of the methods, or just one of the other ones already has them. Indeed, it gives you a more comprehensive view of the processes compared to what traditional Use Case methodology can provide you.

Mention the Domain of the Use Case

Use cases should be based on a niche-specific model that all project participants understand the same. Designing the interface for a banking app is different in terms of setting and participants than a professional system for top managers of an international enterprise. For example, in the case of a bank, you will be using terms such as “bank account,” “credit card,” “debit card,” “currency rate,” “client,” and so on.

The most famous domain introduction tool is the glossary. You should include in the dictionary only those words that might not be clear to anyone. If you start explaining everything, then after the first three points, the reader will become bored, and he will close the glossary, not reaching the important part.

You can also write short articles explaining new concepts.

Use Case List

If the form of Use Cases describes the requirements, then their list becomes a useful project management tool. For example, using such a listing, you can prioritize their implementation; measure progress by the number of use cases implemented. The list of user cases can exist in the form of the actual file (Use Case Survey) or the form of a diagram of use cases.

An example of such a list:

• Set RPM forecast
• Create conversion requests
• Send applications to the bank
• Complete conversion requests
• Take into account completed applications

Unsuccessful Scripts

When writing a Use Case, never forget that something can go wrong. Many professionals forget to include this in their plans and sometimes face having to redo the project from scratch.

For instance, let’s say you write a Use Case for an e-commerce application. You describe how the customer chooses an item and purchases it. But what if they decide to return it? You have to think about this type of scenario in advance as well if you don’t want to be stuck rewriting the app at the last stage.

The Use Case can indeed help to reduce the likeliness of such outcomes. However, to use this tool most effectively, you need to ask yourself at each step: what can go wrong (not as expected)? This is what makes the Use Case both beneficial and practical for a digital project.

Conclusion

Use Cases are already quite an old methodology. During the last 20 years, new approaches have emerged that have moved the method of the areas where it was once the best. For example, Use Cases help more effectively manage requirements in Agile projects. User experience design methods help in developing products that are successful on the market.

Nevertheless, cases are still a functional analysis tool, especially for systems that support business processes. Any UX/UI designer, business analyst, or project manager should know the methodology of user cases and be able to use it.