Personas are a fundamental part of a UX designer’s toolkit—and they help design teams make decisions knowing that they’re solving the right problems for the right person.
But are they as useful as we think? Do personas create a false sense of security?
From my experience working with several teams and many digital products, I’ve learned that not everyone likes doing user research. The reason might be that they “just know” what the customer wants, they’re frightened of what they might find out, or they just don’t see the value. They’re looking for any excuse to get out of talking to users.
Related: Use these powerful research techniques to understand what motivates your users
Here’s the thing, though: once teams have a persona, it becomes that excuse—to not talk to users—they were looking for.
Having a persona is no substitute for user research with actual users.
From Inside Design: Treehouse.
The problem with using personas
So what exactly is the problem with personas? Alan Klement argues against personas in his article Focus On Causality, Skip Personas: “There’s a fundamental problem with personas: they are made up and not real. This means they are full of errors and prejudice. Using personas will distract and lead your team to make wrong decisions.”
“Personas aren’t an excuse to get out of talking to users.”
Alan also raises another point (paraphrased from Ryan Singer: “Personas are only a collection of attributes. Attributes do not make someone use a product. People use a product because it’s solving a problem they have.”
Rather than focus on the problems with personas—as Alan explained so well—I want to share my experience of working with personas and the impact they have on the teams and products I’ve worked with.
The risk of unchallenged assumptions
Recently, I worked with a team to design a complex product for a large number of users of different types. When a new designer joined the team, the first thing he asked was, “Can I see any personas we have for the users?”
It was great to have a new teammate immediately ask about our users. We’d definitely hired the right person.
“Well, we don’t use personas,” I replied.
He immediately asked why and went on to explain how he’d used personas in his last role.
Working on a similar type of product, his previous team had a persona for their main user. Their whole team—not just the designers, but the developers and product managers—used it all the time, especially when discussing new features to help decide what the most valuable thing to do was.
I explained that placing the user at the heart of those types of conversations is exactly what we do, too. Yet, in my experience personas are mostly made up and not reliable. And in the rare occasion that they are based on research, there simply isn’t enough research to make them valid. So they’re filled with massive assumptions to fill the gaps.
He quickly replied, “Come to think of it, our persona was made up, too.”
“Too often, personas are completely made up—and therefore unreliable.”
His previous team was making critical decisions about their product: where the value was, what the user needed, and where to focus their time and money. And it was all based on a fictitious persona full of unchallenged assumptions.
That was exactly the reason we didn’t have any personas.
Wrong persona, wrong product
Another team I worked with had already started well before I joined. It was the type of engagement where you hear comments like “We don’t need to talk to users—we already know what they want.” A challenge for anyone trying to do user research.
However, they’d created a persona for their main user and named him Derek. They turned Derek into a poster and displayed it on the wall to showcase the work the team had done in the project inception. Every user story mentioned Derek. The team used his persona when they talked about in-progress features.
Image from Inside Design: Pocket.
This was perfect. An entire team working in a user-centred fashion and treating the user as if he were a real person in the room.
But there was something very wrong with Derek.
During user testing sessions, we began to discover gaps in our understanding of who Derek was. We even began to start to challenge whether Derek existed.
As we gathered more data from our user tests—trying to understand why the product wasn’t quite doing the job the user needed it to do—we hit on a discovery. Derek was actually 2 people.
Related: Using predictive personas
Derek #1 used our product for a repetitive task, while Derek #2 would not use our product—he’d delegate that job to Derek #1. But both personas had been researched and merged into a single Derek.
We later discovered—during the initial research—that somebody had combined these 2 personas. They created the ideal customer, but that ideal customer just didn’t exist in the market.
“Challenge your assumptions.”
The problem here wasn’t the combination of the 2 personas. The problem was the way Derek was displayed to the whole team as the truth. Nobody challenged it, and it was seen as fact, not a collection of assumptions. Everyone moved on with their jobs without the need to think about who the user was.
And why would they? They had Derek!
The team was lured into a false sense of security because they had Derek. So they built the product based on Derek’s assumptions and never challenged those assumptions.
The persona forced them—in good faith—to build the wrong product.
Talk to users—no excuses
In both the cases above, the persona acted as an excuse to get out of talking to users. The team had a document—taken as fact—that told them everything they thought they’d need to know about their user. So why would they need to talk to users?
Both teams acted with the right intentions. They brought the user into critical conversations about the product they were building. But they substituted the real user with a persona full of unchallenged assumptions.
Image from Inside Design: GoPro.
A better conversation would have shaped their collective knowledge of the real user, identified gaps in their understanding, and challenged any assumptions they discovered. This forces the team to talk to users regularly and constantly learn about the person they’re creating for.
The result: more successful products based on actual user needs. Plus, a healthier team with a better, more accurate understanding of the value they’re delivering.
Are you going to stop using personas?
Why or why not? Tell us on Twitter: @InVisionApp.
Chris Thelwell has been a digital product designer in both the UK and Australia for many years, juggling award-winning F1 projects, cool Google Chrome apps and the occasional European football championship. An outcome focused design leader, Chris specializes in disrupting markets, creating innovative new digital products, and building high-performing design teams in Agile software delivery environments within large enterprises, startups, and agencies.
