“What should this product do?” and “How should this product look and behave?”
Using personas in scenarios
Persona-based scenarios are concise narrative descriptions of one or more personas using a product to achieve specific goals. They allow us to start our designs from a story describing an ideal experience from the persona’s perspective, focusing on people, and how they think and behave, rather than on technology or business goals.
Scenarios can capture the nonverbal dialogue 4 between the user and a product, environment, or system over time, as well as the structure and behavior of interactive functions. Goals serve as a filter for tasks and as guides for structuring the display of information and controls during the iterative process of constructing the scenarios.
Scenario content and context are derived from information gathered during the Research phase and analyzed during the Modeling phase. Designers role-play personas as the characters in these scenarios,5 similar to actors performing improvisa-tion. This process leads to real-time synthesis of structure and behavior —
typically, at a whiteboard — and later informs the detailed look-and-feel. Finally, personas and scenarios are used to test the validity of design ideas and assumptions throughout the process.
Different types of scenarios
The Goal-Directed Design method employs three types of persona-based scenarios at different points in the process, each with a successively more interface-specific focus. The first — the context scenario — is used to explore, at a high level, how the product can best serve the needs of the personas. (We used to call these “day-in-the-life scenarios,” but found that term excessively broad.) The context scenarios are created before any design is performed and are written from the perspective of the persona, focused on human activities, perceptions, and desires. It is in the development of this kind of scenario that the designer has the most leverage to imagine an
10_084113 ch06.qxp 4/3/07 6:03 PM Page 113
Chapter 6: The Foundations of Design: Scenarios and Requirements
113
ideal user experience. More detail about the creation of this type of scenario can be found later in this chapter, under Step 4 in the Requirements Definition process.
Once the design team has defined the product’s functional and data elements, and developed a Design Framework (as described in Chapter 7), a context scenario is revised to become a key path scenario by more specifically describing user interactions with the product and by introducing the vocabulary of the design. These scenarios focus on the most significant user interactions, always maintaining attention on how a persona uses the product to achieve their goals. Key path scenarios are iteratively refined along with the design as more and more detail is developed.
Throughout this process, the design team uses validation scenarios to test the design solution in a variety of situations. These scenarios tend to be less detailed and typically take the form of a number of “what if . . .” questions about the proposed solutions. More detail about development and use of key path and validation scenarios can be found in Chapter 7.
Persona-based scenarios versus use cases
Scenarios and use cases are both methods of describing a user’s interaction with a system. However, they serve very different functions. Goal-Directed scenarios are an iterative means of defining the behavior of a product from the standpoint of specific users (personas). This includes not only the functionality of the system, but the priority of functions and the way those functions are expressed in terms of what the user sees and how she interacts with the system.
Use cases, on the other hand, are a technique based on exhaustive descriptions of functional requirements of the system, often of a transactional nature, focusing on low-level user action and accompanying system response.6 The precise behavior of the system — precisely how the system responds — is not typically part of a conventional or concrete use case; many assumptions about the form and behavior of the system to be designed remain implicit.7 Use cases permit a complete catalogu-ing of user tasks for different classes of users but say little or nothing about how these tasks are presented to the user or how they should be prioritized in the interface. In our experience, the biggest shortcoming of traditional use cases as a basis for interaction design is their tendency to treat all possible user interactions as equally likely and important. This is indicative of their origin in software engineering rather than interaction design. They may be useful in identifying edge cases and for determining that a product is functionally complete, but they should be deployed only in the later stages of design validation.
10_084113 ch06.qxp 4/3/07 6:03 PM Page 114
114
Part I: Understanding Goal-Directed Design
Requirements: The “What” of
Interaction Design
The Requirements Definition phase determines the what of the design: what information and capabilities our personas require to accomplish their goals. It is absolutely critical to define and agree upon the what before we move on to the next question: how the product looks, behaves, operates, and feels. Conflating these two questions can be one of the biggest pitfalls in the design of an interactive product.
Many designers are tempted to jump right into active design and render possible solutions. Regardless of how creative and skillful you are, we urge you not to do this. It runs the risk of turning into a never-ending circle of iteration; proposing a solution without clearly defining and agreeing upon the problem leaves you without a clear method of evaluating the fitness of the design. In lieu of such a method, you, your stakeholders, and your clients are likely to resort to taste and gut instinct, which have a notoriously low success ratio with something as complex as an interactive product.
Define what the product will do before you design how the prod-
DESIGN
principle
uct will do it.
It’s important to note that our concept of a “requirement” here is much different from the way the term is commonly misused in the industry. In many product-development organizations, “requirement” has come to be synonymous with “feature” or “function.” While there is clearly a relationship between requirements and functions (which we leverage as a key part of our design process, as you will see in the next chapter), we suggest that you think of requirements as synonymous with needs. Put another way, at this point, you want to rigorously define the human and business needs that your product must satisfy.
Another critical reason not to conflate requirements with features is that in figuring out the best way to meet a particular human need, an interaction designer has an extraordinary amount of leverage to create a powerful and compelling product.
Think, for example, about designing a data analytics tool to help an executive better understand the state of his business. If you jump right to the how without understanding the what, you might assume that the output of the tool should be reports. It would be easy to come to this conclusion; if you went out and performed user research, you probably would have noticed that reports are a very widespread
10_084113 ch06.qxp 4/3/07 6:03 PM Page 115
Chapter 6: The Foundations of Design: Scenarios and Requirements
115
and accepted solution. However, if you imagine some scenarios and analyze your users’ actual requirements, you might realize that your executive actually needs a way to recognize exceptional situations before opportunities are missed or problems arise, as well a way to understand emerging trends in the data. From here, it isn’t difficult to see that static, flat reports are hardly the best way to meet these needs. With such a solution, your executive has to do the hard work of scrutinizing several of these reports to find the significant data underlying such exceptions and trends. Much better solutions might include data-driven exception reporting or real-time trend monitors.
A final reason to separate problem and solution is that such an approach provides the maximum flexibility in
the changing face of technological constraints and opportunities. By clearly defining the user need, designers can then work with technologists to find the best solutions, without compromising the product’s ability to help people achieve their goals. Working in this manner, the product definition is not at risk when the implementation runs into problems, and it becomes possible to plan long-term technology development so that it can provide increasingly sophisticated ways of meeting user needs.
As we’ve mentioned briefly, these requirements come from several sources. Personas’ previous experiences and mental models often result in some baseline expectations of the product. We derive the bulk of the user requirements from analyzing ideal usage scenarios, and understand business and technical requirements from our stakeholder interviews. Our Goal-Directed process for defining product requirements is described below.
Requirements Definition Using
Personas and Scenarios
As discussed briefly in Chapter 1, the translation from robust models to design solutions really consists of two major phases: Requirements Definition answers the broad questions about what a product is and what it should do, and Framework Definition answers questions about how a product behaves and how it is structured to meet user goals. In this section, we’ll discuss Requirements Definition in detail, followed by a discussion of the Framework Definition in Chapter 7. The methods described are based upon the persona-based scenario methodology developed at Cooper by Robert Reimann, Kim Goodwin, Dave Cronin, Wayne Greenwood, and Lane Halley.
10_084113 ch06.qxp 4/3/07 6:03 PM Page 116
116
Part I: Understanding Goal-Directed Design
The Requirements Definition process comprises the following five steps (which are described in detail in the remainder of this chapter):
1. Creating problem and vision statements
2. Brainstorming
3. Identifying persona expectations
4. Constructing context scenarios
5. Identifying requirements
Although these steps proceed in roughly chronological order, they represent an iterative process. Designers can expect to cycle through Steps 3 through 5 several times until the requirements are stable. This is a necessary part of the process and shouldn’t be short-circuited. A detailed description of each of these steps follows.
Step 1: Creating problem and vision statements
Before beginning the process of ideation, it’s important for designers to have a clear mandate for moving forward. While the Goal-Directed method aims to comprehensively define the product through personas, scenarios, and requirements, it is often useful at this point to define what direction these scenarios and requirements should be headed in. At this point in the process, we already have a sense of which users we’re targeting and what their goals are, but lacking a clear product mandate, there is still room for considerable confusion. Problem and vision statements provide just such a mandate and are extremely helpful in building consensus among stakeholders before the design process moves forward.
At a high level, the problem statement defines the purpose of the design initiative.8
A design problem statement should concisely reflect a situation that needs changing, for both the personas and for the business providing the product to the personas. Often a cause-and-effect relationship exists between business concerns and persona concerns. For example:
Company X’s customer satisfaction ratings are low and market share has diminished by 10% over the past year because users don’t have adequate tools to perform X, Y, and Z tasks that would help them meet their goal of G.
The connection of business issues to usability issues is critical to drive stakeholders’
buy-in to design efforts and to frame the design effort in terms of both user and business goals.
10_084113 ch06.qxp 4/3/07 6:03 PM Page 117
Chapter 6: The Foundations of Design: Scenarios and Requirements
117
The vision statement is an inversion of the problem statement that serves as a high-level design objective or mandate. In the vision statement, you lead with the user’s needs, and you transition from those to how business goals are met by the design vision:
The new design of Product X will help users achieve G by giving them the ability to perform X, Y, and Z with greater [accuracy, efficiency, and so on], and without problems A, B, C that they currently experience. This will dramatically improve Company X’s customer satisfaction ratings and lead to increased market share.
The content of both the problem and vision statements should come directly from research and user models. User goals and needs should derive from the primary and secondary personas, and business goals should be extracted from stakeholder interviews.
Problem and vision statements are useful both when you are redesigning an existing product and for new technology products or products being designed for unex-plored market niches, when formulating user goals and frustrations into problem and vision statements helps to establish team consensus and attention on the priorities of design activity to follow.
Step 2: Brainstorming
At the early stage of Requirements Definition, brainstorming assumes a somewhat ironic purpose. At this point in the project, we have been researching and modeling users and the domain for days or even months, and it is almost impossible to avoid having developed some preconceptions about what the solution looks like. However, we’d ideally like to create context scenarios without these prejudgments, and instead really focus on how our personas would likely want to engage with the product. The reason we brainstorm at this point in the process is to get these ideas out of our heads so that we can record them and thereby “let them go” for the time being.
The primary purpose here is to eliminate as much preconception as possible, allowing designers to be open-minded and flexible as they use their imagination to construct scenarios, and use their analytic minds to derive requirements from these scenarios. A side benefit of brainstorming at this point in the process is to switch your brain into “solution mode.” Much of the work performed in the Research and Modeling phases is analytical in nature, and it takes a different mindset to come up with inventive designs.
10_084113 ch06.qxp 4/3/07 6:03 PM Page 118
118
Part I: Understanding Goal-Directed Design
Brainstorming should be unconstrained and uncritical — put all the wacky ideas you’ve been considering (plus some you haven’t) out on the table and then be prepared to record them and file them away for safekeeping until much later in the process. It’s not necessarily likely any of them will be useful in the end, but there might be the germ of something wonderful that will fit into the design framework you later create. Karen Holtzblatt and Hugh Beyer describe a facilitated method for brainstorming that can be useful for getting a brainstorming session started, especially if your team includes nondesigners. 9
Don’t spend too much time on the brainstorming step; a few hours should be more than sufficient for you and your teammates to get all those crazy ideas out of your systems. If you find your ideas getting repetitious, or the popcorn stops popping, that’s a good time to stop.
Step 3: Identifying persona expectations
As we discussed in Chapter 2, a person’s mental model is their own internal representation of reality — the way they think about or explain something to themselves. Mental models are deeply ingrained and are often the result of a lifetime of experience. People’s expectations about a product and the way it works are highly informed by their mental model.
Returning to our discussion in Chapter 2, it’s absolutely critical that the represented model of the interface — how the design behaves and presents itself —
should match the user’s mental model as closely as possible, rather than reflecting the implementation model of how the product is actually constructed internally.
In order to accomplish this, we must formally record these expectations. They will be an imp
ortant source of requirements. For each primary and secondary persona, you must identify:
Attitudes, experiences, aspirations, and other social, cultural, environmental, and cognitive factors that influence the persona’s expectations
General expectations and desires the persona may have about the experience of using the product
Behaviors the persona will expect or desire from the product
How that persona thinks about basic elements or units of data (for example, in an e-mail application, the basic elements of data might be messages and people) Your persona descriptions may contain enough information to answer these questions directly; however, your research data will remain a rich resource. Use it to
10_084113 ch06.qxp 4/3/07 6:03 PM Page 119
Chapter 6: The Foundations of Design: Scenarios and Requirements
119
analyze how interview subjects define and describe objects and actions that are part of their usage patterns, along with the language and grammar they use. Some things to look for include:
What do the subjects mention first?
Which action words (verbs) do they use?
Which intermediate steps, tasks, or objects in a process don’t they mention?
(Hint: These might not be terribly important to the way they think about things.) Step 4: Constructing context scenarios
While all scenarios are stories about people and their activities, context scenarios are the most storylike of the three types we employ. The focus is on the persona’s activities, as well as her motivations and mental model. Context scenarios describe the broad context in which usage patterns are exhibited and include environmental and organizational (in the case of enterprise systems) considerations. 10
As we discussed above, this is where design begins. As you develop context scenarios, you should be focusing on how the product you are designing can best help your personas achieve their goals. Context scenarios establish the primary touch points that each primary and secondary persona has with the system (and possibly with other personas) over the course of a day or some other meaningful length of time.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 19
