Credit: Erica Peterson

The Problem with Personas

The latest debate in the UX Research community has us questioning whether including demographic data in our personas is harmful. (We think it’s just lazy.)

A few years ago, I worked with a client on a website redesign project. There wasn’t much room in the budget for research, but they’d already created personas, they told me, so I could just use those. Great! I thought. They’ve already done some research and defined their audience. This is gonna be a breeze!

Unfortunately, what I got was a random collection of facts about people who obviously didn’t exist. They were clearly just stereotypes of the different “types” of people who they felt that they needed to represent (The old person! The young person! The middle-aged working mom! etc), their likes and dislikes (Shopping! Texting! Watching tv!), where they liked to eat (Starbucks! Chipotle!). Oh, and of course they were all conveniently “passionate” about exactly the thing this client wanted to sell to them. They encapsulated everything I try to teach my students not to do when they are creating personas. As a designer — the one tasked with designing a product that will solve real peoples’ problems — they were utterly useless to me.

What’s wrong with Personas?

First I want to make it clear that I don’t think personas are fundamentally flawed, just that how they are created often is. I’ve spent a fair amount of time in the classroom with beginning UX designers, and — as people are known to do when learning a new tool — beginners start first by imitating (in this case, filling in an existing template). It can be awhile before a practitioner stops just going through the motions and actually masters how to use the tool, when to use the tool, and, eventually, starts creating new tools to fit their needs. That’s called learning.

The problem is that a lot of practitioners are content to continue just going through the motions of creating a persona without questioning whether the information we are including, or even the persona itself, is actually useful. Without thinking critically about what data to present and how to present it, we are prone to focus on the wrong things. This doesn’t necessarily mean that the tool itself is useless, just that the way people use it can be flawed.

At the end of the day a persona is just a way to encapsulate all the research that you’ve done. The goal is to make the data easier to digest, more memorable, and, hopefully, actionable. The common wisdom is that by adopting a “real person” to embody this research, it will be easier to empathize with and therefor, to design for. So is it any surprise that if this fictitious person doesn’t ring true then it won’t inspire empathy, but rather resistance? Besides, even actual people standing right in front of us don’t always inspire empathy (believe me, I ride the subway every day), and a lot of that is due to the assumptions that we make about them, based on the ways they are different from or similar to us.

So beyond the realness factor, which has long been a common complaint against personas (mostly, I think, from people outside of the design community), the latest commotion arising from within the design community comes from the question of whether, by applying demographic data to our personas, we are unintentionally injecting them with our own biases.

It’s a fair question (not to mention a good sign that actually there are some seasoned UX designers out there evaluating and questioning how we’re creating and using even our most common tools). After all, does it really matter if a persona shops at Target or Walmart? What assumptions will someone make about a persona, based on that information? Are those assumptions worth exploring more? (For example, what is the motivation for shopping there? How does the person go about it? How do they feel about it?) Or are they non-essential to the project? (Is this being used to design something for a Target/Walmart competitor? Or something else entirely?). If it’s the latter, then, yes, I’ll buy the argument that this persona may be doing more harm than good, because now the people who read it are going to place their own biases and assumptions on the people in the personas — basically, they are going to judge them.

What are the common problems?

In a plea that we not throw out the baby with the bathwater, I’d like to offer up some ways that we can make personas better. These are the things I try to avoid when creating personas, and that I see from students or newer UX designers all the time.

1. The persona doesn’t go any deeper than demographics: This is the thing that is rubbing the UX community the wrong way. Rightly so. There are a lot of assumptions that a persona inherits the moment you start pontificating on what their age or ethnicity might be, and we may not even realize that we’re just taking the easy road by relying on stereotypes. But I’ll be honest here. I don’t know that I care so much whether a persona includes demographic info or not, because, unless that demographic data is statistically significant (as in, we know for a fact that these demographics represent some percentage of our user base, and we’re going to dig into how these facts affect their feelings and behaviors) I’m just going to ignore it anyway. It’s just not that important. What matters is that the persona is more than just a conglomeration of age, ethnicity, income, location, and education. If a persona doesn’t go any further than describing the audience as “millennial” (something I’ve seen countless times in student work, and even received from clients’ well-meaning but misguided marketing teams) then it is simply relying on the person reading it to fill in their own stereotypes and assumptions about what being a “millennial” means. It is both unfair and incredibly lazy. What a persona should tell us is what a person thinks, what they feel, what they are trying to accomplish, and what is getting in their way so that as designers, we can start to think about how we can help. So, while I agree with the current attitude in the community that this kind of slap-dash way of applying demographic data to personas is probably doing some harm, I guess I had already been operating under the assumption that it was never really doing any good in the first place.
2. The persona places too much emphasis on unimportant details: I’ve seen groups of students spend 15 minutes aggregating the actual data that they collected to create a persona, then two hours debating over where this fake person likes to shop and eat. I remember the first time I ever saw a brand logo in a persona and my first thought was “that looks pretty.” My second thought was “I don’t care that this person drinks Coca-Cola.” (In fact, now that I know that they drink Coca-Cola, I’m going to make a bunch of judgements about them because I think soda is bad for you. Or because I drink Pepsi. Or whatever. And at the end of the day it just doesn’t matter.)
3. The persona uses fake quotes: Quotations are often the strongest data we have coming out of user research. I’ve read quotes to clients that hit them like a gut punch. I’ve had people get visibly upset and argue with the person (not in the room with us, of course) who said it, because it was so incendiary or it went so against the assumptions that this client had about their users. There is nothing better than a choice quote that encapsulates what people are feeling and communicates it clearly. But too often, I see personas using obviously fabricated quotations to communicate what a personas should say, rather than what an actual person did say. It’s really easy to spot these because they’re generally of the “What I need is [exactly what you are selling to me]“ variety.
4. The persona uses stock photos: I can spot a stock photo from a mile away, and the instant I see it, the persona has just lost all credibility for me. This is another one of those cases where a desire to make the deliverable look good can undermine the purpose of the tool. If I’m not willing to spend the time to find a photo of a real person then I just don’t bother including a photo at all.
5. Its missing a scenario: Kim Goodwin nailed it, so I won’t bother to elaborate too much here. If a persona isn’t trying to accomplish some sort of task then I’m not really sure what a designer is going to be able to do to help them.
6. The persona isn’t being built from actual data: I shouldn’t even have to say this one. But the truth is, as with a lot of UX deliverables, people tend to think that the purpose of the exercise is the deliverable itself, but it’s actually the work that goes into the deliverable that matters. The deliverable is just how you communicate what you’ve learned. If the research activities didn’t include talking to people, then I don’t think that using a person to represent the data is appropriate.

When does it make sense to use a persona?

I do believe there is a time and place for personas. As a deliverable, personas make sense when the research involved actually talking to people, although even then I won’t always create a persona. And again, as I stress with my students, it is not so much the deliverable itself that matters, but the thinking that goes into creating it. What I mean is, when used wisely, personas are a method for synthesizing what was learned from talking to users, taking what might alone only amount to anecdotes or observations and turning them into something much easier to hold onto and make sense of. Maybe even something a little closer to the whole truth of a person’s experience.

And as a tool, personas are helpful for when you are building a product that needs to address discrete audience segments (NOT discrete demographics segments). When you are designing a single product that is supposed to meet the needs of very different audiences (again, read different use cases, scenarios, goals or contexts — not different ethnicities, ages, etc) that product needs to make sense as a single unified experience to each of these different users, so it helps to be able to walk in the shoes of one of these users from start to finish to ensure that it’s meeting their needs in a cohesive way. This kind of exercise can lead to important product decisions like whether to address every audience at launch, or to zero in on a primary audience first.

This was one of three personas I created to represent the very different user roles we would address while developing an in-house productivity tool for a client. This was a case where I included age, gender and ethnicity in our personas because I knew exactly the people who we were designing for and wanted the personas to represent them. But it could still be argued that it wasn’t very important information to the task at hand. What did matter was how each persona worked, how they felt about their work, and the kinds of technology (including websites, social media, and games) that they used. All of the data contained in these personas came from a combination of user interviews and surveys.

What are some alternatives to Personas?

That said there are plenty of times when it doesn’t make sense to use a persona. So what are some other tools that can help us communicate our research, define our audiences, and inspire empathy among the people who will be designing and building products? Here are a few that I like to use:

Empathy map

This empathy map was created during a kick-off meeting with a client as a way to get all of our assumptions out about who our primary user might be. We then went on to conduct interviews and surveys to gather actual data about their real thoughts, feelings and behaviors.

This is a useful exercise for getting out a bunch of assumptions before research begins, but it is not a deliverable. I look at this as an exercise for teams to get everything out in the open, a kind of “proto-persona” that can be used to kickstart the research process, but which will ultimately either be proved or disproved by that research. It’s a fun tool to use with clients because it can provide a benchmark against which to measure everyone’s expectations of what the research will uncover. In other words, I’ll know pretty quickly when something I learn is in line with or breaks from the team’s assumptions.

Archetype

One of four archetypes I created for a media client to help us summarize the expectations and behaviors of their primary users, without a whole lot of demographic or contextual detail.

I’ve seen archetypes presented as a better alternative to personas because they focus more on the “behaviors and motivations” than the characteristics. But I think that’s bull because personas should also very much be focused on behaviors and motivations, and not just random personality traits. However I do find archetypes to be a useful alternative for clients who have a longer-term need for audience alignment, beyond the scope of a single project. I think of it as a persona “lite” because it still has some very actionable information on which to start making informed design decisions, without being weighed down by the more contextual information that you don’t always need to know.

Spectrum

After conducting interviews for this client we identified a few key traits and showed how the people we’d talked to fell into different thought or behavior patterns along a spectrum. This helped us identify which of these points represented our target audience.

This is a comparative look at different audiences which I hadn’t really seen presented as a deliverable until I came across this Microsoft research article recently. But it’s a method that I’ve been using for years, sometimes as a step along the way to creating a persona, as I try to make sense of the characteristics or contexts that I’ve observed in my research and which ones we’ll strategically need to address. But sometimes, this makes sense on its own and doesn’t warrant creating personas around each of these traits, as was the case for the client mentioned above. It’s helpful enough just to know the range of the thoughts, behaviors, and contexts that you need to take into account, or even to weed out the ones that you don’t. As with the archetypes above, if you’ve got what you need from the data and it’s presented in a way that’s easy to understand, there may be no point in weighing it down with extraneous details in an effort to make the data more human. These traits could belong to anyone, regardless of demographics.

Here’s an example of how these tools can actually work well together, as this matrix was used to help us identify what our archetypes would be, based on a range of characteristics that we felt were important to the project.

Customer Journey or Mental Model

If one of the complaints against personas is that they don’t focus enough on scenarios and behaviors then these are two tools that definitely swing hard in the other direction. The information that they present can be incredibly detailed as it digs into peoples’ actions as well as the thoughts behind those actions, but there isn’t always a need for additional information about the person themselves. I use customer journeys for communicating the output of a task analysis by visualizing how a customer’s decision-making process plays out over time through various scenarios and interactions with the product or company. This can help to identify opportunities for improved interactions with customers across different touchpoints. But to do this really assumes that there is only one way to complete a task, and that this is representative of all of the people who might complete it, which isn’t always the case. (Hence the need to still use personas or at least do some basic audience definition in conjunction with these tools to identify who those different audience segments are.)

So What Now?

I suspect it will be a while longer before one of these (or some other, yet to be designed) deliverables will unseat personas as the catch-all research tool taught to upcoming UX designers. But whatever the tool, there will always be complaints about misuse and we will always struggle to teach newcomers and clients alike that it’s the research that’s important. How we communicate what we learn is always subject to refinement and improvement, and choosing or creating the right tool to do that comes with time, experience, and exploration.