We have also found it useful to create photographic collages for each persona to convey more emotional and experiential forces that drive the persona (see Figure 5-5).
Numerous small images juxtaposed have the potential to convey things that are difficult to describe in words. There are also times that we find it useful to create models of the personas’ environments (for example, in the form of a floorplan).
Again, this helps to make these environmental considerations more tangible.
When creating such communication aides, it’s important to remember that personas are design and decision-making tools, not an end in themselves. While there can be a lot of power in creating a holistic image of a persona, too much embellish-ment and theatre can run the risk of making personas seem a fluffy waste of time.
This can ultimately reduce their usefulness as user models.
Figure 5-5 Collages such as this, combined with carefully written narratives, are an effective way to convey the emotional and experiential aspects of a persona.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 104
104
Part I: Understanding Goal-Directed Design
Step 7: Designate persona types
By now, your personas should feel very much like a set of real people whom you know. The final step in persona construction finishes the process of turning your qualitative research into a powerful set of design tools.
Design requires a target — the audience upon whom the design is focused. Typically, the more specific the target, the better. Trying to create a design solution that simultaneously serves the needs of even three or four personas can be quite an overwhelming task.
What we then must do is prioritize our personas to determine which should be the primary design target. The goal is to find a single persona from the set whose needs and goals can be completely and happily satisfied by a single interface without dis-enfranchising any of the other personas. We accomplish this through a process of designating persona types. There are six types of persona, and they are typically designated in roughly the order listed here:
Primary
Secondary
Supplemental
Customer
Served
Negative
We discuss each of these persona types and their significance from a design perspective in the following sections.
Primary personas
Primary personas represent the primary target for the design of an interface. There can be only one primary persona per interface for a product, but it is possible for some products (especially enterprise products) to have multiple distinct interfaces, each targeted at a distinct primary persona. For example, a health-care information system might have separate clinical and financial interfaces, each targeted at a different persona. It should be noted that we use the term interface in an abstract sense here. In some cases, two separate interfaces might be two separate applications that act on the same data; in other cases, the two interfaces might simply be two different sets of functionality served to two different users based upon their role or customization.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 105
Chapter 5: Modeling Users: Personas and Goals
105
A primary persona will not be satisfied by a design targeted at any other persona in the set. However, if the primary persona is the target, all other personas will not, at least, be dissatisfied. (As you’ll see below, we will then figure out how to satisfy these other personas without disturbing the primary.)
DESIGN
Focus the design for each interface on a single primary persona.
principle
Choosing the primary persona is a process of elimination: Each persona must be tested by comparing the goals of that persona against goals of the others. If no clear primary persona is evident, it could mean one of two things: Either the product needs multiple interfaces, each with a suitable primary persona (often the case for enterprise and technical products), or the product is trying to accomplish too much. If a consumer product has multiple primary personas, the scope of the product may be too broad.
Secondary personas
A secondary persona is mostly satisfied with the primary persona’s interface but has specific additional needs that can be accommodated without upsetting the product’s ability to serve the primary persona. We do not always have a secondary persona, and more than three or four secondary personas can be a sign that the proposed product’s scope may be too large and unfocused. As you work through solutions, your approach should be to first design for the primary, and then adjust the design to accommodate the secondary.
Supplemental personas
User personas that are not primary or secondary are supplemental personas. Their needs are completely represented by a combination of primary and secondary personas and are completely satisfied by the solution we devise for one of our primaries. There can be any number of supplemental personas associated with an interface. Often political personas — the ones added to the cast to address stakeholder assumptions — become supplemental personas.
Customer personas
Customer personas address the needs of customers, not end users, as discussed earlier in this chapter. Typically, customer personas are treated like secondary personas. However, in some enterprise environments, some customer personas may be primary personas for their own administrative interface.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 106
106
Part I: Understanding Goal-Directed Design
Served personas
Served personas are somewhat different from the persona types already discussed.
They are not users of the product at all; however, they are directly affected by the use of the product. A patient being treated by a radiation therapy machine is not a user of the machine’s interface, but she is very much served by a good interface. Served personas provide a way to track second-order social and physical ramifications of products. These are treated like secondary personas.
Negative personas
Negative personas are used to communicate to stakeholders and product team members that there are specific types of users that the product is not being built to serve. Like served personas, they aren’t users of the product. Their use is purely rhetorical: to help communicate to other members of the team that a persona should definitely not be the design target for the product. Good candidates for negative personas are often technology-savvy early adopter personas for consumer products and IT specialists for business-user enterprise products.
Other Models
Personas are extremely useful tools, but they are certainly not the only tool to help model users and their environment. Holtzblatt and Beyer’s Contextual Design provides a wealth of information on the models briefly discussed here.
Workflow models
Workflow or sequence models are useful for capturing information flow and decision-making processes inside organizations and are usually expressed as flow charts or directed graphs that capture several phenomena:
The goal or desired outcome of a process
The frequency and importance of the process and each action
What initiates or prompts the execution of the process and each action
Dependencies — what must be in place to perform the process and each action, as well as what is dependent on the completion of the process and each action
People who are involved and their roles and responsibilities
Specific actions that are performed
Decisions that are made
09_084113 ch05.qxp 4/3/07 6:02 PM Page 107
Chapter 5: Modeling Users: Personas and Goals
107
Information that is used to support decisions
What goes wrong — errors and exception cases
How errors and exceptions are corrected
A well-developed persona should capture individual workflows, but workflow models are still necessary for capturing interp
ersonal and organizational workflows. Interaction design based primarily on workflow often fails in the same way as
“implementation model” software whose interaction is based primarily on its internal technical structure. Because workflow is to business what structure is to programming, workflow-based design typically yields a kind of “business implementation model” that captures all of the functionality but little of the humanity.
Artifact models
Artifact models represent, as the name suggests, different artifacts that users employ in their tasks and workflows. Often these artifacts are online or paper forms. Artifact models typically capture commonalities and significant differences between similar artifacts for the purpose of extracting and replicating best practices in the eventual design. Artifact models can be useful later in the design process, with the caveat that direct translation of paper systems to digital systems, without a careful analysis of goals and application of design principles (especially those found in Part II of this book), usually leads to usability issues.
Physical models
Physical models, like artifact models, endeavor to capture elements of the user’s environment. Physical models focus on capturing the layout of physical objects that comprise the user’s workspace, which can provide insight into frequency of use issues and physical barriers to productivity. Good persona descriptions will incorporate some of this information, but it may be helpful in complex physical environments (such as hospital floors and assembly lines) to create discrete, detailed physical models (maps or floorplans) of the user environment.
Personas and other models make sense out of otherwise overwhelming and confusing user data. Now that you are empowered with sophisticated models as design tools, the next chapter will show you how to employ these tools to translate user goals and needs into workable design solutions.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 108
108
Part I: Understanding Goal-Directed Design
Notes
1. Cooper, 1999
2. Constantine and Lockwood, 2002
3. Grudin and Pruitt, 2002
4. Mikkelson, N., and Lee, W. O., 2000
5. Grudin and Pruitt, 2002
6. Grudin and Pruitt, 2002
7. Constantine and Lockwood, 1999
8. Beyer and Holtzblatt, 1998
9. Dillon, 2001
10. Goodwin, 2001
11. Goodwin, 2002, 2002a
10_084113 ch06.qxp 4/3/07 6:03 PM Page 109
6
The Foundations of Design:
Scenarios and Requirements
In the two previous chapters, we talked about how to gather qualitative information about users and create models using that information. Through careful analysis of user research and synthesis of personas and other user models, we create a clear picture of our users and their respective goals. This brings us, then, to the crux of the whole method: how we use this understanding of people to create design solutions that satisfy and inspire users, while simultaneously addressing business goals and technical constraints.
This chapter describes the first part of a process for bridging the research-design gap. It employs personas as the main characters in a set of techniques that rapidly arrive at design solutions in an iterative, repeatable, and testable fashion. This process has four major activities: developing stories or scenarios as a means of imagining ideal user interactions, using those scenarios to define requirements, using these requirements in turn to define the fundamental interaction framework for the product, and filling in the framework with ever-increasing amounts of design detail. The glue that holds the processes together is narrative: using personas to create stories that point to design.
10_084113 ch06.qxp 4/3/07 6:03 PM Page 110
110
Part I: Understanding Goal-Directed Design
Scenarios: Narrative as a Design Tool
Narrative, or storytelling, is one of the oldest human activities. Much has been written about the power of narrative to communicate ideas. However, narrative is also one of our most powerful creative methods. From a very young age, we are accustomed to using stories to think about possibilities, and this is an incredibly effective way to imagine a new and better future for our users. Imagining a story about a person using our product leverages our creativity to a greater power than when we just imagine a better form factor or configuration of screen elements. Further, because of the intrinsically social aspect of narrative, it is a very effective and compelling way to share good ideas among team members and stakeholders. Ultimately, experiences designed around narrative tend to be more comprehensible and engaging for users because they are structured around a story.
Evidence of the effectiveness of narrative as a design tool is all around us. The famous Disney Imagineers would be lost without the modern-day myths they use as the foundation for the experiences they build. Much has been written about this idea: Brenda Laurel explored the concept of structuring interaction around dramatic principles in her 1991 book Computers as Theater, where she urges us to
“. . . focus on designing the action. The design of objects, environments, and characters is all subsidiary to this central goal.”1 John Rheinfrank and Shelley Evenson also talk about the power of “stories of the future” for developing conceptually complex interactive systems,2 and John Carroll has created a substantial body of work about scenario-based design, which we discuss later in this chapter.
Narrative also lends itself to effective visual depictions of interactive products.
Because interaction design is first and foremost the design of behavior that occurs over time, a narrative structure, combined with the support of fast and flexible visualization tools (such as the humble whiteboard), is perfectly suited for motivating, envisioning, representing, and validating interaction concepts.
Interaction design narratives are quite similar to the comic-book-like sequences called storyboards that are used in the motion picture industry. They share two significant characteristics: plot and brevity. Just as storyboards breathe life into a movie script, design solutions should be created and rendered to follow a plot — a story. Putting too much detail into the storyboards simply wastes time and money and has a tendency to tie us to suboptimal ideas simply because drawing them consumes significant resources.
In the initial requirements definition phase we are free to focus only on the “plot points,” allowing us to be fluid as we explore design concepts. Because they are enough to convey the action and the potential experience, many millions of Hollywood dollars
10_084113 ch06.qxp 4/3/07 6:03 PM Page 111
Chapter 6: The Foundations of Design: Scenarios and Requirements
111
have been invested on the basis of simple pencil sketches or line drawings. By focusing on the narrative, we are able to quickly and flexibly arrive at a high-level design solution without getting bogged-down by the inertia and expense inherent to high-production-value renderings (though such renderings are certainly appropriate once a working design framework is in place).
Scenarios in design
In the 1990s, substantial work was done by the HCI (Human-Computer Interaction) community around the idea of use-oriented software design. From this work came the concept of the scenario, commonly used to describe a method of design problem solving by concretization: making use of a specific story to both construct and illustrate design solutions. These concepts are discussed by John Carroll, in his book, Making Use:
Scenarios are paradoxically concrete but rough, tangible but flexible . . . they implicitly encourage “what-if?” thinking among all parties. They permit the articulation of design possibilities without undermining innovation . . . Scenarios compel attention to the use that will be made of the design product. They can describe situations at many levels of detail, for many different purposes, helping to coordinate various aspects of the design project.3
Carroll’s use of scenario-based design focuses on descr
ibing how users accomplish tasks. It consists of an environmental setting and includes agents or actors that are abstracted stand-ins for users, with role-based names such as Accountant or Programmer.
Although Carroll certainly understands the power and importance of scenarios in the design process, we’ve found two shortcomings with scenarios as Carroll approaches them:
Carroll’s concept of the actor as an abstracted, role-oriented model is not sufficiently concrete to provide understanding of or empathy with users. It is impossible to design appropriate behaviors for a system without understanding the users of the system in specific detail.
Carroll’s scenarios jump too quickly to the elaboration of tasks without considering the user’s goals and motivations that drive and filter these tasks. Although Carroll does briefly discuss goals, he refers only to goals of the scenario. These goals are circularly defined as the completion of specific tasks. In our experience, user goals must be considered before user tasks can be identified and prioritized. Without addressing the motivation of human behavior, high-level product definition can be difficult and misguided.
10_084113 ch06.qxp 4/3/07 6:03 PM Page 112
112
Part I: Understanding Goal-Directed Design
The missing ingredient in Carroll’s scenario-based design methods is the use of personas. A persona provides a tangible representation of the user to act as a believable agent in the setting of a scenario. In addition to reflecting current behavior patterns and motivations, personas enable the exploration of how user motivations should inflect and prioritize tasks in the future. Because personas model goals and not simply tasks, the scope of the problems addressed by scenarios can be broadened to include those related to product definition. They help answer the questions,
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 18
