Definition
A user persona is a fictional, archetypal user representation — grounded in real research data — that describes a specific user type's goals, behaviours, motivations, frustrations and context, used as a shared reference point for product and design decisions.
Personas done well are a productivity tool: they let the whole team make consistent design decisions because everyone references the same archetype. Personas done badly — invented without research, packed with irrelevant demographic detail, photographed from stock libraries — are a productivity drag that makes the team less honest about who they're actually building for.
Modern persona practice emphasises behavioural and contextual attributes (what they do, what they need, what they constrain on) over demographic ones (age, gender, income). The behavioural axis is what design decisions hinge on; demographic detail is mostly decoration.
Origin
User personas as a UX practice were popularised by Alan Cooper in 'The Inmates Are Running the Asylum' (1999), formalising techniques he'd been using since the 1980s.
How it works
- Run user research (interviews, surveys, contextual inquiry).
- Identify behavioural patterns across users — who clusters with whom?
- Define 2-5 distinct archetypes based on those clusters.
- Write each persona around behavioural goals, needs, constraints, context.
- Use real verbatim quotes to anchor the persona in real research.
- Reference personas in design decisions — 'would Sarah understand this?' — to keep them load-bearing.
When to use it
Use when
- For products with multiple distinct user types.
- When the team disagrees about who the product is for.
- As an ongoing reference, not just a discovery deliverable.
Skip when
- For very narrow products with a single user type.
- When you don't have research to ground the personas — invented personas are worse than no personas.
Key metrics
- Persona referenced in design reviews (% of design decisions)
- Persona accuracy vs. real usage data (refresh quarterly)
- Team alignment on user target (qualitative)
Examples
- Our three personas turned out to be one persona with three jobs — the research forced us to consolidate.
- Sarah, our enterprise admin persona, became shorthand the whole team used for design tradeoffs.
- We retired one of the personas after analytics showed nobody matching that pattern was actually using the product.
In practice at Makreate
Makreate produces personas only when they earn their place in the project — for complex products with multiple distinct user types where the team genuinely needs a shared reference. Otherwise we skip them in favour of direct user citations from research. Personas that nobody references after the discovery deck become a tax on the project, not an asset.
UX Design →Common mistakes
- Inventing personas without research.
- Building personas around demographic detail instead of behaviour.
- Creating too many personas (more than 5 stops being useful).
- Treating personas as a one-time deliverable instead of an ongoing reference.
- Not refreshing personas as the user base evolves.
Frequently asked
How many personas should a product have?
2-5 typically. Fewer than 2 means you don't have meaningful user-type variation; more than 5 means the personas are too narrow to be useful.
Are personas still relevant in 2026?
Yes, for products with distinct user types. Some teams prefer Jobs-to-be-Done framing instead — both can work; pick what makes the team produce better decisions.
Do personas need photos?
Not necessarily — photos can mislead more than they help. Focus on behavioural detail; photos are decoration.