Scenario of Use

Scenarios are descriptions of one or more users interacting with with a system, device, or process to achieve a goal under specified conditions and constraints. They provide information about the context in which a system has to operate, in a user- and task-oriented way.

Scenarios can be presented as rich narratives (e.g.,an hour or a day in the life of a user) or simple statements describing the triggers and situation that prompts a user to interact with a system. Scenarios sometimes include simple lists of the steps in a task. Scenarios are used in design sessions, walkthroughs, and usability tests to ensure that the system design effectively supports users in a wide range of real-life situations. They are also known as “task scenarios”.

Scenarios and use cases

Scenarios are sometimes called “use cases”. However the term “use case” can be confusing, as it is used with a different meaning in software engineering. One way of illustrating the difference is through the classic example of withdrawing money from a bank.

• Use cases will include the functional steps of: requesting the withdrawl, verifying your identity, specifying the amount of the withdrawl, checking available funds, and receiving the requested money.
• Scenarios may include situations like: visiting an ATM when the bank is closed (in the rain), a tall person using an ATM in glaring sun, getting a withdrawl from a bank teller inside a bank, or requesting the withdrawl in the form of a bank draft (a check).

User-centered design usually tries to have a scenario refer to multiple component use cases (depending on functions required to satisfy the goal of the scenario), and also to have a use case refer to multiple scenarios (depending on the likely triggering situations and goals that reflect the overall expectations for the system in user terms).

Related Links

Web Resources

Usability.gov. (ND). A brief description of scenarios for design and scenarios for testing by usability.gov

Gaffney, G. (ND). A brief description of scenarios by Information & Design

Degler, D., Battle, L. and Taylor, D.H. (2003). Sharing the Vision = Designs that Get Built. Usability Professionals’ Association conference 2003. Phoenix, AZ, USA. Discusses the relationships between user-centered design documentation and traditional systems engineering formats, including the relationship between scenarios and use cases.

IxDA Discussion Threads

• Use Cases or Scenarios discusses the differences between use cases and scenarios.
• Scenarios and Task in usability testing discusses how scenarios can be used in usability testing.
• Functions or Scenarios? discusses how programmers can make use of scenarios.

Authoritative References

• Alexander, I. F., & Maiden, N., (Eds.) (2004). Scenarios, stories, use cases through the systems development life cycle. New York, NY: Wiley.
• Carroll, J. M. (2000). Making use: Scenario-based design of human-computer interactions. Cambridge, MA: The MIT Press.
• Hackos, J. T., & Redish, J. C. (1998). User and task analysis for interface design. New York, NY: Wiley.
• McGraw, K. L., & Harbison, K. (1997). The Scenario-based engineering process. Lawrence Earlbaum.
• Rosson, M. B., & Carroll, J. M. (2002). Usability engineering: Scenario-based development of human-computer interaction. San Francisco, CA: Morgan Kaufmann.

Published Studies

McInerney, Paul. Exercise for A Structured Template for Writing Scenarios. UPA 2004 Conference.

Detailed Description

Benefits, Advantages and Disadvantages

Benefits

• Scenarios can be used to communicate design issues and create a shared vision among the product team.
• They can be re-used for many purposes including: usability test development, quality testing, persona development, task analysis and to check out conceptual models.
• The technique can be used by developers with nil to minimal human factors expertise.
• Only minimal resources are required to generate scenarios.

Advantages

• Scenarios are relatively inexpensive and easy to create.
• Scenarios are flexible. You can reflect various tasks, user characteristics, and environments.

Disadvantages

• Scenarios are often not based on actual user data which can lead to incorrect assumptions.
• It is often left to the interpretation of the designer on how to integrate scenarios into the overall development process.

Appropriate Uses

Scenarios are most useful when produced early in development as specific, realistic, and detailed examples of what a user would do, but without making any reference what user interface features that would be used. Scenarios can also be used later to explore how the interface would be operated.

• Scenarios encourage designers to consider the characteristics of the intended users, their tasks and their environment.
• Usability issues can be explored at a very early stage in the design process (before a commitment to code has been made).
• Scenarios can help identify usability targets and likely task completion times.
• The method promotes developer buy-in and encourages a user-centred design approach.
• Scenarios can also be used to generate contexts for evaluation studies, including usability testing.

How To

Procedure

• Gather together the development team and other relevant stakeholders under the direction of an experienced facilitator.
• Identify intended users, their tasks and the general context. This information will provide the basis for the scenarios to be created by the development team.
• Functionally decompose user goals into the operations needed to achieve them.
• Consider which activities should be performed by the user and which by the computer.
• Create an outline of the users’ activities, goals and motivations for using the system being designed, and the tasks they will perform.
• To maintain design flexibility, scenarios should not specify what product features are used.
• Assign task time estimates and completion criteria as usability targets.
• The session can be videotaped for later review or transcribed for wider distribution.
• The results from scenario building sessions can be used to plan user-based evaluations.

Practical guidelines

• Try to generate scenarios to cover a wide range of situations, not just the most common ones or those of most interest to the design team.
• Try to include problem situations that will test the system concept, not just straightforward scenarios.
• Work through the scenarios fully and judge the system on that basis rather than trying to change the system half way through.

Scenarios for usability testing

Scenarios for tasks in usability testing are less detailed than scenarios used for design, but should give sufficient information to explain the situation in which a user is attempting to achieve a goal.

A good scenario for usability testing gives the participants:

• a goal/task (what to do or what question to find the answer for)
• data, if needed, that a real user would have when going to the site/application to do that task

These examples are from usability.gov:

• Your grandfather told you that he posed for Bertrand Adams when he was painting his large 1937 masterpiece, Early Settlers of Dubuque. You heard that the painting is displayed in a Federal building. In which building can this artwork be found?
• Your friend Chris calls you from Paris that his salary was delayed by a day but he needs to pay off a Monthly Installment for the car he bought recently. He requests you for some money to cover for the installment. You have it with you in your bank account. How do you think you can quickly arrange for money to get to Chris? And can you explain how would you go about doing that?

Explanation: Here the user is assumed to be in London. And the scenario is a part of a user interview regarding a consumer banking website. The designer is trying to check if the user can identify the “Fund Transfer Across Borders” feature and to see his perception of how it might be used.

Who Can Facilitate

An experienced moderator is recommended for the sessions in which the scenarios are explored. Next Steps

Use the scenarios as a basis for developing more specific usability requirements.