Perfecting Your Personas

by Kim Goodwin

A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns you understand very well—you can satisfy the broader group of people represented by that archetype.

Personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few (very few!) fictional personal details to bring the persona to life. For each product, or sometimes for each set of tools within a product, there is a small set of personas, one of whom is the primary focus for the design. In the case of enterprise products that touch multiple roles, you may have several primary personas who each get a unique interface.

It’s easy to assemble a set of user characteristics and call it a persona, but it’s not so easy to create personas that are truly effective design and communication tools. If you have begun to create your own personas, that’s great. This article provides a few tips on avoiding the most common pitfalls of persona creation; my UIE Roadshow seminar will provide even more.

Personas Represent Behavior Patterns, Not Job Descriptions

Although tasks are an important part of understanding users, a good persona description is not a list of tasks or duties; it’s a narrative that describes the flow of someone’s day, as well as their skills, attitudes, environment, and goals. A persona answers critical questions that a job description or task list doesn’t, such as: Which pieces of information are required at what points in the day? Do users focus on one thing at a time, carrying it through to completion, or are there a lot of interruptions? Why are they using this product in the first place?

Although you will sometimes see a one-to-one correlation between personas and job descriptions when you have a very narrow, highly specialized role, this is usually not the case. Skill level, environment, and simple differences in how people think can mean that two people who seem to have the same job approach things very differently. In some cases there will be multiple personas with the same job description; in others, a single persona can represent people with a wide range of jobs because the tasks and goals are not unique to a specific job. If you were creating software used by call center agents, for example, you might have an experienced agent persona who is very familiar with the product, as well as an inexperienced agent who needs more prompts and written information. If, on the other hand, you were designing an e-mail application, one persona could represent people with hundreds of very different job descriptions, as long as they all shared similar goals and behavior patterns related to communication.

Keep Your Persona Set Small

If you’ve ever read a book or watched a movie with an enormous cast of characters, you may have found it hard to remember who was related to whom, who said what, and so on. You probably didn’t feel like you knew any of the characters very well. If you were designing a product for such a large cast of characters, could you predict how so-and-so’s cousin (whose name you forget) would behave in a certain situation? Probably not. That’s why a large set of personas is problematic—the personas all blur together.

The good news is that you don’t need a cast of thousands. Ideally, you should have only the minimum number of personas required to illustrate key goals and behavior patterns. There’s no magic number, but if you’re designing a consumer product and you have a dozen personas, then you may be making distinctions that aren’t very important. For example, if you were creating an electronic family calendar, your persona set might include a career mom, a stay-at-home mom, a career dad, and a teenager. If the career mom has the same needs as the career dad, and also does all the family management the stay-at-home mom does, you may be able to eliminate both the dad and stay-at-home mom personas. The important distinctions among personas are behavioral, not demographic.

Your Marketing and Sales Targets May Not Be Your Design Targets

Many product managers and executives are surprised when there isn’t a direct correlation between market segments and personas. The people who bring in the most revenue may not be the best design targets. If you were designing an in-flight entertainment system, a frequent business traveler—every airline’s most valued customer—would be a tempting design target. A business traveler would actually make a poor design target, though, because she would be too familiar with flying and with using computers and other gadgets. If you design for the business traveler, the retired bricklayer going to see his grandchildren won’t be able to use the system. If you design for the bricklayer, you may need to add a little something extra to satisfy the business traveler, but the bulk of the interaction will satisfy them both.

Add Life to the Personas, But Remember They’re Design Tools First

Sometimes it’s easy to focus too much on a persona’s biography. Personal details can be fun to come up with, but if there are too many of them they just get in the way. To avoid this problem, focus first on the behavior patterns, goals, environment, and attitudes of the persona—the information that’s critical for design—without adding any personality.

Once you have the critical design information, add just one or two personal details, such as what your persona does after work (she goes home to watch old movies with Claude, her cat), or what personal touches there are in her workspace. You can also add life to the persona by using environmental details to reinforce important characteristics. For example, if someone tends to be incredibly busy at work, don’t just say he’s incredibly busy; instead, say there’s a sandwich on his desk that he’s been trying to find time to eat for three hours. Without a little bit of personality, personas can easily turn into generic users instead of precise design targets.

Use the Right Goals

Each persona should have three or four important goals that help focus the design. Keep in mind that goals and tasks are different: tasks are not ends in themselves, but are merely things we do to accomplish goals. Not just any goals will do, though, so it’s important to understand which types will help you make design decisions.

Life goals are only occasionally useful in design, and when they are, it’s because they’re directly relevant to the domain of the product. For example, “retire by age 45” would be of little use if you were designing a word processor, mobile phone, or PDA, but it may offer valuable insight when you’re designing a financial planning tool.

Experience goals describe how the persona wants to feel when using a product; having fun and not feeling stupid are experience goals. Not every persona needs an experience goal; in most persona sets, there is one persona who represents people with a lot of anxiety about technology. One of this person’s goals is to avoid feeling stupid. Other experience goals might center on the product domain. A persona using an online banking site, for example, might want to feel confident that his transactions are secure. However, if you’re doing custom visual design rather than, say, a standard Windows look, experience goals can help you target the color, type, and style of visual elements so they convey the right message. Our online banking persona might not feel so secure using a site that’s orange and purple and uses funky type, so navy blue and a crisp, simple font would be a better choice.

Most persona goals should be end goals that focus on what the persona could get out of using a well-designed product or service. End goals may involve the work product that results from using the tool. For example, a graphic designer using a layout tool might want to create an award-winning ad. End goals can also involve indirect benefits from using a product. If a manager wants to be more proactive, a better spreadsheet tool can help her achieve this goal if it makes her more efficient.

Personas Must Be Specific to the Design Problem

Organizations with more than one product often want to use the same personas over and over (“We have a salesperson persona already—why can’t we use her for the spreadsheet as well as the contact management software?”). Unfortunately, this doesn’t work because effective personas must be context-specific—they should be focused on the behaviors and goals related to the specific domain of a product. A persona’s behaviors and goals related to contact management have very little to do with those related to manipulating financial data. You could keep the same name and personal details, but you’d have to throw away the rest of the persona and start over. It’s better to start with a new set of personas for each product. (There are rare exceptions to this, such as when two products are incredibly similar, or when they’re two tools that get used together on related tasks).

Published here on January 13, 2005.