This is an old revision of the document!
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).
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.
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.