User personas are research artifacts that describe patterns of needs, behaviour, and attributes of users. Usually presented as a character or a description of a specific, individual user, personas are commonly used to help product design teams understand and empathize with likely users. Personas draw attention to some aspects of the user and make concrete the abstract findings of research.
Notably, different disciplines use personas in different ways. A persona developed and used by a marketing group, for instance, may describe a desired buyer of the product and include a great deal of demographic detail; user personas, on the other hand, tend to describe people who are likely to encounter the problem the product or design is meant to solve. Marketing personas and user personas may look similar, but they're not interchangeable. They do different jobs for different people.
Personas may be broad or narrow in scope, depending on need. A broad persona will lack the rich detail necessary for focused design work, whereas a narrow personas will probably be too specific to influence larger-scale decision-making. But each have their place.
A user persona should be realistic, not idealized, and serve to help teams understand the context in which a user might look to a product or design to help accomplish a goal or solve a problem.
Personas build shared understand about users
Personas are frequently cited as helping development teams achieve empathy for their users.
It's worth noting that achieving empathy isn't as easy as some might suggest. It means much more than just considering the user's perspective; it requires a concerted effort to imagine the world through the user's eyes. Real empathy requires effort and even training.
Personas are intended to facilitate that; yet, personas are sometimes constructed with little thought or care as to why or how they should actually be crafted and used. They've just become part of the process—almost a ritual more than a tool. In fact, it's questionable whether or not personas facilitate empathy at all. According to one (admittedly limited) academic study, personas didn't help its student participants overcome "egocentric anchoring": the tendency to use the self as the primary reference point for evaluating the perspectives of others. The students reduced the personas down to a handful of core attributes, and fixated most heavily on those aspects that marked the personas as "different"—hardly putting themselves in the shoes of their users. When considering personas that they perceived as being part of their "in group," the students defaulted back to their own needs as their primary reference. Particularly elusive was "affective" empathy—an emotional connection to the user being described by the persona.
There is also the risk that the creation and use of personas provides the design team with false assurance that "empathy" has taken place, even if it hasn't. In other words, the persona becomes a box to check so the team can convince itself that it's doing user-centric work.
Nevertheless, personas may still be worthwhile as a document that shares a team's current understanding of their users' perspectives, values, and priorities. While affective empathy can be difficult to achieve, cognitive empathy—consider another person's more functional needs—seems more attainable. Personas can be an effective shorthand for that purpose, if nothing else reminding product or design teams that there is a real, human user on the other side of the experience whose goals may differ from their own.
Moreover, whether or not they facilitate affective empathy, personas can keep teams aligned around the scope of their project. Alan Cooper suggests that personas can help prevent feature creep, as well as helping teams focus on user goals rather than features. And so, whether or not personas actually help development teams empathize with the users, they may still have utility as focalizing tools that, if used effectively, help manage scope, limit design changes, and establish a shared understanding and vocabulary about users.
Personas start with qualitative research
Personas shouldn't be created so much as discovered. First and foremost, personas document research. Personas articulate patterns of thought and feeling. These are attributes that can't easily be quantified. Effective user personas should be an outcome of qualitative research. Personas should be the result of sensemaking, not measurement.
This is abductive research: it doesn't start with a supposition or hypothesis, but begins instead with an openness to evidence that can be assembled into a theory. Persons require attention to what Christian Madsbjerg calls "thick data"—the rich context below the surface that details what an experience feels like rather than simply noting that it occurs. Personas should describe not just what kinds of people use the product, but help teams understand how they understand their relationship to the product and the problem space it occupies.
Due to a small sample size, it is possible that these qualitative personas will not completely capture a representative portrait of the use base. Some organizations therefore build on qualitative personas with another layer of quantitative research to help validate qualitative findings and identify statistical patterns among the users. This adds a veneer of scientism to personas and provides assurance that they are representative of the user base. However, the creation of statistical personas is far more time consuming and may yield only incremental benefits for the extra work.
Teams and organizations will sometimes create personas based on their best current understanding of the user; these should be clearly described as proto-personas and be treated as assumptions that should be subject to testing. Teams should be reluctant to base any significant decisions on proto-personas unless they're supplemented by more rigorous research. Nevertheless, when research isn't possible, proto-personas may be better than nothing. In the very least, they may serve as reminders that, at the end of the day, work needs to serve the customer. They may also be more useful in Lean UX environments where work will be continually tested and iterated upon even without initial discovery research.
Cooper emphasizes the importance of selecting a primary persona—the user archetype whose needs must be met at all costs. Most projects will involve multiple personas, but one should be identified as most important. Cooper also suggests that there may be value in creating anti-personas—in other words, defining user for whom you explicitly won't design.
Focus personas on tasks, goals, and motivations
The format and use of personas is subject to some debate. For instance, it has been suggested that the inclusion of names, gender, and other demographic details can lead to users making cognitive leaps or assumptions about users based on unconscious (or conscious) biases. As well, personas may lack rich contextual information and lead teams to fill information gaps with their own assumptions.
Typically, personas include details such as a photograph, age, attributes (like "tech literacy," sometimes scored on a scale of 1-10), information about a typical day, which are intended to help flesh out the persona as a real person. Some of this information might be useful, but often it's fluff. Some designers have suggested that such extraneous information helps them identify with or empathize better with the persona. Others have suggested that the inclusion of details like names or headshots can help make the persona more memorable. However, it's also possible that these elements are included less because they are useful and more because it's consistent with a team's idea of what a persona should look like.
More important than these details are the persona's needs and objectives. In fact, Cooper goes so far as to say that personas are defined by their goals. Goals are not tasks; tasks are means by which someone might achieve a goal. Tasks may change over time as technology and conditions change; goals remain consistent.
Cooper identifies four types of goals:
Personal goals, e.g. to not feel stupid, to not make mistakes
Practical goals, e.g. to avoid meetings, to handle client demands, to record a client's order
Corporate goals, e.g. goals that are pre-requisites for function but that don't motivate in and of themselves
False goals, e.g. technology goals that are immaterial to the user but may be valued by a technology team, such as save key strokes, save memory, reduce load time
Scenarios, meanwhile, are a description of the persona using the product to achieve a goal. These may include both daily use scenarios, actions that the persona will perform frequently and may benefit from a shortcut; and necessary-use scenarios, which are performed less frequently but are nonetheless essential.
Jared Spool suggests that scenarios are perhaps the most important part of the persona. In fact, he's argued that in many situations you can get away with having scenarios even without the rest of the persona. For Spool, personas are only needed if there are significant variations between how different user groups would approach the same scenario.
Personas have a number of shortcomings
Personas have come under fire for including extraneous information that, beyond simply being unnecessary, can distract or contribute to misunderstandings about users and their contexts. For instance, Alan Klement suggests that by describing a set of attributes, personas distract teams from the actual problems their users are hoping to solve.
Much of the critique of personas has centered around their inclusion of demographic information and photography to represent the user. Indi Young and Klement have, in their own ways, suggested that including demographic information can instigate subconscious reactions and biases in team members. They may therefore inspire "anti-empathy." At best, demographic data may provoke divergent understanding as different members of the team interpret even soft descriptors like "low-income," "middle-aged," or "college student" in different ways. This is not to say that there are never situations when this kind of information is useful; but, these are likely exceptions rather than the norm.
Young, Klement, and others have therefore suggested adjustments to personas to mitigate the risk of biases. Much of this advice suggests removing demographic information or any data that would align the persona to a broad population rather than an archetype of an individual. For instance, Young suggests using gender-neutral names. However, because even those names may be suggestive of culture, race, or class, it may be preferable to refer to the "personas" with general descriptors rather than names at all. Young has also proposed using demographic data to disrupt assumptions people might have of a given group.
Personas have also been criticized for being too reductive. This is, to some extent, unavoidable; personas are by intent and by design meant to condense research into an accessible format. Spool says that personas can be a valuable tool, but suggests that most teams create overly simplistic user models that don't actually add to the process. "They look good," he writes, "but they get ignored."
It would be impossible to fully capture the complexity of every user and their context in a diagram that can easily be digested by a number of individuals. However, this creates the risk that the design team will fill in gaps with their own assumptions about the user. Klement writes that "[b]ecause personas focus on creating a story made up of a customer's attributes, instead of a story that explains a purchase, personas leave the brain in an unsatisfied state." This leads each member of the team to come up with their own, potentially divergent, stories about the persona's needs and motivations. Teams should take care, then, to consider carefully whose experiences are represented by the personas and whose are left out.
Personas may also become too strong a stand-in for actual user research. That is, once personas are established, they may be used as an excuse for not engaging in further contact with users. This is dangerous. Even the most expertly designed persona can provide only a rough approximation of the real lived complexity of another human being. We can't test designs with persona, nor can we gather meaningful insight from them. We need real people for that. A persona shouldn't be the end of research. It's represents just part of it the research work to be done.
Better than any persona is ongoing exposure to actual users.
Alternatives to personas
A number of alternatives to personas have emerged over the years in response to some of these shortcomings.
Klement suggests that "personas" be replaced with "characters." Characters represent a subtle adjustment—Klement suggests that you need not even shift your vocabulary—but shifts focus toward a kind of story world that the personas inhabit, highlighting the anxieties, motivations, and personal histories of each persona that may have led them to your product. However, the line between “personas” and “characters” feels like a fine hair to split.
Indi Young promotes her concept of "thinking styles" instead of personas. Thinking styles represent users' patterns of thought, emotional reactions, and guiding principles. Gathered through listening sessions—qualitative research conducted deep in the problem space—thinking styles focus more heavily on rich contextual information than traditional personas.
A large body of work has emerged around the Jobs to be Done framework, often positioned as an alternative to personas. There are at least two different interpretations of jobs to be done. However, both shift focus away from individual people interacting with the product and toward the need that the product needs to fulfill. Its focus is on the process an individual might undertake to resolve some tension their life. These "jobs" can be simple or complex, but they're relatively stable over time (like Cooper's goals) and should be solution agnostic.
Haag, Maren and Nicola Marsden. "Exploring Perosnas as a Method to Foster Empathy in Student IT Design Teams." International Journey of Technology and Design Education 29. https://link.springer.com/article/10.1007/s10798-018-9452-5
Harley, Aurora. "Personas make users memorable for product team members." Nielsen Norman Group. https://www.nngroup.com/articles/persona/
Klement, Alan. “5 tips for writing a job story.” https://jtbd.info/5-tips-for-writing-a-job-story-7c9092911fc9
Laubheimer, Page. "3 Persona Types: Lightweight, Qualitative, and Statistical." Nielsen Norman Group. https://www.nngroup.com/articles/persona-types/
Madsbjerg, Christian. Sensemaking: The Power of the Humanities in the Age of the Algorithm. Hachette Books, 2017.
Salazar, Kim. "Just-Right Personas" Nielsen Norman Group. https://www.nngroup.com/articles/persona-scope/
Spool, Jared. “Making personas truly powerful by making them scenario-based.” https://articles.uie.com/making-personas-truly-valuable-by-making-them-scenario-based/
Westerholm-Smyth, Amber. “Your personas probably suck. Here’s how you can build them better.” https://medium.com/uxr-content/your-personas-probably-suck-heres-how-you-can-build-them-better-b2b32a45c93b
Young Indi. “Challenging the ‘make-believe’ in personas.” https://indiyoung.com/challenging-the-make-believe-in-personas/
—. “Describing Personas.” https://medium.com/inclusive-software/describing-personas-af992e3fc527