Why User Personas Aren’t User-Friendly & How to Fix Them
An over-reliance on out-of-the-box templates & examples has weakened personas as a user research tool. Changing the way we think about and approach them can help us course-correct.
In an episode of Curb Your Enthusiasm, Larry David and two of his friends are waiting at the entrance of a restaurant for their other friend to arrive. Growing impatient and hungry, David approaches the hostess and asks if they can be seated as they wait.
“I’m sorry, sir, but we can’t seat you until your entire party arrives.”
“Why?” asks David.
“It’s our policy. We don’t seat incomplete parties.”
“What’s the point of the policy?” David sneers. “We have three people. It’s the same table. What’s the difference?”
“The chef really likes everyone to sit together so they can order together and he can deliver the food at the same time,” she says.
“Ohhh, the chef likes everyone to sit together?”
“Yes.”
“Isn’t that nice,” David says.
“It makes for the optimal dining experience,” she explains.
“Okay, you know what the optimal dining experience is? To eat when you’re hungry.”
Problematic Personas
Although UX LinkedIn would tell you otherwise, product teams are often the chef in this scene. Even when we profess a user-centric philosophy, other influences — be it policies, politics, personalities, or business priorities — prevail and we create less-than-optimal user experiences.
Alas, there’s no escaping these other influences. But personas can help teams create better user experiences; they’re a tool for taking user-centered thinking from idea to practice. Without them, “the user” is a shapeshifter in the minds of stakeholders. Personas allow for a shared understanding. They help stakeholders see their users as real people with real needs, goals, and motivations.
But over the 24 years since software developer Alan Cooper coined the term in his book The Inmates are Running the Asylum, personas have been diluted. The goal of personas is to imbue user empathy in the minds of stakeholders. The measurement of their success is yoked to that goal. But a quick Google search shows that personas often fall short. As David Travis and Philip Hodgson put it in Think Like a UX Researcher, personas lost their pizzazz in an Agile, move-fast-and-break-things world. “Personas get a mixed reception from development teams,” they say, “with some questioning their value.” Go talk to stakeholders about personas, and you’ll hear something like:
“Personas are…”
- Too fluffy: neatly arranged data that looks pretty but lacks substance.
- Too final: one-and-done artifacts that are never updated.
- Inflexible: too specific to a user type and “break” when applied in different contexts.
- Inaccessible: hard to find and/or use.
- Innumerable: there are too many to make sense of.
- Black boxes: the research they’re based on isn’t cited.
Persona creation has turned into a perfunctory exercise. UXers use out-of-the-box templates and examples almost without question. These usually include a stock photo, bio, demographics, user needs, quotes, and a host of other data that may or may not be useful. A generation of UX practitioners has learned (myself included) to create personas without ever stopping to ask the most important question: What do my stakeholders need to know about users to optimize the user experience?
User Personas: More Scientific Theory Than Fictional Character
Personas are often described as fictional characters. It’s not that this is incorrect; by definition, personas aren’t real people. But this view most likely contributes to the above pain points. Including a photo, name, backstory, and demographics all aim to make personas feel more “real” and easier to empathize with. This thinking is rooted in psychology research showing that humans feel more empathy for an individual with a face, name, and backstory than a group of people.
For example, people tend to be more charitable to an individual in need of disaster relief aid than a group of people in the same scenario. Empathy is a superpower we have compared to others in the animal kingdom — but that power is limited. The developmental psychologist Paul Bloom put it this way in his book Against Empathy: The case for rational compassion: “Empathy is narrow; it connects us to particular individuals, real or imagined, but is insensitive to numerical differences and statistical data.”
Increasing user empathy is the goal of personas. But not all empathy is created equal. You want to instill the right kind and level of empathy in your stakeholders. You can write an elaborate backstory about the struggles your users go through, making them weep with empathy. But will that help them optimize the user experience? Probably not. When you’re sick or in pain, you want your doctor to feel empathy for you, but not feel what you feel. Instead, you want them to have more cognitive empathy: the ability to “step in your shoes,” but armed with 8+ years of medical training.
Personas are more like scientific theories than fictional characters. In science, a theory is a way for scientists to make sense of a bunch of data. There may be a hundred studies on a topic — e.g., evolution. Only by zooming out and drawing a connecting line between them can scientists make sense of it all — e.g., new species emerge because of environmental forces and genetic differences in a population; this is the theory of natural selection.
Theories are data-driven, updated as new data is collected, concise, generalizable, and predictive of how the world works. These are exactly the tenets “good” personas should have: data-driven, updated as new research is done, lean (concise), flexible (generalizable), and predictive of user behavior.
Thinking about personas as theories changes the way we approach creating them. We’re still aiming for user empathy, of course. But by viewing personas in this light, we prop them up on a sturdier foundation. We give ourselves tenets to follow instead of prescriptive methods or out-of-the-box templates. When it comes to personas, there isn’t a one-size-fits-all solution; there are only principles to follow to ensure you create something of value.
IBM Cloud: A Use Case
In early 2022, UX Research for Public Cloud (UXRPC), the research team I’m on, sought to create more useful personas. We weren’t the first. The UX community is replete with alternatives: jobs-to-be-done, mindsets, thinking styles, personas rooted in analytics, and many others.
The UXRPC decided to take a new approach to personas. We started from the ground up. We followed the tenets of good personas and included our stakeholders in the creation process. This initiative was broken into four stages:
- Research personas to better understand the problem being solved.
- Consolidate past research across all of Cloud to create draft personas.
- Socialize and get feedback from stakeholders on those draft personas.
- Continue to evaluate with users and stakeholders regularly.
Stage 1: research personas
Stage 1 was researching and uncovering the problems with personas. This was a lot of desk research, but also conversation. We tracked down past efforts inside IBM, both in Cloud and beyond, interviewing those involved to better understand what worked and what didn’t; we spoke to stakeholders about personas in general; we read external persona literature and listened to podcasts on the topic. “If I had an hour to solve a problem,” Einstein said, “I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.”
Stage 2: consolidate what we know
New research is often done specifically for the act of creating personas. Our team took the other route. We had several years’ worth of research to draw from — user interviews, user journeys, usability tests, and surveys. A cadre of us began meeting with each member of the UXRPC, often multiple times. Working in Mural, we started compiling the relevant research.
Our team of a dozen researchers supports ~40 IBM Cloud products. Our user base consists of thousands of employees from hundreds of companies trying to solve a host of business and technological needs. The stakeholders building Cloud are likewise legion. Drawing a connecting line between those users and companies in a way colleagues could understand — and use to build better products — was a herculean task.
With the research laid out in Mural, we not only began to see individual personas “pop out” but also a “persona framework” — i.e., a conceptual model for how our personas related to each other. When a platform is as big as IBM Cloud, a framework will help orient stakeholders. Without it, it’s like trying to describe what a puzzle is just by looking at individual pieces in isolation.
Stage 3: socialize and validate with stakeholders
After completing draft personas, we needed to show these weren’t just the UXRPC’s personas — these were all of our personas. We presented them to leadership teams; shopped them around in product team meetings with designers, PMs, and engineers; and openly invited feedback and criticism at every turn. In this way, we refined our personas and insured the data we put on them was valuable to stakeholders. Moreover, by inviting stakeholders into the creation process, we fostered a sense of shared ownership.
Usually, stakeholders aren’t user research professionals. Because of this, word choices matter. Even though our approach embraced bits and pieces from alternatives — e.g., jobs-to-be-done — we did not use these terms when speaking with stakeholders. The reason was part semantics and part strategy. I would argue personas are a catch-all and alternative approaches—jobs-to-be-done, mindsets, thinking styles, etc.—are different kinds of data that can be included in a persona. Using newer terms also requires more explanation/buy-in; stakeholders are more familiar with the word persona. Expanding the definition of the word is an easier lift.
Stage 4: continue to update and evaluate
The final stage of this project — continuing to validate and update with user data and stakeholder feedback — is never-ending. If you ever want to make more business-oriented folks balk, use the phrase “never-ending” when talking about a research project. But the ebb-and-flow of employees will always happen, and teams and organizations will always change. As this happens, if it isn’t made clear what research your personas are based on and that they’re up-to-date, a new group of people will reinvent the wheel.
Going back to the personas-as-theory analogy, when scientists propose a new theory, they cite the research it’s based on. If they didn’t, nobody would pay attention to them. So it should be with personas. User researchers need to allow easy access to the foundational research personas are based on. Not only to signal to stakeholders that they are data-driven but also so stakeholders can dive into the weeds if they wish. During the consolidation process (Stage 2), the UXRPC tracked the research we were pulling in so we could eventually link to it. Gatekeeping research only hinders the goal of doing research in the first place — namely, helping product teams better understand their users so they can build better products.
The second step to solving this problem is keeping personas updated. The UXRPC has carved out time in our team’s roadmap to update our personas biannually with any new research/feedback. We also made a point to explicitly say this on our persona website and include “last updated” time stamps. As we like to say at IBM Design, everything’s a prototype — even personas.
“Here’s a secret many people don’t know: you don’t need to create personas to be user-centered. Creating personas should never be your goal — understanding users’ needs, goals and motivations should be your goal.”
Travis & Hodgson, Think Like a UX Researcher
Measuring Impact
At the beginning of 2023, we published our personas and persona framework on an internal site along with details about how we created them and ways they could be used (e.g., workshops, recruitment, storytelling, etc.). We created persona assets in Figma and slide decks for easy use. The reception has been overwhelmingly positive. Other research teams at IBM have reached out to learn from our process. It has come full circle; this is exactly how we started.
Applause and positive comments are nice. But if user personas are intended to increase user empathy, how do you know you’ve done that? How can you measure increases in user empathy?
In user research, we find ourselves in an interesting predicament. We’re often asked to show the impact of our research, but the impact we make is often hard to trace. The currency we deal in is influence, rather than dollars or design changes or bug fixes. But we indirectly impact those things by influencing our stakeholders.
We thought about this question of measurement often as it related to personas. One way we decided we could do this was to survey our stakeholders about their persona usage and user knowledge before and after the release of our new personas. By running this kind of pre-/post-test survey, we’ll be able to see if we have moved the empathy needle. Alas, only time will tell if we do move the needle. We plan on re-surveying later this year. Such is user research. The work we do often has a delayed, as well as indirect, impact.
In a way, we have stuck our necks out by doing this survey; our personas may have little to no impact. But by first understanding the problem, collaborating with fellow researchers and stakeholders, and embedding a method of continuous validation, we have created something more user-friendly. As Karel Vredenburg, IBM’s VP of Client Insights and Research, says, we have helped “de-risk product development.” At the end of the day, what more could a user research team hope for?
Nick Stiles is a User Researcher at IBM based in Austin, TX. As mentioned, this was a collaborative effort through and through and would not have been possible without the expertise of many people. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.
