A situated use case (SUC) is the “setting” in which a product is used.
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.
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 good SUC will describe, in broad strokes, the nature of co-users as well as the user themselves.
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:
A SUC consists simply of:
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.|
|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.
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.|
|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.|
|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.|
|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.
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.
TODO Describe consequences and counter-indications.