« Back to Writing

Response to The Foundations of Design: Scenarios and Requirements

This post was written for UW's HCDE 518, User Centered Design, in response to chapter 6 (The Foundations of Design: Scenarios and Requirements) of About Face by Alan Cooper et al.

In this chapter, the authors emphasize the importance of scenarios, especially in their use as an effective communication and ideation tool for design teams. The authors then propose a five-step method for transforming user research into design requirements.

Compared to use cases (at the individual task level and without regard for different user types), the authors stress that scenarios based on the project's specific personas are most effective for two reasons:

  1. Using personas helps the designers (and other stakeholders) empathize with their audience, making it easier for them to understand their needs.
  2. Personas help illustrate goals and motivations, guiding the project at a higher level. Focusing on individual tasks can cause designers to lose track of the overall purpose of the project.

There are (at least) 3 types of scenarios: context scenarios, key path scenarios, and validation scenarios (see definitions in Key Terms). Different types of scenarios can be used at different steps in the design process. For example, context scenarios are used to generate high-level ideas about the overall design solution, while validation scenarios can be used to test for secondary interactions and edge cases.

Though jumping straight to designing is tempting, make sure to define the requirements before actually beginning to design! Decide what you need to design before you decide how it will be designed. Without defining requirements, beyond not knowing why you are really creating the design, you will not have a grounded way of evaluating the quality of your design. Develop a set of requirements based on the users' needs rather than on desired features.

Five steps for turning user research into requirement definitions:

  1. Problem and Vision Statements: Formally state the problem and design objective such that the process for moving forward on the project is clear.
  2. Brainstorming: Brainstorm in order to dump as many preconceived ideas as possible as well as to get the designers to transition from analysis to creativity.
  3. Identifying persona expectations: E.g. recognize users' mental models that will need to be preserved (as much as possible) in the final interface.
  4. Constructing context scenarios: Take an initial pass at constructing context scenarios, focusing on high-level interactions from the user's point of view and making sure to include contextual information like setting, time of use, other roles, and user skill levels.
  5. Identifying requirements: Extract objects, actions, and contexts from the context scenario.

Key Terms

a story that is used to illustrate how a potential user might interact with a future system. Different types of scenarios throughout the design process can be used to talk about a design solution in general (high-level) or to refine details (low-level).
Use Case
an ordered list of specific interactions and specific system responses for completing a task. Use cases don't cover the motivations and goals of users and may therefore miss more subtle but important points of the interaction design.
Context scenario
high-level interactions in a particular setting, used to envision the potential use of a product, focusing on a persona's needs, goals, and motivation.
Key path scenario
focus on the primary way that a user would use a product, allowing designers to being focusing on what the main flow of the interface should be to support that path.
Validation scenarios
secondary or less common goals that still need to be achieved by the interface, used to test if interface still supports other usages.
Problem statement
A concise description of the reason for the new design, focusing on the existing system's problems or of a problem that hasn't been solved.
Vision statement
A transformation of the problem statement into a forward-looking to define what the design team will be aiming to do on the project, focusing on the fact that the problems will be solved.
Mental model
The users' belief and perception of how a system is structured, even if incorrect.
Represented model
How the system is structured and organized via the designed interface. For effective design, the represented model should aim to match the users' mental models, even if this isn't how the data is naturally structured.
Traditionally used to list required features. The authors suggest, instead, to think of requirements as user needs (focus on the problem rather than the specific solution).


  1. When identifying requirements (in terms of user needs), how can designers avoid thinking of specific features or design ideas? How can designers ignore their preconceived ideas about the solution?
  2. Let's walk through some other parts of the example context scenario (from the text) and identify additional requirements (objects, actions, and contexts).
  3. One student asked on the class discussion board, "For products with narrow functional requirements, could there still be value in constructing scenarios and personas?" Do you think designers can use persona-based scenarios on rigid projects? How?

« Next: Broadcasting through Cloudy Glass: The Imagined Audiences of Social Media Networks

Previous: Autoethnography: Reflecting Upon Computer Mediated Communication »