Scenarios

=What are Scenarios in Design?=

toc Scenarios are basically stories about people undertaking activities in contexts using technologies. They offer an effective way of exploring and representing activities, enabling the designer to generate ideas, consider solutions and communicate with others (Benyon et.al. 2005). Scenarios are used throughout the design process and, as use cases, form part of the formal specification of the system

Scenarios are useful in requirements work, **prototyping, envisionment, evaluation, conceptual design and physical design:** 5 key stages of interactive design.

Types of Scenarios
Benyon, Turner & Turner (2005) distinguishes 4 typs of scenarios: user stories, conceptual scenarios, concrete scenarios and use cases.

User stories are real world experiences, ideas, anecdotes and knowledge of people. They are rich in context and capture many seemingly trivial details that are usually left out if indivduals are asked to provide more formal presentations of what they do.

//**Example 1 - User Story for a television remote control**// David loves television; he can’t get enough of it. His home-theater setup has a VCR, a DVD player, and a 50-inch plasma television. All this adds up to a bunch of remote controls, so he bought a universal one. The control is divided into three quadrants. He wants to watch a VHS tape, so he puts in a movie and hits Play on the remote control. The DVD player turns on. Surprised, he decides to hit the Stop button to turn it off. The tray for the DVD player pops out. Beginning to feel a little bit irritated, David hits the Stop button again thinking it will cause the tray to go back inside the player. The VHS tape pops out of the VCR. Now annoyed with his movie players, David presses the Power button on the remote to watch some TV. The VHS powers down instead.

Conceptual scenarios are abstract. Context is stripped away during process of abstraction and similar stories are combined together. Conceptual scenarios are particularly useful for generating design ideas and for //understanding// requirements of the system. Abstraction = classification/aggregation: moving from details of the specifics (people, activities, context, technology) and using particular piece of technology to a more general description that still manages to catch essence of activity. Abstraction treats the whole as a single entity.

Each conceptual scenario may generate lots of concrete scenarios. Concrete scenarios often identify some feature that applies only under certain circumstances. They may then develop a more specific elaboration of the scenario and link it to the original. At this point, one reasonably abstract scenario may spawn several more concrete elaborations which are useful for exploring particular issues. Concrete scenarios also dictate interface design and a particular allocation of function between people and devices. They are useful for prototyping as well as envisioning design ideas because they offer a varied perspective of the technology. The more specific the scenario is about some aspect, the more concrete it is.

Use case describes the interaction between people (or other actors) and devices. It is a case of how the system is used and needs to describe what people do and what the system does. Each use case covers many slight variations in circumstances (many concrete scenarios). Tasks and functions have to be allocated to humans or devices before use case can be specified. The specification of it both informs and is informed by task/function allocation process. Use case is used to describe an implementable system. ie, enough interface features are specified and allocation of functions between system and people are complete, so that use case describes a coherent sequence of actions between an actor and system.

Sources:
Benyon, D., Turner, P. & Turner, S. (2005). Designing Interactive Systems: People, Activities, Context and Technologies. Harlow, UK: Pearson Educational