User Tools
Site Tools
Sidebar
Table of Contents
Situated Use Case
A situated use case (SUC) is the “setting” in which a product is used.
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.
SUCs do not include users or interventions, but do include the environment in which users will use an intervention. 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 make sure faulty interactions don't occur when your users will use your intervention.
Many SUCs are possible for any single intervention. 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.
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?
While SUCs are defined from the point of view of particular potential, though hypothetical, users, 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.
How are situated use cases specified?
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.
Each team must develop SUCs that are:
- 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.
A SUC consists simply of:
- a unique ID (so it's easier to refer to in later stages of designing),
- a brief descriptive title,
- the name of the team member responsible for that SUC, and
- a description of the situation.
When developing an SUC, you ought to depend on your situation scan. Every aspect of the sitscan will bear on the development of every SUC. SUCs that are not consistent with the sitscan are simply wrong.
Below is an example SUC for a system to move people between floors of a building1).
| SUC 1 | Users go to work. |
|---|---|
| Owner | Georgiou |
| On an especially cold winter day, many users arrive roughly at the same time and need to go to their respective jobs on different floors of a five-storey office building. |
Exercise for the Reader Consider the following questions and how they imply things that will impact the design of the system.
- Why specify “an especially cold winter day”? How could this affect what happens when people use the system?
- How would you quantify what “an especially cold winter day” is? What about “many users”?
- We have “many” users and a “five-storey office building”. What might happen as they use the system to get to their respective floors?
- What's unique about the users going to their jobs that might be different when they're on their way home?
Every element of the description of a SUC needs to relate to issues you think will appear in actual use. Keeping in mind that a SUC's purpose is to set up a study of potential interaction errors, it's important to make sure that relevant situational information is specified.
Here are some other examples of SUCs; each one is for a different type of product.
| SUC 2 | Making smoothies for the kids. |
|---|---|
| Owner | Kirk |
| 6-year old Johnny has 5 friends over on a hot summer day, and their caregiver decides to make them smoothies using a device stored in an upper cabinet. |
| SUC 3 | Going to work using a human powered vehicle. |
|---|---|
| Owner | Picard |
| A user who lives on the top floor of an old five-storey apartment building is going to work on a rainy day. |
| SUC 4 | Paying for groceries at an automated checkout. |
|---|---|
| Owner | Janeway |
| A user receives a phone call from their spouse while they're using the automated checkout kiosk at the supermarket. |
Exercise for the Reader For each question below, besides answering the question directly, consider what the impact on the user's interactions with the product might be, and the implications this can have for the quality of the user's experience.
- In SUC 2, why do we identify some characteristics of Johnny but not of the caregiver?
- In SUC 3, why do you think it matters where the user lives?
- In SUC 4, what could be the impact of receiving the phone call?
Deliverables
A team of N members must develop N reasonable and distinct SUCs. Each team member will be responsible for one SUC.
Clearly, a team must collaborate to develop those SUCs, to ensure they are reasonable and distinct, but ultimately each SUC will be “owned” by a single team member. Their responsibility will be to ensure that whatever design the team develops will work as well as possible in their SUC.
For each SUC, include no more than 250 words explaining why that SUC was included.
However
TODO Describe consequences and counter-indications.
