Personas that teams actually use (and the ones that rot in a drawer)

A persona gets used when it is built from research, defined by what people are trying to do rather than by demographics, small enough to remember, and wired into the decisions a team makes every week. Personas rot when they are invented in a workshop, decorated with stock photos and hobbies, and handed over as a finished deliverable. The steps below build the first kind.

Why most personas end up in a drawer

A persona is a short, concrete description of a type of person your service is for: their goal, how they behave, what gets in their way. The idea was popularised by Alan Cooper in The Inmates Are Running the Asylum (1999) as a way to stop software teams designing for an imaginary "user" who could be anyone. Its job is to make a team argue about a specific person instead of a vague average.

Most personas fail for predictable reasons. They are made up from what the team already believes, so they confirm assumptions instead of challenging them. They describe age, job title and favourite coffee, none of which helps anyone decide what to build. There are too many of them, so nobody remembers any. And they are delivered by a research team or agency, then never mentioned again, because nobody's process asks "which persona is this for?"

How to build personas people use, step by step

1. Start with the decisions they need to support. Ask the team what it will decide over the next six months: what to build first, which channel to invest in, how to write the onboarding. Personas exist to make those decisions easier. If you cannot name the decisions, you are not ready to make personas.

2. Gather real evidence first. Interview a spread of current, lapsed and would-be customers, and watch some of them use the service where they normally would. Ten to fifteen good interviews often reveal the main patterns, though there is no fixed number: keep going until new interviews stop telling you new things. Add what you already have, such as complaints, call notes and search terms. The sibling article on how to really understand your customers covers this research in depth.

3. Look for differences in behaviour and goals, not demographics. Lay out what you heard and group it by what people were trying to achieve, how they went about it, and what stopped them. Affinity grouping works well here. You are looking for clusters that would need different things from you. Two people of very different ages who both "want to get it done in one visit and never think about it again" belong together. Two people of the same age, one cautious and one in a hurry, do not.

4. Keep the set small. Three to five personas is enough for most services. Pick one as the primary persona: the person the service must work for first, because if it works for them it usually works for others. If you have eight, some are probably variations of the same goal; merge them. A persona nobody can name from memory is not doing its job.

5. Write each one on a single page, in a fixed order. Use the same structure for each so they can be compared:

• a short name and a one-line description of their situation;
• the goal, in their own words ("I just want to know it's been received");
• the behaviours that matter for your service: how they look for help, which channels they use, how much effort they will tolerate;
• what gets in their way, with a real quote;
• what this means for the service: two or three design implications.

Leave out hobbies, brands, personality types and anything else you did not learn in research and would not use in a decision. An illustration or photo helps people remember, but choose one that does not lock the persona to a gender, age or nationality you did not mean to fix.

6. Mark what is evidence and what is assumption. Sometimes you must start before research is possible. That is fine: write "assumption" personas, sometimes called proto-personas, a term popularised by Jeff Gothelf's Lean UX, and label them clearly. Then test them. A persona that hides its assumptions will be defended long after the evidence has moved on.

7. Put them into the work. This is the step that decides whether personas live. Write user stories and problem statements that name a persona ("As Noor, a first-time applicant…", see user stories and point of view). Ask "which persona is this for, and what would they do here?" in every design review. Recruit usability test participants who match each persona. When a feature serves no persona, ask why it is being built.

8. Review them on a schedule. Set a date, perhaps once a year or when the service changes significantly, to check each persona against new research. Retire the ones that no longer match anyone. A persona is a working tool, not a monument.

Do's and don'ts

Do:

• Build personas from interviews and observation, and keep the source notes linked.
• Define them by goal, behaviour and obstacle.
• Name one primary persona and design for them first.
• Use the persona's own words for their goal and frustrations.
• Make the personas part of how work is written, reviewed and tested.

Don't:

• Invent personas in a half-day workshop and present them as research.
• Fill the page with demographic detail that changes no decision.
• Create a persona for every department's favourite customer.
• Confuse personas with market segments. Segments help marketing and finance size and target; personas help a team design. They can overlap, but they answer different questions.
• Use personas to judge or label real customers. They describe patterns, not people.

Illustrative example

Illustrative. A public library service in a mid-sized Canadian city had a set of seven personas made by an agency three years earlier. Each had an age, a photo, a list of hobbies and a favourite genre. The digital team admitted nobody had opened the file in a year.

When the service planned a new booking system for study rooms and equipment, the team started again. Over three weeks they interviewed fourteen members and non-members, spent two afternoons watching people at the front desk, and read a year of booking complaints. Grouping the evidence by goal, three patterns stood out.

"Planner" booked weeks ahead for group study, cared about certainty and wanted reminders. "Drop-in" arrived and wanted whatever was free right now, and gave up if it took more than a minute. "Helper" was booking on behalf of someone else, usually an older relative or a community group, and needed to manage several bookings without sharing a password. Age did not predict which pattern someone fitted.

The team chose Drop-in as the primary persona, because the existing system failed them worst. Every user story for the new system named one of the three, and usability tests recruited at least two people for each. Helper changed the design most: the team added a way to book on someone's behalf, which no earlier persona had suggested. The old seven personas were archived with a note explaining why.

Questions people ask

How many personas should I create? Usually three to five, with one primary. Fewer than three can hide important differences; more than five is hard to remember and often means some are variations of the same goal.

What is the difference between a persona and an empathy map? An empathy map captures what one person or group says, thinks, does and feels, often from a single round of research. A persona is a more settled description of a recurring pattern across many people. Empathy maps are a good step on the way to personas.

Can I make personas without user research? You can make assumption personas to start a conversation, as long as you label them as assumptions and plan to test them. Presenting invented personas as research is how teams end up designing confidently for people who do not exist.

Where to go next

The persona guide gives you the canvas, stakeholder interviews help you gather the evidence, and affinity grouping helps you find the patterns. For the wider practice these personas belong to, read customer-centric is a practice, not a slogan, and to make sure the research behind them changes something, read from insight to change: turning customer research into decisions.