Scenarios

Download ‘printer-friendly’ PDF version (File size: 9 KB)

A scenario is a description of a person’s interaction with a system. Scenarios help focus design efforts on the user’s requirements, which are distinct from technical or business requirements. Scenarios may be related to ‘use cases’, which describe interactions at a technical level. Unlike use cases, however, scenarios can be understood by people who do not have any technical background. They are therefore suitable for use during participatory design activities.

When are scenarios appropriate?

Scenarios are appropriate whenever you need to describe a system interaction from the user’s perspective. They are particularly useful when you need to remove focus from the technology in order to open up design possibilities, or when you need to ensure that technical or budgetary constraints do not override usability constraints without due consideration.

Scenarios can help confine complexity to the technology layer (where it belongs), and prevent it from becoming manifest within the user interface.

How do you write scenarios?

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 of the interaction, even where they are outside the current scope of the technology. Such references may include cultural and attitudinal issues. For example, the fact that Jane is continually interrupted by telephone calls may be just as relevant as the software platform she uses. 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.

How do you use scenarios?

Use scenarios during design to ensure that all participants understand and agree to the design parameters, and to specify exactly what interactions the system must support. Translate scenarios into tasks for conducting walk-through activities and usability tests.

Example

The following is a sample scenario describing a customer withdrawing money from an automated teller machine (ATM).

It’s Friday afternoon and Joe is flying to Sydney. He doesn’t have enough money for a taxi to the airport, and he’s running late. He goes to the local ATM and identifies himself. He specifies that he wants $100 from his savings account. He’d like the money in $20 notes so that he can give the taxi driver the correct change. He doesn’t want a printed receipt, as he doesn’t bother keeping track of transactions in this account.

Note that this description specifically avoids references to transaction cards and PINs. This leaves open the possibility of considering a variety of identification and authorization regimes. Be prepared to review scenarios based on feedback from users. In particular, be prepared to modify or even abandon any unrealistic or unrepresentative scenarios.