Using Scenarios

Some thinking about scenarios….

It takes a thousand voices to tell a single story
– Native American saying, tribe unknown

A scenario is a description of a persona using a product to achieve a goal, they describe an instance of use…in context.

Scenarios are usually narratives that tell a story describing one or more tasks in a specific environmental situation.

For the design of services and systems we can use scenarios to understand and communicate what activities our system needs to support.

Scenarios are flexible and can become more detailed throughout the project life-cycle. They should focus on the activities people do and the context in which they do them. They differ from use cases in that they focus on specific situations and capture the diversity between these. Your scenarios should illustrate all of the situations in which people visiting your site/ application will experience.

They help focus design efforts on the user’s requirements, which are distinct from technical or business requirements. They are also particularly good for discussing requirements with stakeholders who do not have any technical background.

Scenarios are the plot and personas the characters, and they can stage user actions with a future artifact.

The schema below illustrates the things that should be considered when writing scenarios.

Why Use Them

There are a number of reasons that scenarios are useful for experience design.

They can provide a vehicle for communication as well as a mechanism to explore design solutions.
They help mediate the thinking and communication required in design.
They are concrete yet flexible enough to change and morph in detail as the project progresses.
They help us understand the flow of experience and are tools for thinking about design (they help us reflect and reason)
They help us present and situate solutions
They help identify potential problems
They are easily understandable by all stakeholders as they are story-like
They can provide rich descriptions of use in context which can spark ideas and help inform design
They help determine if the design solution is appropriate
They can help us see social factors and help understand a users multi-channel experiences (i.e.z on and off-line_

When to use them

Scenarios can have a number of iterations and be utilised in a number of ways throughout the project life-cycle.

They can be used in the beginning of a project to help flesh out requirements.
They can be used as tools to explore design solutions.
They can be used to validate designs and reveal design assumptions.
They can be used to hang specifications and wire-frames off within documentation.
They can be used by testers to test the final designs.
They can be used for competitor analysis whereby a scenario can be used to compare a variety of sites to each other.

Before you begin

To write a scenario, you need a basic understanding of the tasks to be supported by the system. You also need to have an understanding of the users and the context of use. Scenarios can be derived from data gathered during contextual enquiry activities. If you do not have access to such data, you can write scenarios based on prior knowledge or even ‘best guess’, provided the scenarios will be subject to review by users prior to being used as a basis for making design decisions.

To write a scenario, describe in simple language the interaction that needs to take place. It is important to avoid references to technology, except where the technology represents a design constraint that must be acknowledged. Include references to all relevant aspects (including cultural and attitudinal factors) of the interaction, even where they are outside the current scope of the technology.

For example, the fact that Sally is continually interrupted by telephone calls may be just as relevant as the software platform she uses. These types of details should be considered during the design.

After you have written a scenario, review it and remove any unwarranted references to systems or technologies. For example, the statement ‘the customer identifies herself’ is appropriate, whereas ‘the customer types her 4-digit PIN’ is not (unless the PIN is a non-negotiable system constraint). You should also have the scenario reviewed by users to ensure that it is representative of the real world. (NB this comes from a really good book on UCD by Kim Goodwin: Designing for the Digital Age)

Evolving Scenarios

Scenarios are a great artifact which can evolve over time.

Below is a schema adapted from Pruitt and Adlin (in the Persona Life-cyle) showing how they can evolve over time.

This schema shows how scenarios can evolve and be both prescriptive and evocative and can be used at different stages of the design life-cycle.

Understanding context

Understanding a users context is central to scenario definition. The following should be considered for each persona

Goals: What is the user trying to accomplish? How do the user’s actions fit into the objectives of the organization?
Process: What are the steps the user will follow? How does information flow from one step to the next? What are the various roles (such as creator, contributor, editor, or approver) that are involved?
Inputs & Outputs: What materials and information will the user need to successfully use the interface? What will they need from the interface to continue with their overarching goals?
Experience: What similar things has the user done in their past? How has the organization survived without this design in the past?
Constraints: What physical, temporal, or financial constraints are likely to impose themselves on the user’s work?
Physical Environment: How much room does the user have to work? What materials on their desk? What access do they have to necessary information (such as user manuals)? What is taped to their monitor?
Tools In use: What hardware and software does the user currently use?
Relationships: What are the interconnections between the primary user and other people who are affected by the tool?