Personas & Archetypes
Research-grounded portraits of the range of people you are designing for, so the team designs for real users instead of for itself.
Not fictional people invented to feel real. Evidence-based representations built to keep the diversity of actual users in the room.
What it is
A set of real people held in the room while you design.
A persona is a research-grounded portrait of a type of user: their goals, motivations, behaviors, frustrations, and context, distilled into a single, memorable, shareable representation. Archetypes are the same idea at a higher level of abstraction: rather than a named, detailed individual, an archetype captures a behavioral pattern or role (the Optimizer, the Reluctant Adopter, the Power User) stripped of biographical specifics. Personas are concrete; archetypes are abstract; both do the same job.
That job is to keep the real diversity of users in the room. Left unchecked, every team designs for itself — for the user it imagines, who tends to look suspiciously like the team. A well-built set of personas, covering the meaningful range of real users (the confident and the anxious, the expert and the first-timer), forces the team to design for people who are not them. When a designer asks “but what would the Avoider do here?”, the persona is doing its job.
The single most important thing about a persona is what it is not: it is not a fictional character invented in a workshop to feel plausible. A persona invented from assumption is worse than no persona, because it wears the authority of a real user while teaching the team only its own biases back. A persona is only as valuable as the research beneath it.
The personas
Meet the range. Click any persona.
As you click across the cards, the range becomes tangible — genuinely different people with genuinely different needs. Designing for only one of them would fail the others.
When to deploy it
A synthesis tool, not a research method.
Use Personas & Archetypes when
- →You have done real user research and need to synthesize it into a shared, memorable form the whole team can design against.
- →The team is at risk of designing for itself, and needs the diversity of real users made concrete and present.
- →Multiple distinct user types genuinely exist, and designing for the range (not just the average) matters.
- →You need a common language for "who we are designing for" across a cross-functional team.
Do not lean on it when
- ×You have no research to ground them in. A persona built from assumption is actively misleading — see Best Practices.
- ×You genuinely have one sharp target customer and want to align focus around them, not cover a range (use an Avatar instead — see section 11).
- ×You need statistical market sizing or demographic segmentation. That is market segmentation, a different tool.
- ×The team will make beautiful persona posters and then never look at them again. A persona that never enters a real decision is decoration.
The honest limit: personas are a synthesis and communication tool, not a research method. They are only as good as the research upstream of them, and only as valuable as the decisions downstream of them. Sandwiched between weak research and unused output, they become theater.
How it works
Six moves, in order.
Start from real research.
Personas are built from in-depth interviews, contextual observation, and other primary research. The raw material is real people; the persona is the distillation. Budget the research first, not after.
Find the patterns, not the average.
Look across the research for meaningful clusters of behavior and motivation — distinct types, not a single blended 'average user' who is, in fact, nobody. The clusters become the personas.
Decide personas or archetypes.
Choose the level of abstraction. Detailed personas (named, contextual, specific) when vividness and empathy matter. Archetypes (abstract behavioral patterns) when you want to strip away biographical noise and focus on roles.
Build each portrait around what drives decisions.
Goals, motivations, behaviors, frustrations, and context — the things that actually change a design decision. Resist padding personas with irrelevant biographical detail (favorite coffee, a stock photo) that adds realism but no design value.
Cover the meaningful range.
Build a small set (usually three to five) that spans the real diversity of users, including the edge cases that stress the design (the anxious first-timer, the impatient expert). Too many personas and none get used; too few and the range collapses.
Put them to work.
The persona set earns its keep only when it enters real decisions: design reviews conducted "as" a persona, features justified against specific personas, prioritization that asks which personas a choice serves. A persona that never leaves the poster is wasted.
Best practices
What good looks like — and the mistakes that prevent it.
When it goes well
- ✓Every persona traces back to real research; you can point to the interviews and observations behind each one.
- ✓The set covers the meaningful range of real users, including the uncomfortable edge cases, not just the flattering core user.
- ✓Personas are built around what drives decisions (goals, motivations, frustrations), not padded with decorative biography.
- ✓The team actually uses them: they show up in design reviews, prioritization, and feature debates.
- ✓They are revisited and updated as understanding deepens, treated as living tools rather than a finished deliverable.
The mistakes, and how to avoid them
Inventing personas from assumption.
The cardinal sin. A persona conjured in a workshop with no research is a mirror of the team's biases wearing the mask of a real user. Ground every persona in evidence, or do not build it.
The "average user" persona.
Blending all users into one composite produces a person who does not exist and needs nothing in particular. Build distinct types that span the range, not an average.
Decoration over substance.
Stock photos, names, and favorite-snack details create a feeling of realism while adding zero design value. Include only what changes a decision.
Too many personas.
A set of nine personas gets used as often as zero. Keep it to a memorable, usable few — three to five is the usual range.
Building them and shelving them.
The most common failure: beautiful personas that never enter a real decision. If they are not changing design choices, they are theater.
Confusing personas with segments or avatars.
Treating a demographic segment or a single marketing avatar as a persona muddles the work. The boundary section (11) draws these lines precisely.
Logistics
Building personas that actually get used.
A persona is downstream of primary research. Budget the research before the personas; the personas are a synthesis step, not a substitute for talking to users.
The research comes first
In-depth interviews and contextual observation are the usual primary sources. The same research that feeds empathy maps and journey maps feeds personas. There is no shortcut; a persona without research is an assumption in costume.
Build them collaboratively
Personas are best built with the cross-functional team, not handed down by one researcher. When the people who will use the personas help distill them from the research, they trust and actually use them. A persona built in isolation and delivered as a poster tends to be ignored.
How many, and how detailed
A common working range is three to five personas, detailed enough to feel real and distinct, lean enough to be remembered. Match the detail level to use: rich personas for empathy-heavy design work, spare archetypes for pattern-level strategy.
Keeping them alive
Personas drift out of date as the user base and the product change. The most useful sets are revisited periodically and updated from fresh research, rather than frozen at the moment of a single project.
Sharing them
Personas live where the team works — on the wall, in the design system, in the project workspace, referenced by name. Common formats are one-page persona cards; the format matters less than whether people actually reach for them.
AI and this method
AI will generate a full set of personas in seconds. That is exactly the danger.
Toggle each persona to see what changes when AI generates it from nothing versus when AI synthesizes it from your real research. The difference is the whole point.
In-depth example
The same brief, built two ways.
The same team, the same research brief, two different methods. The contrast reveals exactly why the source of a persona matters.
Shared scenario
A fintech startup is building a budgeting app and needs to define who it is for. The founding team — three engineers and a designer — all assume their user is a young, tech-savvy professional who wants powerful features and detailed control. They set out to build personas to guide the product. Both versions below tackle the same task; only the method differs.
The team ran fifteen in-depth interviews with a deliberately varied set of people who struggled with budgeting — different ages, different incomes, different relationships with money. They synthesized the research into four personas covering the real range they found.
The interviews broke the founding assumption. Yes, one persona matched their imagined user: the Optimizer, a confident power user who wanted control and features. But the most common and most underserved type was almost the opposite. The team came to call her the Avoider: someone whose relationship with money was anxious and shame-tinged, who did not want more data and control but less, who wanted to feel reassured rather than empowered. For the Avoider, the team’s planned feature-rich, dashboard-heavy product was actively repellent — it made the anxiety worse.
That persona appeared in six of the fifteen interviews. The team would never have designed for her — or even imagined her — without talking to real people. And designing for her (calm, reassuring, minimal, judgment-free) rather than only for the confident Optimizer changed the entire direction of the product.
The insight
The persona set did its job: it forced the team to design for a real user who was nothing like them, and who they would otherwise never have built for. The Avoider was the user who changed everything. She appeared in the research, not in the assumptions.
Boundaries
Three things that get confused, and are not the same.
This method is muddled in practice because three different tools wear similar clothes. Getting the distinction right is most of the skill.
Personas & Archetypes
The RANGE
Multiple research-grounded portraits
A SET of portraits covering the meaningful diversity of real users — the confident and the anxious, the expert and the first-timer. Plural by design. Built from primary research. The job is to hold the range of real users in the room so you design for people who are not you.
The rule: use segments to size and slice a market, personas to understand the range of real people in it, and an avatar when you commit to a specific beachhead market before expanding. They answer different questions at different scales. Confusing them is how persona work goes wrong.
Frameworks
Where personas show up.
Personas are a synthesis output, so they appear where frameworks turn research into a shared understanding of the user.
Note: the Design Sprint tends to import an existing persona rather than build one in the five days, and FDE relies on continuous direct embedding rather than distilled personas. These blanks are intentional.
Related methods
What to combine with personas.
Sources & further reading
The work behind this method.
About Face: The Essentials of Interaction Design
Alan Cooper, Robert Reimann, David Cronin, and Christopher Noessel (2014)
Cooper originated the persona method. This is its definitive treatment — where the concept of the persona as a research-grounded design tool was first fully articulated.
The User Is Always Right
Steve Mulder and Ziv Yaar (2006)
A practical guide to creating and using personas grounded in research, with clear guidance on the research-to-synthesis process.
Universal Methods of Design
Bella Martin and Bruce Hanington (2012)
Personas among the wider catalog of research and synthesis methods — useful for understanding how personas fit alongside other tools.