Start with the right kind of research

Personas are based primarily on ethnographic user data. Ethnographic techniques are valuable because they assume that an interview subject's attitudes and behaviors are so habitual as to be unconscious. Rather than asking users what they want, it is more effective to focus on what users do, what frustrates them, and what gives them satisfaction. By combining interviewing with direct observation—preferably in the actual usage context—you can get a lot of data very quickly. Observation also helps minimize dependence on users' self-reported behavior, which is often inaccurate.

A dozen hour-long interviews are usually sufficient for defining a simple consumer product, though it can take several dozen for a complex enterprise application. You'll know you can stop interviewing when you can predict how each user will respond; this means patterns are beginning to emerge. If you have the time and budget, you can verify your findings with quantitative surveys or other techniques, but these cannot replace direct observation.

Identify behavioral patterns from the data

Once you finish interviewing, list all of the behavioral variables, i.e., ways in which interviewee behavior differed. Most variables can be represented as ranges with two ends. In an online shopping domain, for example, you might have variables such as frequency of shopping, degree of enjoyment, and price vs. service orientation. There may also be demographic variables that seem to affect behavior, such as age or technical skill. Be wary of focusing on demographics during persona creation, since behavioral variables will have far more impact on the design. Note that if you are doing an enterprise application, each role* will have its own set of behavioral and demographic variables. Although the number of variables will differ from project to project, it's typical to find 20 or so variables per role.

Next, map each interviewee against the appropriate set of variables. It doesn't matter whether user #2 is 45% or 50% of the way up the scale; what matters is where he appears relative to the other interviewees. When you are finished, look for people who clump together across multiple variables. When you have found a set of people clustering across six or eight variables, there's a good chance that you have found a major behavior pattern that will form the basis of a persona. Give each major pattern a brief description, such as "the bargain-hunter" or "the impulse-buyer." For very specialized roles, you may find only one major pattern, but for consumer applications or broader roles, you will typically find two or three patterns.

Beware of defining false patterns, though. There is a logical connection if people who are very price-conscious also spend a lot of time comparison-shopping, but there may not be any connection if interviewees who are very price-conscious all happen to have cats.

Assemble your persona descriptions around behavioral patterns

For each pattern, add details based on your data. Describe the potential usage environment, typical workday (or other relevant time period), current solutions and frustrations, relevant relationships with others, and goals. Avoid the temptation to add a lot of irrelevant personal detail; if you're designing an email tool, it doesn't matter that your persona wants to be an actress. One or two bits of personality can bring an otherwise dull persona to life, but too much biography will be distracting and will make the persona less credible as an analytical tool. If every aspect of the description can't be tied back to real data, it's not a persona—it's a creative writing project that should not be used for making critical design and business decisions.

Describe your personas in narrative form

A list of bullet points might contain the same essential facts, but since personas do double duty as communication tools, a narrative is far more powerful in conveying the persona's attitudes, needs, and problems. The Cliff's Notes edition may convey the basic ideas, but it will never be as compelling as the story. Avoid writing novels, though; a typical persona description is no longer than this article. The persona does not need to contain every detail since the people who did the interviewing are (hopefully) the people doing the design, and no one else has the time or patience for that much detail.

Avoid false precision

Precision indicates a degree of certainty in the results; if you write down a laboratory measurement as "1.01 centimeters," it implies that you actually measured hundredths of centimeters. The same is true of personas; if you provide a detailed description, it implies that you observed that level of detail in your research. In cases where you have little or no research, there's no point in trying to "make up" a set of personas. Instead, you can create "provisional personas," which are a sketchy best guess at user needs and characteristics. They typically consist of a few goals and one or two other characteristics, but no detail or narrative. It's important that all team members understand these are useful thought experiments, but are not real personas because they are not based on data.

Build your product on the best foundation

The whole point of creating personas is to get past our personal opinions and presuppositions to understand what users truly need. If we invent fictitious model users and call them personas, we'll just have the same old problems with the development process packaged up in a new way. If you truly want to build a better product, create your personas based on real data, and use them in conjunction with business goals and good design principles to guide your solutions.