UX glossary
Persona
A persona is a fictional person, grounded in real research, who represents a typical group of users. It helps teams make decisions from those people’s point of view.
Imagine a team building an app for a bakery’s delivery service. Every meeting is full of talk about “the users,” but everyone in the room pictures someone different: one person thinks of the student ordering late at night, another of the family that wants fresh rolls on Sunday morning. The discussions go in circles because nobody knows who the decisions are actually for.
Explained simply
A persona is a made-up person who stands in for a real group of users. They have a name, often a photo, and above all goals, habits and typical problems. Those traits don’t come from imagination, though. They come from user research: interviews, observation and surveys with real people.
Think of an experienced bookseller who, when placing an order, has “the crime fiction fans who drop by every Friday” in mind. She isn’t thinking of one specific customer but of a pattern she knows well. A persona makes that kind of pattern visible and tangible for an entire team.
The method was popularized by software designer Alan Cooper. By his own account, he worked with an early form of personas back in the 1980s and described the method in the late 1990s in his book The Inmates Are Running the Asylum.
What belongs in a good persona
At its core, a persona answers three questions: What does this person want to achieve? In what situation do they use the product? And what gets in their way? The Nielsen Norman Group advises, in essence, to judge every detail by whether it influences a design decision. A name and a photo make the persona memorable. A favorite color or star sign only helps if it actually relates to the product.
A few personas are usually enough. Merge characters that are similar, and drop groups that barely matter for the product. If you don’t have research data yet, you can create a so-called proto-persona. That’s a team assumption, clearly labeled as such, that you check against real data later.
An example
Back to the bakery delivery app. Before, the requirement reads: “People want to order quickly.” That could mean anything. After interviews with customers, the team creates the persona “Jana, 38, two kids, orders from bed on her phone the night before.” Jana wants to place the same order as last week in under a minute, and she often remembers only just before the order cutoff.
Now it’s obvious what to build first: an “Order again” feature and an evening reminder. The question in meetings is no longer “What do people want?” but “Does this help Jana?”
Common misconceptions
A persona is not a marketing segment. Marketing target groups often describe age, income and location. For design, what counts is goals, situations and behavior. A second misconception: that personas are ever finished. Good personas get updated whenever new insights come in from interviews or usability testing. You can read more in What Are UX Personas and Why Does Every Team Need Them?
In practice
- Research first, write second. Talk to real people before you write a persona. Without data, it mostly reflects your team’s assumptions.
- Every detail has to decide something. Cut anything that doesn’t answer a design question. A short, clear persona gets read; a ten-page document probably won’t.
- Bring the persona into everyday work. Put it up where people can see it, or mention it by name in reviews. A persona that disappears into a folder won’t change a single decision.
Related terms
Jobs to be Done, Journey Map, User Research