Research

User Persona

A research-based representation of a key user group that keeps design decisions grounded in real user needs, goals, and behaviours rather than assumptions.

#user persona#persona#user research#target user#archetypes#empathy#user needs

What is it?

A user persona is a semi-fictional representation of a key segment of your target users, built from real research data — interviews, surveys, usage analytics, and observation. A persona captures not just demographics but goals, motivations, pain points, behaviours, mental models, and the context in which they use a product. When built from real data (not assumptions), personas give entire teams a shared, concrete understanding of who they are designing for.

Why it matters

Without personas, teams design for themselves or for a vague "average user" that does not exist. Personas make the invisible visible: they give names and faces to the range of real people who will use a product, allowing designers, developers, product managers, and stakeholders to make decisions with a specific, humanised user in mind. Research shows that teams with personas make more user-centred design decisions and build more consensus on priorities. The critical caveat: a persona built on assumptions — not real research — is worse than no persona at all because it creates confident decisions based on false premises.

Best Practices

Base personas on real user research — minimum 5 interviews per persona archetype, supported by survey data and analytics where available.
Include context of use: where does this user encounter the product, on what device, with what interruptions? Context shapes behaviour as much as demographics do.
Focus on goals and frustrations, not demographics. A 28-year-old developer in London and a 52-year-old developer in Lagos may have identical goals when using a code editor.
Create 2–4 primary personas. More than 4 is unmanageable; a single persona ignores real variation.
Include a direct quote from actual research — a real user's words anchor the persona in reality and make it resonant.
Share personas visually (one page, readable in 2 minutes) — not as lengthy research reports that nobody reads.
Make personas actionable: each persona should have a clear primary goal relevant to your product. "Wants to manage team projects efficiently" is actionable. "Is a busy professional" is not.
Revisit and update personas when significant user research is conducted. Users, contexts, and products evolve.
Use personas during design reviews: "Does this decision serve Sarah's goal?" is a powerful design conversation anchor.

Common Mistakes

Creating "assumption personas" — personas built from team opinions rather than real user research data.
Over-emphasising demographics (age, job title, location) at the expense of goals, frustrations, and context.
Creating a single persona that represents "everyone" — this is not a persona, it is a fantasy.
Creating personas that are too numerous or too similar to differentiate design decisions.
Building personas and filing them away — unused personas have no value. They must be actively referenced in design and product decisions.
Treating personas as final documents instead of living representations that update as research updates.
"Marketing personas" that focus on buying behaviour rather than product usage behaviour.

Checklist

Each persona is grounded in real user research (interviews, surveys, or analytics)

Each persona has a clear primary goal relevant to the product

Context of use (device, environment, competing tasks) is included

At least one direct user quote is included per persona

Personas are presented in a format that is readable in under 2 minutes

The team can name primary personas without referencing a document

Personas are actively referenced during design reviews and product decisions

Personas are dated and scheduled for review when new research is conducted

Research & Theory

Cooper (1999) — The Inmates Are Running the Asylum

Alan Cooper introduced personas as a design tool after finding that teams consistently designed for "elastic users" — a fictional average user who conveniently wants whatever the team decides to build.

Why it's relevant

Personas solve the elastic user problem by making it uncomfortable to design for a user who does not represent any real person. A named, specific persona creates accountability.

Goal-Directed Design (Cooper et al., 2007)

Cooper's framework places personas' goals — not their demographics — at the centre of design decisions. Goals are categorised as personal goals, practical goals, and experience goals.

Why it's relevant

The most useful personas are goal-first, not demographic-first. A persona's goal drives design decisions far more than their job title or age.

Persona Effectiveness (Long, 2009)

Research by J. Long found that teams using research-based personas produced designs that better matched user needs and generated stronger consensus on priorities than teams without personas.

Why it's relevant

Personas are not just design artefacts — they are alignment tools. They get everyone on the same page about who the product serves.

Real-World Examples

Spotify

Uses listener personas segmented by listening context (focus, workout, social, background) rather than by demographics — because a 25-year-old and a 45-year-old listening while running have identical needs in that context.

Mailchimp

Their "Freddie" persona framework distinguishes between small business owners sending their first newsletter and experienced marketers running multi-segment campaigns — resulting in features like the "beginner mode" and advanced segmentation being designed for genuinely different users.

GOV.UK

Maintains personas for digital excluded citizens — users with low digital literacy, no home internet, or reliance on assistive technology — ensuring government services are not designed exclusively for digitally confident users.