Personas

Personas (Figure 5.8) are a documented set of archetypal people who are involved with a product or service. They're supposed to give designers a sense that they are designing for specific people, not just "the users," who, if ill-defined, can be twisted to serve any purpose. ("Of course the users will want to enter a password on every page!")

Figure 5.8. A sample persona. Personas turn "the users" into identifiable human beings.

Designers should devise personas from observing and talking to users. Personas are typically amalgams of multiple people who share similar goals, motivations, and behaviors. The differences between each persona must be based on these deep characteristics: what people do (actions or projected actions) and why people do them (goals and motivations).

What personas shouldn't be are users who have similar demographics. Focusing on demographics will provide market segments, not personas. The only time demographics really matter for personas is when those demographics directly affect user behavior. A 13-year-old will probably use a product differently than an 83-year-old. A rural peat farmer in Ireland might use a product differently than a Korean financial analyst in Seoul. But maybe notdemographics may not matter at all. In fact, using demographics could limit and hinder the usefulness of the personas. For products with millions of users, for example, a designer could end up with hundreds of personas, and such a large set is essentially useless.

To create a persona, designers find a common set of behaviors or motivations among the people they have researched. This set becomes the basis for the persona, which should be given a name, a picture, and a veneer of demographic data to make the persona seem like a real person.

For example, consider a design project related to airline travel. Designers have observed three sets of behavior: flying frequently for business, flying occasionally for pleasure, and flying habitually every fall and spring (the snow bird phenomenon). Each of these behaviors is tied to specific other behaviors while traveling, with different goals and motivations. The behaviors become the basis for three personas: Bob, the frequent flier; Susan, the vacationer; and Wilma, the snow bird.

Quotes pulled from the research are helpful for distinguishing and identifying personas ("I fly at least once a week"), as are simple titles ("The Frequent Flier"). The persona documents should clearly note the behaviors, motivations, and goals that differentiate one persona from another. Bob cares deeply about getting to his meeting or hotel on time, while Wilma is more relaxed about what happens after the flight.

For most projects, the number of personas should be smallanywhere from 1 to 7. After about 7 personas, remembering and distinguishing them becomes difficult (recall the Magical Number Seven rule from Chapter 3). Most important, it becomes difficult to design for such a large group. Imagine creating a mobile phone that will satisfy a dozen very different people. The debate that would go on among those people would make it difficult for the designer to accomplish anything. Unless you are designing for millions of users, you should consolidate personas to fewer than 7. While both designer and client will usually want the product or service to work for the largest possible group, 7 personas should be enough to cover 95 percent of the users. A product or service that is being designed to accommodate more personas likely isn't focused enough on the core behaviors that need to be addressed.

Once you have a set of personas, find a face for each. Pictures, more than anything else, will humanize personas and make them memorable. As long as the personas won't be made public, an online dating service like Yahoo Personals is an excellent place to find persona pictures. Personals contain (mostly) flattering pictures that can be browsed according to any combination of gender, location, age, ethnicity, and other factors.

Personas by themselves are fairly useless. They become useful only when the designer sets up scenarios and uses the personas to test features for appropriateness and utility. Designers can then ask themselves: Would this persona do this task? Could this persona do this task as it is designed?

Robert Reimann on Personas

courtesy of Robert Reimann

Robert Reimann is President of the Interaction Design Association (IxDA) and Manager of User Experience at Bose Corporation. He helped write the book on interaction designliterallywith Alan Cooper: About Face 2.0: The Essentials of Interaction Design.

How did the idea of personas come about?

The idea of personas, or tools like them, has been around for a long time. Many design, marketing, and usability professionals in the 80s and 90s made use of "user profiles" to help them visualize who their customers were, and to help them imagine what kind of needs and desires they might have in relation to products and services.

Alan Cooper, who coined the term "persona" for this type of tool, first did so in 1983, while designing and developing a software package called SuperProject for Computer Associates, and later did so for what eventually became Microsoft's Visual Basic.

Cooper's early personas were "primitive", in that they were based on loose, personal observations of a small number of individuals in particular roles. However, Cooper's fundamental insight was that these representative characters had goals and behaviors that could be served by products. By enumerating the most critical goals and including them as part of the persona description, Cooper developed a powerful design method: meet the persona's top goals with the product by designing for their behaviors, and the design is much more likely to be successful.

My own contribution to Cooper's persona methodology was to introduce more formal ethnographic field research as the data-gathering method for the information used to construct personas, and to (with Kim Goodwin) refine the persona goals into three types: experience goals, which describe how users wish to feel (or not to feel) when using a product; end goals, which describe what users actually want or need to accomplish with a product to meet their expectations; and life goals, which describe the broader aspirations of the persona in relation to the product, and thus help describe what the product means to the persona. It's this focus on goals and behavior patterns, combined with a scenario-based method of translating these requirements into design solutions, that makes Cooper's personas so unique and powerful.

What are personas good for?

Personas are terrific tools for understanding and communicating user behaviors, needs, desires, and contexts. They are extremely useful for:

1. Directing the product design. Persona goals and behaviors inform both the structure and behavior of a product and its interface.

2. Communicating design solutions to stakeholders. Using personas in storyboards and scenarios is a very effective way to tell the story of the product and helps highlight why design decisions were made as they were.

3. Building consensus and commitment around the design. Having a common language around which the team can communicate regarding priorities and features and tying each decision specifically to user benefits/consequences helps rally a team to work together to make the best possible product for its target users.

4. Measuring the design's effectiveness. Design choices can be tested against persona behaviors, contexts, and expectations while they are still on the whiteboard, far in advance of testing on prototypes or final products. The result is better quality earlier in the design process, which makes later refinements more manageable.

5. Contributing to nondevelopment efforts. The information captured in personas and storyboards can be of great interest and use to marketing, advertising, sales, and even strategic planning activities within companies.

What are the essential components of any persona?

The most important elements of any persona are the behavior patterns gathered via ethnographic research and analysis, and the goals that derive from them. Furthermore, it is important to understand each persona's priority as addressed in the design: for example, is it a primary persona (main design target), a secondary persona (served by an interface directed at the primary persona, but with some special additional requirements), or a persona that is not served by the product at all?. in addition to these components, a representative name, a picture, and a small amount of additional demographic information help make the persona seem real and engage designer and stakeholder empathy. Personas must seem like credible, real people to maximize their effectiveness as design and development tools.

Designers (and, indeed, businesses) can also use personas to set priorities. The persona that represents a majority of a product's users may not be the user that the organization values the most; other personas may make the organization more money, be more involved, use more features, and so on. Organizations can and should use personas to make strategic decisions.

While many find personas helpful, some designers don't care for them. For these designers, personas form an artificial barrier between the product and its users. Some projects, especially smaller ones, may not warrant a full set of personas. But for many designers, if their personas are based on research and focused on the right characteristics (behaviors, motivations, and goals), personas are a valuable tool.