<aside> 🚩 A situated use case (SUC) is a particular “setting” in which an intervention is used, and from which designers can establish context for the use of interventions by users.

</aside>

• ON THIS PAGE

Overview

What is a situated use case?

A situated use case (SUC) is an instance of a setting in which a design intervention will be used.

Each SUC is connected to a particular Persona; that is, a SUC describes a particular situation that a particular (archetypal) user will try to achieve a goal using a specific Design Concept. Defining SUCs is important to ground analyses of how and why users would use an intervention, and the kinds of interactions they could have with the intervention.

The purpose of SUCs is to set up circumstances that could cause faulty interactions between users and the intervention. Your job is to design those faulty interactions out of your intervention.

Many SUCs are possible for any single intervention and single user. You might use a portable music player (1) at the beach, or (2) in your home, or (3) in your car. In each case, the situation will impact how you use the player, and how the player might respond to different inputs from either the user or from the environment itself.

<aside> 💡 Exercise for the Reader. Consider the case of the portable music player in the three different situations noted above. What makes each situation unique from the others? What influences might the distinctive features of each situation have on the design of the player?

</aside>

While SUCs are defined from the point of view of particular type of user, other co-users often play a crucial role in establishing a good SUC.

A co-user is a secondary user - one who may not interact with a product directly, but whose actions can have a significant impact on the outcomes of product usage. Here are some examples.

• A passenger in a vehicle: Say you're designing some kind of vehicle, and your SUC is intended to capture the situation from the point of view of the driver. Different passengers can significantly impact how a driver will interact with the vehicle. Consider a ride-hailing company like Uber. How might the driver's interactions with the vehicle change if their passenger is sober vs drunk, friendly vs angry, calm vs anxious?
• A sous-chef: How might a chef interact with their kitchen staff if their sous-chef were competent vs incompetent?

A good SUC will describe, in broad strokes, the nature of co-users as well as the user themselves.

However, a single SUC by itself is of limited use in design. SUCs become truly useful when a collection of them accurately represent the breadth and depth of general use of an intervention. This means that while no single SUC will capture a universal situation, an appropriately defined collection of SUCs will cover a broad range of possible situations that you expect your intervention will see in actual use.

A set of SUCs then exhibit three characteristics:

• reasonable: one may reasonably expect the conditions described in the SUC to actually occur in real life.
• distinct: to capture the breadth of an intervention's use, each SUC must be as different as possible from every other SUC.
• general: a good SUC will not be tied to a specific technology or design, except where such technologies and designs are mandated by the Design Brief.

A good SUC will cover all stages of an intervention’s use. For instance, say you’re designing a way to escape from a burning building. An SUC that covers only reaching a conveyance of escape (e.g., a stairway, slide/chute, etc.) is not enough.

How are situated use cases specified?

A SUC consists simply of:

• a unique ID (so it's easier to refer to in later stages of designing),
• a brief descriptive title that includes the name of the Persona involved,
• the name of the team member responsible for that SUC, and
• a description of the situation, including its relevance to the design.