Personas
A persona is a composite character built from real research data that gives your team a concrete, shared reference point for every design decision. Design for someone specific — not for an abstract "user."
01 — TL;DR
Two sentences.
A persona is a fictional but research-based character that represents a segment of your target users — built from patterns found across multiple user interviews, observations, and behavioural data, not invented from assumptions. It gives your team a concrete, named reference point so that design decisions are made for a specific person with specific goals, frustrations, and behaviours, rather than for an abstract and infinitely flexible "user."
Alan Cooper introduced the concept in his 1999 book The Inmates Are Running the Asylum, arguing that designing for a single, well-defined user archetype produces better outcomes than trying to satisfy everyone. What makes personas useful in practice is not the artefact itself — the document, the poster, the card — but the shared understanding they create: when a PM says "would Maya actually use this?" every person in the room is thinking about the same person.
02 — When to Use
Apply this when…
When NOT to apply it
Skip it when you have sufficient behavioural data to segment and test directly, when your research base is too thin (a persona from two interviews is misleading), when the team has continuous direct access to users, or when design decisions are driven by compliance requirements rather than user preference.
03 — How It Works
The mechanism
A persona works by converting distributed, qualitative research findings into a single, memorable reference point that anyone on the team can invoke during a decision. Instead of asking "what do users want?", the team asks "what does Maya want?" — and because Maya is built from real data, the answer is grounded rather than projected.
Lead with goals, not biography
Demographic details — age, job title, location, family status — are the least useful parts of a persona and the most commonly over-specified. A persona built around goals, frustrations, and behaviours transfers across demographic change; a persona built around "35-year-old London marketing manager" becomes useless the moment your user base shifts. Lead with the job to be done, not the biography.
04 — Real Example
Mailchimp's Freddie and the small business owner persona
Mailchimp spent years building their product explicitly around a single primary persona: the small business owner who handles their own marketing without a dedicated team. This person is time-poor, has no technical background, and measures success by whether customers came back — not by open rates or click-through percentages.
The deeper insight is what Mailchimp chose not to build. Enterprise features, advanced segmentation tools, and complex automation workflows were deliberately kept off the roadmap for years because they served a different persona whose needs conflicted with the simplicity the primary persona required. That discipline is only possible when the primary persona is genuinely shared and genuinely believed.
05 — In the Wild
Test yourself & see real examples
No examples yet — be the first.
Spotted a product that clearly knows exactly who it is designing for — or one that is visibly trying to serve everyone at once? Submit what you observed.
Seen Personas violated in a real product? Help grow the evidence base.
06 — Common Mistakes
Where teams go wrong
07 — Variations & Related Principles
Connected ideas
Personas sit at the intersection of research synthesis and product strategy. They are most useful when paired with methods that either generate the raw material they need or apply the understanding they encode.
The most important pairing is Personas with Journey Mapping. A persona without a journey is a character without a story — you know who the user is but not what they actually experience. A journey without a persona is a process without a person. Build them together and you have both the empathy and the context needed to make design decisions that hold up.
08 — 10-Min Exercise
Run it right now
⏱ 10 minutes · Team · No prep
1. Name the primary persona your team is currently designing for. Write down their primary goal in one sentence — not a demographic description, not a job title, but what they are fundamentally trying to achieve with your product.
2. Pick the last three significant design decisions your team made. For each one, write whether it directly served the primary persona's goal, served a different user's goal, or served an internal stakeholder's preference.
3. If you cannot name the primary persona, or if fewer than two of the three decisions served their primary goal, your team does not have an active persona — you have a research artefact that is not being used.
4. Share the results with the group. If people named different primary personas or described the same persona's goal differently, you have found the root cause of at least some of your recent design disagreements. That misalignment is the first thing to fix.