April 2009

Volume 24 Number 04

Usability in Practice - The Power of Personas

By Dr. Charles B. Kreitzberg, Ambrose Little | April 2009

Contents

The Cognitive View
How to Create Personas
Why Personas Work so Well
Types of Inferences Personas Support
How Many Personas?
Connecting Personas to Screens
What Goes into a Persona
The Software View
Empathy
Clarifying What to Do and In What Order
Clarifying How to Do It
Communication
Shortcuts to Personas
Summary

THE COGNITIVE VIEW

Dr. Charles B. Kreitzberg

If you are designing a UI, you should consider creating personas to guide you. Personas are one of the basic tools of User Experience (UX) design. A persona is a description of a fictional person representing a user segment of the software you are developing. Of course, the word "fictional" applies to the person not the description; that should be as grounded in reality as possible.

Figure 1 shows an example of a simple persona developed for a financial institution. Bill (and his wife Sue) are fictitious composites developed from interviews conducted with the bank's customers. The interviews and other studies revealed that the bank's customers fell into a number of audience segments, each with its own goals, concerns and Internet usage habits. By creating a persona to represent the segment, it becomes easier to formulate design questions and answer them.

Persona creation is not an exact science and it can be difficult to verify how well a persona actually reflects the users. The fact that personas are created through an act of fiction has led some people to question their value entirely. Such criticism is valuable if it serves as a reminder that the personas are built from data that is, by its nature, incomplete and imperfect. But personas are nevertheless quite useful. Among their benefits, personas:

• Enable designers to make inferences about the needs and desires of audience segments.
• Serve to communicate user characteristics in a compact and easily understood way.
• Help keep stakeholders from changing the definition of audience segments to advance narrow interests.
• Put a face on the person for whom you are designing the UI.

Figure 1 A Simple Persona

How to Create Personas

Like most design elements, personas can be developed iteratively. And like most design elements, there are benefits to creating the personas collaboratively. Involving the stakeholders and other team members increases the accuracy of the persona and creates a level of awareness about the users that helps the team align around them. As people become familiar with the personas, they start talking about them as if they were actual people. When that happens, you have achieved a valuable focus.

Personas do not need to be complex to be useful. I typically begin by creating brief outlines of personas based on conversations with people who know the audience well, such as salespeople or customer service staff. I call these personas "assumptive personas" because they are not based on actual data.

Sometimes, that's all I have time or resources to do. But a better practice is to interview users and use the data collected to validate and refine the personas. In some cases, organizations perform extensive data gathering and analysis, using a variety of ethnographic research techniques, to create highly refined personas.

It's great to have really well researched personas, but even if you can whip together only a few simple assumptive personas, you will find that they are really useful design tools.

An excellent resource to help you understand personas and their construction is the book The Persona Lifecycle: Keeping People in Mind Throughout Product Design by John Pruitt and Tamara Adlin (Morgan Kaufmann, 2006).

Why Personas Work so Well

Personas tap into a fundamental human skill—the ability to make predictions about how other people will react based on mental models of them. One can often predict accurately how a close friend or family member will react to a particular event and decide how to act based on those inferences.

With close friends and family one has the history of experiences that make mental models rich and (usually) accurate. But one is also capable of making inferences about people based on relatively little data. Just looking at someone's attitude or posture as they walk can convince you to cross the street.

Of course, assumptions about how people are going to behave in a particular situation may not be correct and you often make errors of inference. Nonetheless, the ability to reliably predict the behavior of others is essential to survival, and humans are cognitively well-equipped to do so. That's what makes the persona so powerful. When you create models of your audience, you are able to make inferences about how they will react to the design choices you make.

Types of Inferences Personas Support

There are a number of ways that you can use personas to facilitate the design process. You can use them to:

• Help you choose among multiple design alternatives, selecting the one that your target user is most likely to prefer
• Help set the priorities for features under consideration, discriminating between what the user needs and what is a nice to have
• Decide what will engage a user
• Decide what will offend or cause distrust
• Determine if a single UI will serve all users or if you need to create multiple UIs

Of course, whenever possible, you should verify the design decisions you make through usability testing or other direct interaction with the user.

How Many Personas?

Most interactive products have multiple audience segments. This suggests that you should construct multiple personas. However, with too many personas, the process can get out of hand. As a rule of thumb, three or four personas are enough for most projects. If you find that you are creating more than five or six, stop and reconsider.

Many experts feel that you should designate one persona as the primary persona and treat the others as secondary. Design decisions would be made with the primary persona in mind and then tested (through a thought experiment) against the secondary personas. You can then add additional design to address any unmet needs of secondary personas. If you are unable to reconcile the primary and secondary personas, it might suggest that you need to consider distinct UIs.

Connecting Personas to Screens

The interaction between a user and an interactive product is governed by the intersection of two models. The first is the design model of the UI, which includes the navigation, interaction design, and information architecture. The second is the mental model the user brings to the interaction. Within the user's mental model is his or her knowledge of the system, of computing in general, and of the subject matter addressed by the product.

Every interaction begins with a goal on the part of the user. The user looks at the screen to determine what actions are possible, and selects the action that will get him or her closer to the desired goal. To the extent that the persona helps you understand the user's mental model, it can be an effective tool to guide design.

For each screen, you can enumerate the goals that your user might have when arriving there. You can then ask whether the design contains all the information that the user needs to process the available options and make the correct choice of action. If the answer is no, then you have a usability problem that requires redesign.

What Goes into a Persona

Many people feel that it is important for the persona to be rich with personal information that may not, at first, seem relevant to the product under development. The value of this, they argue, is that a rich persona enables you to tell stories about the user and this process makes the persona more valuable.

There is truth to this contention but you still need to decide what to include and what to leave out of the persona. A great tool is the Persona Creation and Usage Toolkit developed by George Olsen which you can download at Interaction by Design.

OIsen has developed a comprehensive—perhaps even daunting—list of all the factors you might consider including in your persona description. It's far too extensive to use as a whole, but I've found it to be an excellent starting point for thinking through the process.

Generally, I include the following elements in persona descriptions:

• Persona name and photo
• A quote or slogan that captures the personality
• Demographics (gender, age, marital status, family, where the person lives)
• Education
• Work
• Lifestyle factors and goals
• Computer competence and usage
• Values and attitudes

With these as a base, I try to include elements that make sense in the context of the product being developed. So, for example, if I am working on a banking system, I might include financial assets, financial sophistication, major expenses, attitudes toward money, and so forth. Less obviously, I might also consider issues of trust, how the person regards financial institutions, where he or she gets advice and similar emotional or attitudinal factors that might affect the design.

With the basic persona in place, I try to enrich it with personal elements such as likes and pet peeves. If I am doing interviews, I will often ask the respondents what TV shows they like, what magazines they read, and other personal data that helps flesh out the story.

Personas are powerful tools. They may seem too unscientific to some, but they help package user data into a form that can keep the team and stakeholders in alignment while supporting the design process.

THE SOFTWARE VIEW

Ambrose Little

There's a lot of value in just creating personas, assuming you get the right people involved in the process. In fact, it has been suggested that this process of building a persona provides the main value to organizations; however, that does not mean that personas are not valuable beyond the creation phase—you just have to know how and when to use them.

Most developers, if they are familiar with the concept of personas, picked it up from Alan Cooper's The Inmates Are Running the Asylum (Sams—Pearson Educatio, 2004). Cooper is by and large responsible for creating and popularizing the methodology of personas, as such, in software development, and in an interview he calls them the "bright light under which we do design… a powerful, malleable tool to help you look through the eyes of your users," which is as good a description as any I've seen.

In asking how to use personas, it is useful to also consider how not to use them. In their paper, "Quantitative Evaluation of Personas as Information," Christopher N. Chapman et al make the case that personas are not a valid source of actual information about real users. Their demonstration, based on generating persona-like substances from a database of real-life customer attributes, shows an extremely low correspondence in the generated persona-like substances to their source material (in that essentially none of them matched any one of the source customer attribute records). This is good as a sort of quantitative warning—don't be deceived into thinking your personas are real individuals, don't let them substitute for cases where you truly need to have some kind of quantitative input to inform your solutions. (See "Death to Personas! Long Live Personas!.") Don't use personas as substitutes for real data when you need real data—they are a derivative design asset, not actual customer data.

For example, if you needed to make a decision in your product or project as to what operating systems to support, you probably would not want to rely on a persona to inform that decision. Instead, you look at your customer data that tells you what percentage of your target customer base uses which of the various operating systems and make a decision based on the hard data. A persona might capture the use preference for an OS, but it is much better to base such quantitatively informed decisions on quantitative data, if you have it.

Personas are far more useful as qualitative tools that give you persistent insight into how you design solutions as well as what goes into your solutions. Donald Norman, one of the most well known human-centered design gurus, put it this way: "[personas] only need to be realistic, not real, not necessarily even accurate (as long as they accurately characterize the user base)." He identifies two core uses of personas: for communication and for empathy, which seems pretty spot on to me. (See "Ad-Hoc Personas & Empathetic Focus.")

Empathy is about as squishy as it gets and probably seems a bit foreign if you are accustomed to thinking in terms of functional requirements, but empathy is a core value if you want to make something that is good for the people who are going to use it. It's all about putting yourself metaphorically in their shoes.

If you're thinking about what functionality to include, personas can help. They can also help you prioritize the features. If you're thinking about how your target audience would want to achieve a particular goal or task, personas can be an indispensible tool. Even on discrete interfaces, you can use personas to help you both imagine how they should be designed as well as double-check your design against what your personas would want.

Clarifying What to Do and In What Order

A concrete way to include personas in your process is to have your stakeholders prioritize your personas and use that to create a weighted prioritization of capabilities in your solution, as Figure 2 shows.

This simple table illustrates that the View Item capability is far more important to the solution than the Place Order—from the target audience's perspective. The weightings were established beforehand, probably through the input of marketing, sales, and product management (the business stakeholders). It is important to note that this is not the full picture in prioritizing; the needs and goals of the business itself are not represented.

For instance, it is highly likely that the Place Order capability must be implemented for it to be a viable solution for the company to fund. Both the needs of the business and those of the user should be balanced to create a harmonious solution. (And if you can't find harmony, the solution probably won't be successful, which further illustrates the value of personas in simply validating whether or not to pursue solution ideas.)

The core idea here is that you are using personas to consistently think through and validate the various aspects of the development cycle from the perspective of your target audience. To come to the understanding that Elizabeth values viewing items as a must-have, you have to actually put yourself in her shoes and think about how much she would value that capability. This is far superior to a business analyst, project manager, or even developer generically trying to put a value on the capability using the same scale (which I've observed many times in my career). And it can be used to prioritize bug fixes as well, which again would likely be far more realistic prioritization than a general sense of urgency or severity.

Clarifying How to Do It

Another example of how personas can be used is to think through how a persona might want to use the software. This is especially useful if you are doing something that is new or trying to improve an existing solution or, of course, trying to differentiate based on UX. In fact, even before you get to prioritizing, personas can help you to correctly formulate what to build—instead of starting from a list of competitive features, functional requirements, formal use cases, and the like (or if you already have those, it's not too late; they can be reformulated in a similar way), you start by reframing the question of what to build in terms of the goals and motivations of your personas.

These are two key aspects of personas—they both do more than individual attributes and preferences to help you really gain empathetic insight. If you can stop and ask yourself why the person would want to do something with your solution and what they are trying to achieve, it goes a long way toward the proper focus.

Similarly, if you find yourself in trouble, which happened to me recently, where you have tons of prickly issues poking out of your design, it may just be that you need to zoom out and attack the problem anew from your persona's perspective. Sometimes it's hard to break old ways of thinking about design, and using personas can help you reformulate your approach. In my case, doing this helped me to see that we needed to somewhat dramatically alter our approach in terms of presenting essentially the same functionality to our target audience.

The trick here is not so much using some formula or technique but rather in changing how you formulate your understanding of how to build what you need to build.

Communication

Unless you are the sole individual involved in the creation of your solution, then personas can be a great tool to further refine a common language and understanding of what it is you're going about. One of the core ideas in domain-driven design is the ubiquitous language, and personas can help you better understand both the domain and the language that those in the domain use in order to help get everyone on the same page.

The research that goes into forming personas usually happens early in the process—people are busy and can spare only so much time to provide input in the form of interviews, and so forth. The real people are not avilable later on, but the personas are always available everywhere they need to be.

In short, they are about the best stand-in you can get when talking to real people isn't an option, and sometimes they can be better because they are not susceptible to moods or quirky, unrepresentative opinions (prejudices) that might wrongly skew the answer. Of course, that doesn't make them better all the time, either, since they rely on your interpretation of what the answer would be.

In fact, the need for interpretation can be a good thing. It can stimulate more critical thinking to dialectically come to an agreement on what to do or how to do it. This probably would not occur if the team were relying on an individual who is the undisputed representative of the customer.

And even in cases where the team members are committed to human-centered design, personas can help explain what might otherwise appear to be dictatorial specifications. I've seen this happen more than once, where a design specification was questioned because it didn't make sense to some people on the team. They were looking at it from their own, seemingly intuitive perspective, but the solution wasn't being built for them. The personas provide a known, concrete reference point to explain why the spec is the way it is, which takes the focus of the discussion away from what makes sense to individual team members (or what they prefer) to what makes sense for the people you are building for. And sometimes, the questioning of a requirement or spec comes from the perspective of a persona, and again, that dialectic based on differing interpretations will lead to a better solution than either individual would have proposed on their own.

Figure 3 Persona-based Story

A concrete example of how you can use personas to communicate is via scenarios and stories. "Scenarios" is a pretty overloaded term, so let me be clear on my meaning. A scenario is a descriptive narrative of one or more coherent interactions between a person (preferably a persona) and a product in a specified context from which one can derive design implications. Scenarios focus on how a person experiences the software without specifying the design in detail; that is, they provide the relevant human-oriented perceptions and actions for how a design should work. This is as opposed to what I'd call a "story," which is an overarching, coherent narrative that provides the background for scenarios, with particular focus on needs, goals, and desires. Stories provide more of the why—the human motivations.

You'd start with a story, based on your persona, and then break that out into scenarios, which can directly be used to design your solution and then to verify and validate your design. It can map more or less to goals and interactions/tasks/activities, where the goal provides the context and motivating factor for the story, and the scenarios map more or less to the particular interactions. Figure 3 shows an example of a story in a hypothetical solution.

This is a screen shot from a tool called Scrivener, which has a nifty index card view of document sections. I use that view for these purposes to keep the stories and scenarios short and to the point—they should be concise because busy people need to read and use them. Figure 4 shows some possible scenarios in this overall story.

Figure 4 Persona-based Scenarios

These scenarios cover discrete but coherent interactions from the persona's perspective (Sandra's). The story is a known, based on a real goal that the persona has. The scenarios are where your imagination comes into play—how would Sandra expect to be able to achieve her goal with the solution is the question, and the answer is described without specifying anything more than a narrative of what Sandra does. You see the story carried through from one scenario to the other, and yet you could conceive of these interactions on their own—a starting point, some interaction, and a coherent end point that can be the basis for further action.

Notice that these scenarios are careful not to specify how the interactions materialize in the UI. The reason for this is twofold: first, you don't want to prematurely constrain your UI design—you should be open to iterating over several possible UI solutions to support the interactions (as you should be open to iterating the scenarios themselves), and second, it is far more efficient and effective to design the UI in terms of the UI (with wireframes, mockups, prototypes, and so on.).

You can imagine that the same story and scenarios could be derived simply from user research or from a detailed set of functional or business requirements. You can adapt where such scenarios fit based on your processes, but the key is that they help you to think through how best to design your solution with minimal investment.

Shortcuts to Personas

Figure 5 Persona Shortcuts (Images Blurred Intentionally)

Finally, one aspect of communication, as Charlie covered, is how to communicate the personas themselves. There are many neat ways, and depending on your background, it may take some overcoming of prejudices, i.e., having posters, cards, cardboard cutouts, action figures, and other real, physical objects can very probably be more effective to communicate them and keep them top of mind than, e.g., a digital version like a Word doc or PowerPoint presentation that just sits out on SharePoint. Devs tend to want a technology solution for everything, but with design, including personas, it is often best to prefer a non-technical solution.

However, even if you have these physical artifacts, many folks work in multiple environments (in a coffee shop, at home, wherever) so that you don't always have those around. In such cases, having a backup digital copy can help, and I would suggest keeping a referent to them on your desktop, as shown in Figure 5.

This has the dual benefit of both providing a ready link to reference a digital persona document as well as keeping the personas themselves (image and name) top of mind. It's easy to do, too—just make a shortcut and change the icon to a cropped headshot of your personas. Just a simple way to make personas more usable if you are a traveling type.

Summary

In this installment, we took somewhat detailed tour of personas. First, we covered how to make them—the processes and techniques involved in developing, validating, and maturing the personas themselves, which has a big benefit to the whole team involved in getting a much better understanding of whom the solution is being developed for.

Then we discussed some different uses of personas, how not to use them, as well as how to—chiefly to gain empathy to inform what and how you build so that it makes sense for your target audience as well as a valuable communication tool to keep team members on the same page, speaking the same language, and collaborating in terms of people rather than in terms of technical or hierarchical terms.

For more persona information, see Persona Resources on GUIUI.com and Example Tester Personas on MSDN.

Send your questions and comments for Charlie and Ambrose to magux@microsoft.com.

Dr. Charles Kreitzberg is CEO of Cognetics Corporation (www.cognetics.com), which offers usability consulting and user experience design services. His passion is creating intuitive interfaces that engage and delight users while supporting the product's business goals. Charles lives in Central New Jersey where he moonlights as a performing musician.

Ambrose Little lives with his wife and four children in central New Jersey. He's been designing and developing software for more than 10 years and is honored to be an INETA speaker and Microsoft MVP. Lately, he's shifted from technical design to designing for people and is now a user experience designer for Infragistics.