“Alan Cooper popularized personas as a valuable design tool, but many people who adopted them failed to take into account the context of Cooper’s practice, which had fairly specific needs.”
How can something that feels so right be so wrong? Personas ought to be one of the defining techniques in user-focused design. Lots of professionals create them, yet too often the personas end up being too vague to guide a product’s focus. They often lack the detail to be useful in guiding low-level design trade-offs. And, as typically done, personas have been too narrowly focused. They often aren’t helpful in identifying the information a user needs or creates. Nor do they have much to say about the sensory and emotional aspects of user experience–the sorts of factors that cause consumers to lust after products like Apple’s iPod.
As a result, personas have unfortunately become more of a check-off item than a useful tool, and many personas get put on the shelf once they are written. So how did we get here?
Alan Cooper popularized personas as a valuable design tool, but many people who adopted them failed to take into account the context of Cooper’s practice, which had fairly specific needs. Cooper’s company most often dealt with enterprise clients who hadn’t yet bought into the value of user experience. As a consultant, he had a strong need to persuade internal development teams to pay attention to users, so, not surprisingly, he emphasized both the narrative and empathy-building aspects of personas.
Cooper’s goals for personas were to:
- Allow the development team to live and breathe the user’s world.
- Allow the team to filter out personal quirks and focus on motivations and behaviors typical of a broad range of users, while still relating to users as individuals.
These are good goals, but incomplete. Compounding the problem was that Cooper’s seminal The Inmates Are Running the Asylum talked at length about why personas were important, but didn’t provide many details about how create them. So people improvised, often with unsatisfying results.
My own frustrations with personas came as I tried to apply them to a different context. While Cooper mostly worked with enterprise clients, with developers and managers who were reluctant to consider users, I’ve usually had a hand in building the sites I design, even as an outside developer and consultant. Likewise, Cooper’s clients typically were developing internal applications where efficiency was main goal, so it’s not surprising that his approach was task-focused. But as I’ve argued previously, other types of projects are predominantly information-oriented and immersion-oriented–or some mix among the three.
Much of my own work has been on consumer-facing websites and interactive products where functionality was only part of the focus. When I was developing movie promotion sites, the studios obviously hoped the websites would “put butts in seats.” But people don’t visit movie promotion sites to find out where the film is playing. Nor–if they live outside Hollywood–to find out the name of the second assistant camera operator. People go to movie promotion websites to get a taste of the film.
The design challenges simply weren’t the same as Cooper’s. I needed a tool not just for creating empathy and filtering out quirks, but one that could:
- Guide strategic decisions about a product’s focus,
- Enable better tactical-level design decisions, and
- Help make inevitable design trade-offs.
In a sense, trying to build personas with sufficient actionable detail is similar to the problem novelists and screenwriters face when trying to understand motivations, making sure plots are clear. Good editors constantly pose questions to the writer to force them to reach that clarity. My toolkit is built on the efforts of others from a wide variety of fields, from HCI to branding to filmmaking. To help develop more “three-dimensional” personas, the toolkit contains more than a dozen pages of questions about:
- Biographic, geographic, demographic, psychographic background information
- The business’ relationship to the persona
- The persona’s relationship to product and business
- The persona’s specific goals, needs and attitudes
- The persona’s specific knowledge and proficiencies
- The context of usage
- Interaction, information, sensory, emotional aspects of the user experience
- Accessibility issues
- Relationships among personas
It also includes techniques for using personas to prioritize user interface components, as well as useful definitions for providing a common language to describe this prioritization.
“In a sense, trying to build personas with sufficient actionable detail is similar to the problem novelists and screenwriters face when trying to understand motivations, making sure plots are clear.”
My focus was on a tool for design rather than a tool for persuasion, so the questions– and resulting answers–are far too detailed for those outside the design team. But they’re necessary to enable a designer to not only make better tactical level decisions, but also to think more strategically about the product’s focus and help drive the product’s definition. The toolkit covers a wide variety of situations, so you should use the questions that are most appropriate to the context of your project. Similarly, not all the questions need to be–or should be–answered at once. The toolkit is designed to be used iteratively with questions being filled in over time as they become relevant to the design issues at hand. (However, it’s still a good idea at the start of the project, or at least at the start of each project phase, to identify the questions you think you’ll want to answer, so that you can begin gathering the necessary information.)
Let’s quickly review some of the basics of persona creation. When building personas, the first challenge is finding the information to build them. Obviously, it’s preferable to talk to and observe the users themselves, but that’s not always possible. In my opinion, any information is generally better than no information, and there are inevitably other sources of information. You can talk to user surrogates, such as domain experts, trainers, or immediate supervisors. There are “informants” who know about the users, such as people in the marketing, sales or customer support departments. For example, I once designed an extranet for a company’s board of directors. I couldn’t get access to the board, but their support staff was able to tell me all I needed about the directors’ behavior and computer skills. There are other indirect sources as well, such as manuals (especially those with notes written in them), site logs, customer feedback forms, surveys, etc. But one indirect source to be wary of is “ersatz” users–most commonly upper-level executives who think they understand their customers far more than they typically do.
After gathering information, I prioritize personas into the following types:
- Focal–These are the primary users who are the product’s target.
- Secondary–They also use the product and we’ll satisfy them when we can. But their needs can be sacrificed to meet the needs of focal users.
- Unimportant–Infrequent, unauthorized, or otherwise low-priority users.
- Affected–They don’t use the product but are affected by it. For example, one member of the family may do the research when buying a car, but the others–who are usually involved in the decision–will be affected by that person’s work.
- Exclusionary–We’re not designing for them. Period.
- Stakeholders–I’ve often found it useful to create mini-personas that represent their interests and involvement. These can range from advertisers to senior management to industry influencers to regulatory agencies. Stakeholders may–or may not–be something you want to put into writing. But stakeholder personas are often useful to formally create because they provide a good way of ensuring stakeholder issues get discussed openly. If you’re including a feature solely because it will get press coverage, it’s better to acknowledge this in the design process than to pretend that it’s there to satisfy a user need.
You probably want no more than a dozen personas, with at least one focal persona. But if there are more than three focal personas, you’re trying to do too much, and you need to subdivide the product or interface–for example, separating the “user’s” user interface from the “administrator’s” user interface. This is probably familiar ground. But I mention it because it’s critical to get team consensus on the relative priority of each persona in order to later prioritize specific design decisions.
What is your persona’s background?
At the broadest level, persona development starts with the biographic background, including:
- Geographic profile. Where do your personas live and work? What’s it like there? Why can this matter? It’s worth noting that some of the earliest non-U.S. internet adopters were the Scandinavian countries, Australia, and New Zealand. While geography may not be destiny, I suspect the rapid adoption was in part due to the long dark winters of the former and the geographical isolation of the latter.
- Demographic profile, such as age, gender, family size, income, occupation, education, etc., information that’s available from the marketing team. It’s frequently less useful for understanding the behavioral aspects of your persona, but can useful in rounding out a persona’s character. Politically, it’s a good way to get Marketing to buy in.
- Psychographics, which include social class, lifestyle traits and motivations, personality characteristics and attitudes. These can be important in understanding the proper tone and voice to give a product. For example, the PRIZM system developed by Claritas–based on the idea that people with similar tastes tend to live in the same neighborhoods–is eerily accurate in describing people’s likely interests based on their ZIP code (You can try it yourself here.) I’ve also found it to be a useful tool for adding in non-essential details that make personas feel more realistic.
What’s the relationship between persona, product, and business?
Some of the key strategic questions are around the persona’s relationship with–and value to–the business.
- Is the persona a customer, an employee, a partner? A company will likely want to communicate different messages for its external sites than its intranet. An extranet may display different content for a preferred vendor than for other vendors. Similarly, a website might restrict certain information to only paying customers, while leaving other content available to all users.
- Conversely, what sort of relationship does your persona have with your product or business? Are they a heavy user or a non-user? If you’re trying to acquire customers from a competing product, then you need to understand the people who aren’t using your product. What’s your persona’s attitude toward your product, your brand and your company? What kind of relationship would your persona like to have–but doesn’t have now? Enterprise applications are often like arranged marriages–employees use them not out of love, but because they’ve been told to do so. Linux users have an undying “hate affair” with all things Microsoft, and Tivo users will tell you that it changed their lives. Where’s the relationship headed? If you’re MTV, you’d best recognize that your brand relationship is a passing fling; in a few years, today’s viewers will be wearing Dockers and watching VH-1. In contrast, you’d have to pry their Macs out of the cold, dead hands of many users with a lifelong commitment to Apple.
- What’s the persona’s value to the business? More zealous advocates of user-centered design seem to think any user is valuable, but that simply isn’t true. The 80/20 rule was discovered by an economist’s extensive analysis of businesses that discovered 20 percent of customers did account to 80 percent of revenues. It can be useful to think about what percentage of overall users (or overall revenue) a persona represents. It may not the critical factor in a persona’s priority, but if nothing else prepares you to answer questions from the business side of the project.
What’s the context around the product’s usage?
Focusing on the product being offered, what are the specific goals, needs and attitudes surrounding the context in which your personas will use the product? Crown Equipment Corporation realized that even warehouse workers want to be “cool,” which was the inspiration for the stylish exterior of its Wave rolling ladder replacement. The product has been a hit. Not only did it create significant jumps in efficiency because it allows one person to do the job of two, but companies using it saw big increases in job satisfaction and morale.
After thinking about what your personas are trying to accomplish, then look at what specific knowledge and proficiencies your personas have related to achieving that goal. A safe rule of thumb is that most users never pass the “advanced beginner” stage of expertise–nor do they really want to. This question also applies to more fundamental issues than computer skills. For example, there’s a company that provided computer-based HR training (sexual harassment policies, etc.) to hotel maids. Not all the maids spoke English, nor were all of them literate in their native languages. Needless to say, their language skills had a significant affect on the design.
It’s useful to get specific about the context in which the persona is using your product. For example:
- When and where do users perform a task? With whom?
- What’s the surrounding environment? Global navigation positioning systems for sailing are used at any hour of the day or night, in any weather condition.
- Are there device constraints? For example, designing for a mobile phone.
- Are there confidentiality needs? Accuracy needs? Audit needs?
- What are the operational and/or safety risks? Designing a hospital billing system has big risks–but far smaller than designing the hospital’s pill-dispensing system.
- Is there assistance and training available? Many of us work on websites where training is impractical, but in designing an air traffic control system it may be preferable to prioritize other concerns over learnability, since the users will be formally trained in its use.
- Are there legal and/or regulatory restrictions? If you’ve ever worked in financial services or other regulatory industries, you know how much these issues can affect the design.
What does the interaction look like?
Now that we’ve looked at the context around your persona’s usage of the product, let’s take a close look at the interaction with the product itself. How frequently does the interaction take place? Is it on a regular basis? Is it continuous or interrupted? Is it so intense that it requires the persona’s full attention, or is one of several interactions that your persona is doing at once? How quickly must the persona act? How complex and how predictable is the action? Who’s driving the interaction–your personas or outside factors? If you’re designing an air traffic control system, the interactions are highly complex, but generally predictable. The controllers are the ones driving the interaction with the pilots, but it involves continuous high-intensity focus with split-second reactions for hours on end. That’s a little different than the interaction with your average website. Admittedly, these questions overlap with task analysis, but answering them for each persona can help identify important similarities and/or differences in behavior among your personas.
What information is involved?
Many interactions also involve information–something that traditional task analysis can overlook in its focus on actions. So the next step is to look specifically at the characteristics of the information that your persona needs and/or manipulates as part of the interaction with the product. For example, at one extreme are call centers, where the operators are listening and talking with customers, while simultaneously reading and typing on their computer screens. If you were designing the call center’s software, you’d want to think about the volume and complexity of the information being used, how it flows to and from the operators, and what level of detail is needed at what times.
What makes the user experience memorable?
While interaction and informational aspects of user experience can be analyzed logically, the sensory and immersive characteristics of a user experience are inherently more subjective–but no less important. Products can survive in the marketplace initially despite being crude, ugly or dangerous if they provide enough value. But over time, as competitors match quality, style becomes the differentiator. (Or price–but only one product can ever be the lowest-priced.) What’s the mood or feeling, style or genre that’s appealing to your persona? What’s appealing? What’s pleasurable? What’s memorable?
Geek Squad–a boutique high-end computer-support company–is the master of the memorable experience. Does its black-and-white “Geekmobiles” and Men In Black-meets-computer nerd schtick affect the actual technical troubleshooting skills of its services? Nope. Does it make an impression? You bet. So much so that the company amassed a celebrity client list and was subsequently acquired by Best Buy, who is now launching the service in all its stores.
The Geek Squad experience was no accident. It was consciously created to overcome people’s adverse reactions to arrogant tech support workers. Not surprisingly, brand researchers have paid much attention to the emotional aspects of an experience. One researcher argues that aspects of five major personality characteristics:
account for roughly 90 percent of brand differentiation. Regardless of whether the list is as specifically effective as claimed, it is worth thinking about what personality your product conveys and whether it’s something that’s attractive to your personas.
Likewise, what is your personas’ perceived experience of using your product? Does the product convey:
- Sense of adventure?
- Feeling of independence?
- Sense of security?
Strengths in many of these areas are what prompt Harley-Davidson’s customers to literally brand themselves with tattoos and jackets–and what kept the company afloat during the 1970s when the motorcycles themselves suffered severe quality problems.
With this level of detail in your personas, it becomes far easier to prioritize them. The toolkit provides three approaches for doing so.
This approach seems to pose numerous questions–and it does. As I mentioned previously, you only need to answer the ones that are most relevant, and not all at once. But it’s the details that will make your personas powerful.
This article and the toolkit is very useful. I can’t wait to use it for my current software project. I am using the Persona approach to flesh out Stakeholder and User profiles. Thanks, this is the best document for my purposes.
Love the article! What is particularly valuable in this is the recognition that there is the stakeholder vs. user balance that is extremely challenging in internal IT. I am passionate about changing the way internal IT works, to make user centered design second nature to software development in corporate IT, and I am often frustrated with how we in the UX community seem to have given up on corporate IT. Agreed, it is an uphill climb, but, more than 50% of software is made by corporate IT, and if we ignore such a large segment of users, it means our passion for creating a better world for software users is conveniently limited to the space where it is easy to sell the need for UX…right? I hope we do a lot more to making business stakeholders understand the value of user experience in internal software.
“Not only did it create significant jumps in efficiency because it allows two people to do the job of one”
Interesting measure of efficiency!
Great article George. Are there more coming?
For some personae the “demographic” (=How much can they spend) and live in an area factors have a weak correlation. For example here in New Zealand I often see evidence of different “demographic” groups living in the same street.
That issue of “I don’t want you as a customer” is very important. The man hours wasted and the payroll bloat, from not being very clear on this could push a company out of “we’re doing what we want to AND we’re making money”.
There is a lot of merit to the methodology described below. That said, why does it have to all fall under the umbrella of ‘personae?’ Most companies already see the value of the type of due diligence you describe. Does this require UX practitioners to drive this process, and in many cases, replicate what is already taking place.
IMO, the benefit of personas iare their ability to provide a somewhat brief, lucid and informed snapshot of potential users to various stakeholders and team members who would otherwise not have the time nor inclination to get involved with suzh ‘fuzzy’ research.
Comments are closed.