Methods for Creating New Designs

Use Cases

What are they?

Use Cases are formal versions of a scenario—stories that describe someone using a product, system, or service to achieve a goal. Compared with scenarios, Use Cases embody a much more rigorous approach to storytelling. In addition to one "main path," systems typically include dozens or even hundreds of other paths people can take on their way to accomplishing their goals. Use Cases are intended to capture the breadth of interactions—both normal and uncommon—someone could have with a system. They help engineers and other technical team members to describe functionality requirements and build a system that matches users' needs. Additionally, use cases can feed directly into "test cases":—the narrative-based evaluation methods used by software developers use to check their code for defects.

Use Cases are written, but are typically accompanied by a diagram of actions and interactions.

How do I do it?

To create Use Cases, consider the users who are involved and their goals. Working from an overview to a detailed and descriptive view, articulate the steps the users will take to achieve their goals. More specifically, follow these steps:

List the actors and their roles. What experience can we assume the actors have with both the system and the domain?

For example, the actors involved in a homeless shelter service may include the following:

• Nancy, aged 31, is homeless, has a history of depression and anxiety, and has traveled by herself throughout the southern states for the past six years. She sleeps on the streets until the temperature drops below freezing, when she tries to find a place to sleep inside. She carries a bedroll, a mobile phone, and an expired drivers' license; she goes out of her way to carry as little as possible because she has been robbed several times in the last few months. She typically asks for spare change at a busy corner and knows the best hours and sign messages to encourage donations.
• Mitch, aged 44, is a caseworker who has worked at various Dallas homeless facilities since he graduated from college; he received a Master of Social Work with a focus on housing and the extreme poor. Recently, he has explored technology-based interventions and has introduced web- and mobile-based tools to support the homeless people and the workers that serve them. At night, Mitch is teaching himself database management and programming.

Describe the actors' multiple goals. For example, Nancy's goals in using an SMS-based bed finder on a freezing night may include the following:

• finding a safe place to sleep for the evening
• finding a female-only facility
• finding a quiet, sparsely populated area
• being discreet
• knowing how long it will take to walk to the sleeping location

Mitch's goals for the same system are different:

• providing care to as many people as possible
• knowing how many people the system serves in a month
• knowing why people return or don't return to the shelter after their first experience

As is common in life, various actors' goals often conflict. In this case, Nancy's goals for a quiet and discreet bed may be at odds with Mitch's goals to provide shelter to as many people as possible.

Create the main narrative that describes a user using the system to achieve a goal. This should describe success, and focus on the most important goals of a given user. As you write the narrative, be sure to include preconditions, technologies, decision points, assumptions, and actions:

• Preconditions define the existing constraints upon the user. These may include previous knowledge, social and political influences, physical and economic context, etc.
• Technologies describe the systems that support users' ability to achieve their goals. In addition to digital technologies, such as computers or mobile phones, they may also include physical infrastructure (buildings, spaces) and artifacts (objects, forms, brochures, posters).
• Decision points are moments in which the user is forced to do something, often after needing to choose between two or more directions. These actions have impact on the well-being of other people and the actor, so in decision points, designed interventions can drive emotional and intellectual value.
• Assumptions describe why a person is acting in a certain way. Assumptions are based on previous knowledge, the current situation, and various external influences. Assumptions should be credible and should consider emotional, social, economic and political influences, and not just knowledge because—people may act irrationally because of the way they feel.
• Actions should be written at a broad level ("Mitch placed a call to Fred") rather than a detailed interaction level ("Mitch pressed the 2 button, then the 4 button...").

Craft supporting Use Cases that relate to subgoals, alternative goals, and related goals.

Continually refine multiple Use Cases in a design to ensure they support one another. Combine smaller Use Cases or break out cases that can stand on their own.

In writing Use Cases, avoid describing the medium of the solution. For example, if the user is going to be using software, avoid the temptation to describe buttons, labels, and other widgets, for two reasons: This level of specificity creates artificial constraints, which are desired at later phases in the project, but limiting to creativity at this early phase. It also tends to "make the Use Cases long, hard to read, and brittle."

When should I use it?

Create Use Cases as an explicit way to move from research and opportunity-finding to designing; Use Cases begin to define the solution. They can be created alongside storyboards or can leverage storyboards as a point of departure. The process of creating Use Cases often highlights areas of incomplete research.

What is the output, and how can I use it?

The output of a cohesive use-case writing exercise is a series of stories that define the breadth of the system to be designed. Use Cases also act as input into more detailed and pragmatic design artifacts, such as sketches, wireframes, information architecture diagrams, and service design blueprints.

Where can I learn more?

Read the book Writing Effective Use Cases, by Alistair Cockburn.

Keep Reading