Why Personas (can) Hinder Human-Centred Design
When I was in school, personas were a core component in human-centered design. We learned how to create them, update them and turn to them when we got stuck in the design process. UX, we were told, would not exist without personas. Just like atoms are the building blocks of life, so were personas the foundations of good design. Yet, we fast forward to today and in practice, most UX-ers almost never use personas.
Why not?
When I stepped into my first design job, I came in guns blazing, wondering where the personas were. How could we possibly design without them? I was told right away that personas are often unnecessary when approaching a user-centered project, and take properly-executed user research to be useful. I remember thinking that this project wouldn’t possibly be well-received by users. I was wrong.
I was amazed to see when that project went to market that users’ found it a seamless experience with the client’s portfolio of other offerings. All without personas.
But how could that be?
As a UX-er, it’s likely that you’ll jump into a project that’s well-underway; meaning that the company already exists and has products in the market, or you’ll join a team well-underway with a new product in the works. This means it’s up to you to consider the design patterns and solutions the client already has in place to create a seamless experience. For example, say you walk into a meeting with Adidas who has asked you to find a solution for their decline in customers adding products to their shopping carts. Asking for a persona to improve the shopping process doesn’t make a ton of sense because Adidas has many different customer profiles. My mom buys Adidas because she likes the quality, and my niece buys Adidas because they’re a trendy brand right now. Two very different personas, but with one goal in mind: to purchase. Does it make sense to create a persona to approach the solution?
Maybe. But can you ensure your persona will be completely founded on research and have no bias? And in the end, does it help you or hinder you?
Personas and Clients
One of the first things that come up when we sit down with clients is: “Let’s talk about personas!” Typically, these are well-established companies that have been catering to a specific target demographic for years. It’s at this point where we typically ask how they plan to incorporate these new personas throughout their entire business offerings and future projects. We normally receive a reply along the lines of, “Oh this is only for this specific project,” or, “We’re only incorporating this persona into this project, but not our others.”
Hmm.
Enter another scenario: we sit down with a client who’s done their own pre-research on UX and have brought along 4–5 personas with them. Upon review, the personas are filled with bias, assumptions and aren’t based on research, but rather stereotypes. This sounds like a harsh criticism, but it’s in fact just human nature. (If you don’t believe me, refer to our good friend Wikipedia who can provide a list of cognitive biases.) By creating a persona over the course of a couple of days, there’s almost no time to truly get to know the person you’re building the persona around. What are their goals and behaviors towards the market, what are their pain points when using your product, or a competitor’s product? Persona creation requires more in-depth research to understand user behavior over different spans of time.
As UX-ers, we know that a persona is only meant to be a point of reference when making design decisions, but the weight that we’ve begun to place on personas is that they are the source of truth. It’s an issue that we’ve begun to claim personas are who people truly are. And we’re way off base.
Here’s a (very) simplified example:
Sounds nice right?
In reality, if we get to know Monica over time and dig a little deeper, we might find that Monica’s persona might look more like this:
Humans are complex. By trying to squeeze them into a persona, we infuse our own biases into who people are. At that point, we’re designing with our own assumptions in mind.
Personas start to lose their value very quickly because they don’t allow designers to design for the user long term; The use of personas means that we’re only trying to understand who they are now, rather than who they will be.
When Personas are Useful
Personas are primarily meant to be used when solving complex problems, or if a product/service is just beginning. It’s important to understand the motivations and behaviors users have towards your particular industry. This helps you, as a UX-er, properly identify and approach the problem being attempted to solve. For example, if you’re trying to create a blockchain-service company, but you’re having a hard time with users adopting the product/service, you should understand the “why” behind that problem. What are their motivations behind wanting to adopt the product? What is their level of knowledge behind it? What other services do they currently use religiously? Having a persona that outlines user motivations and behaviours can help you immensely.
In the end, you have to ask yourself if you’re doing users justice by slapping together a half-baked persona.
Our User-Centred Framework
At Boompah, we don’t typically use personas as our client timelines are quite short. That said, we do use them when we’re approaching complex problems, where goals, pain points, etc have to be thoroughly and clearly outlined; this typically takes place around the time that a company is just starting, or have just gone through the validation stage. The downside of persona development is that creating a solid, unbiased persona takes months of research, planning, and monitoring. Unfortunately, we don’t always have the timeline and budget to work with.
Typically, we work with the jobs-to-be-done framework. I won’t go into too much detail as I plan on writing a future article on this, but the Innovator’s Toolkit defines the framework as:
“A job to be done (JTBD) is a revolutionary concept that guides you toward innovation and helps you move beyond the norm of only improving current solutions. A JTBD is not a product, service, or a specific solution; it’s the higher purpose for which customers buy products, services, and solutions.”
(To learn more about this framework, here is a good place to start.)
Essentially, the jobs-to-be-done framework allows designers to deconstruct a job that customers are trying to get done into specific and purposeful process steps. We’ve found this framework allows us to make a huge list of customer needs and approach each individual micro-problem with a solution. We’re also able to identify user-centered future innovations and clearly see what the MVP is.
By creating a list of jobs that need doing for users, regardless of their persona, we’ve mitigated bias and identified clear tasks to be done. We’ve found this approach to be more user-centered as we’re not making assumptions based on who we assume people to be as people.
To Conclude
Let’s be clear, we don’t feel that personas are completely useless, in fact, they’re incredibly helpful when approached and used in the right way. They’re a tool that helps keep human-centered design at the forefront of your process. At the end of the day, as UX Designers, we need to use any tools necessary to make sure we’re designing with the end-user in mind and remaining empathetic throughout the design process. That said, we need to be conscious and self-critical of our biases. Only then can we hope to create human-centered design solutions, rather than selfishly designing.
Until next time.
