All 29 modules are open from the start — nothing here is
locked, and nothing costs anything. Sign in so your progress, titles and
credentials stay with you, on every device you use.
Free forever, with your Google account. No password, no payment.
Turn dry research data into a person your team can build for
A user persona converts rows of statistics and interview notes into a vivid, realistic
profile, so the whole team designs for the same real human instead of a vague "user".
This guide shows how to build personas that actually drive decisions.
Ready?
1
The Anatomy of a Persona
A persona is a short, evidence-based description of one type of user, written so that a team can make decisions on their behalf when that person is not in the room.
The emphasis belongs on decisions. A persona is not a character study and it is not a marketing artefact. It exists to settle arguments.
A useful one has four layers. Context: their situation and the constraints they work under. Goals: what they are trying to achieve — not with your product, but in their job or life. Behaviours: what they actually do today, including their workarounds. Frustrations: where it currently breaks down.
Notice what is absent. No age, no stock photograph, no hobbies. Those make a card feel like a person and have never once settled a roadmap argument. The test for any line is blunt: would a decision change if this line were different? If not, it is texture.
Four layers, and the rule down the side is a condition on all four rather than a note about the first. Every line has to survive one question: would a decision change if it said something else? An age and a stock photograph never survive it, because nothing was ever going to turn on them.
Everyday example, describing a friend for a blind date
If you set a friend up on a date, you'd describe them in a way that hangs together:
who they are ("Maya, 29, nurse"), what they do ("hikes
every weekend, terrible at texting back"), what frustrates them ("hates
loud, crowded bars"), and what they want ("someone easy-going for quiet
dinners"). Notice it all connects, the frustration (loud bars) and the goal (quiet
dinners) fit. If you said "hates crowds" but "wants a partner for nightclubbing," the
date would sense something's off. A persona works the same way: the four parts must tell
one believable story.
Identity
Profile & demographics
A name and a life. "Rohan, 34, software architect."
Habits
Behaviors
What they do routinely. "Automates everything, lives by keyboard shortcuts."
Friction
Pain points
What blocks them. "No time to cook; big menus cause decision fatigue."
Progress
Goals & motivations
What they want instead. "Healthy food sorted instantly, no thinking required."
The persona that settled an argument
A team had a six-month disagreement about whether to add an approval workflow. Their persona work showed the primary user had no authority to approve anything and always forwarded to someone outside the product. The argument ended in a meeting, because the persona answered a question the opinions could not.
Quick check: spot the broken quadrant
A draft persona for a premium grocery app: Rohan, 34, works 60-hour weeks, automates
everything, and his pain is having no time to cook healthy meals. His listed goal reads:
"wants to hunt for the cheapest bulk discounts on cleaning supplies." What's wrong?
2
Root Every Line in Real Data
The difference between a persona that works and one that quietly does damage is entirely about where its lines came from.
An invented persona is worse than no persona at all, because it carries the authority of research with none of the evidence. Once something is printed on a card, people stop asking “do we actually know that?” — and the assumption gets cited in decisions for years.
The defence is a traceability audit. Something specific and findable. Any line that traces to “we assumed” or “someone said in a meeting” is either removed or clearly marked as an open question rather than a finding.
This is uncomfortable in a useful way, because personas accumulate plausible detail — and plausible detail is precisely what cannot be distinguished from evidence once it has been written down neatly.
Two habits keep them honest. Put the source next to each claim, visibly, so anyone reading can weigh it. And re-check on a schedule, because personas decay: your customers change, and your product changes who it attracts. A persona written two years ago and never revisited is describing a company you no longer run.
Nothing in the right-hand column is a lie. It is all plausible, which is exactly the problem — set one of those lines beside four that trace to interview notes, print the card, and within a month nobody in the room can tell you which column any given line came from.
Everyday example, a police sketch vs. fan fiction
A police sketch artist draws only from what witnesses actually saw, every feature traces
to real testimony. Useful. Fan fiction invents whatever the author fancies, fun, but it
tells you nothing true about a real person. A data-backed persona is the sketch;
a made-up one is fan fiction. The dangerous part is that invented personas feel
just as vivid and convincing as real ones, so teams confidently build for a person who
doesn't exist. The fix is simple and strict: for every line on the card, ask "what real
quote or number is this based on?" No source, no line.
Guesswork
Decorative fluff
"Drinks oat-milk lattes, listens to indie vinyl, enjoys rainy weather." Charming, and useless for deciding what to build.
Tracked data
Behavioral evidence
"Abandons checkout whenever the form has more than 3 steps." Directly shapes the conversion flow and engineering scope.
The traceability audit
For each trait on the persona, draw a line back to its source: a quote from an interview
or a metric from your analytics.
If a trait has no source, delete it. No exceptions.
The trait that traced to nothing
An audit walked each line of a persona back to its source. "Prefers mobile" came from a stakeholder's assumption, and the analytics said the opposite — 80% of sessions were desktop. Two roadmap items had been justified by that line, and both were dropped that week.
Quick check
A persona card states: "Priya, 34, lives in Bristol, enjoys cycling and podcasts, and needs a faster way to reconcile invoices." Which line is doing real work?
3
Personas as a Decision Compass
The value of a persona is realised at exactly one moment: when a team has to choose between two reasonable options and cannot agree.
It works as a filter too, and this is the less comfortable half. If a request would only serve someone unlike your persona, that is a real signal — either the request is genuinely out of scope, or your persona is wrong and needs revisiting. Both are useful outcomes; what is not useful is building it while leaving the persona untouched, which teaches everyone that the persona does not mean anything.
And a persona can change the shape of a decision rather than vetoing it. If your primary user has no budget authority, an in-product upgrade flow is not wrong — it needs a way to hand off to the buyer rather than a credit-card field the user cannot fill.
The habit is small and it is what makes the whole exercise pay: when an argument stalls, say the persona’s name out loud and ask what they would actually do. If nobody can answer, the persona is not finished — and that is worth knowing before the next argument.
Three exits, drawn the same size on purpose — a veto, a redesign and an admission are all wins here. There is no fourth branch for building it anyway and leaving the card alone, and a team that takes that route twice has taught itself the persona is decoration.
Everyday example, "what would Grandma do?"
If you're building a gadget for your grandmother, every time the team argues you can ask:
"would Grandma actually use this? Could she even find the button?" Suddenly the debate
stops being about opinions ("I think it's cool") and becomes about a real person. A
persona is that Grandma-in-the-room, a shared, named human you point to when someone
says "users want X." Instead of "I feel…" versus "I feel…", the question becomes "does
this serve Rohan's actual pains?", which usually has a complete answer.
A worked example
Your food-app team is split over what to ship next for Busy Rohan
(time-starved, decision-fatigued):
Feature A: a one-tap "reorder my usual" button on the home screen. Feature B: a bulk-discount calendar that saves 15% but needs a 10-minute setup.
Verdict: Feature A. It attacks Rohan's actual pains, time and decision load. Feature B
asks him to spend the very thing he lacks.
The persona as tie-breaker
A food-app team was split between a loyalty scheme and faster reordering. Their primary persona ordered the same three meals on a weekday commute and had never once opened the offers tab. The disagreement ended in ten minutes, on evidence rather than seniority.
Quick check
Your persona says the primary user has no budget authority and always forwards pricing questions to someone else. The team is debating an in-product upgrade flow with a credit-card step. What does the persona tell you?
Drill what you learned
Scenario 1
easy
Your engineering lead says personas are a waste of time: 'Let's just build for everyone and maximize the market.'
What's the strongest counter?
Scenario 2
easy
A designer adds 'loves outdoor mountain biking' to your fintech persona, saying it makes the persona feel more human.
How do you evaluate the addition?
Scenario 3
easy
For 'Busy Rohan' (time-starved, decision-fatigued architect), the team is split: Feature A is a one-tap 'reorder my usual' button; Feature B is a bulk-discount calendar that saves 15% but needs a 10-minute setup.
The persona says…?
Scenario 4
easy
A stakeholder builds a persona from scratch in a meeting, purely from imagination, without any user research: "I just know our users — they're 35, busy, and love automation."
What's the core risk?
Scenario 5
easy
Your team has created 11 detailed personas to "cover all our users." In practice, nobody can remember them and they're never referenced in decisions.
What's the problem, and the fix?
Scenario 6
medium
A persona lists the pain "gets overwhelmed by too many options" but also lists the goal "wants a fully customizable dashboard with 50 configurable widgets."
What's wrong?
Scenario 7
medium
Marketing built buyer personas focused on brand attitudes and media habits. Your product team wants to reuse them to prioritize features.
Should you reuse them as-is?
Scenario 8
medium
The personas were built two years ago from research done before a major product pivot and a shift in your user base. The team still treats them as gospel.
What's the concern?
Scenario 9
medium
A PM wants to add a photo and a real-sounding name ("Busy Rohan") to the persona. An engineer objects: "That's just fluff — give me a spreadsheet of attributes."
What's the honest case for the name and photo?
Scenario 10
medium
Your product genuinely serves two very different primary users — an admin who configures it and an end-user who uses it daily — with conflicting needs.
What's the right persona approach?
Scenario 11
hard
A designer proposes a feature and justifies it: "Rohan would love this." When you check the persona, nothing in Rohan's pains or goals relates to the feature.
What's happening, and what do you do?
Scenario 12
hard
Leadership asks: "What's the difference between a persona and a market segment? Aren't they the same thing?"
What's the clearest distinction?
Scenario 13
hard
A persona's "behaviors" quadrant reads: "is a passionate, detail-oriented perfectionist who values quality." An engineer says this doesn't help them build anything.
Why is the engineer right?
Scenario 14
hard
A startup with no users yet and no budget for research insists on creating personas before their first launch.
What's the honest, pragmatic guidance?
Scenario 15
hard
Your beautifully-made persona sits in a slide deck that no one has opened since the kickoff. Features keep shipping based on whoever argues hardest.
What's the real failure, and the fix?
Drilled it. Now apply it to a real situation.
Put it to work
From lesson 1
Alan Cooper invented personas to stop arguing
Alan Cooper
Cooper describes, in The Inmates Are Running the Asylum, arriving
at personas while designing project-management software. Talking about
"the user" produced endless circular argument, because everyone in the
room pictured a different person and each was right.
He began describing a specific, named, invented individual based on the
people he had interviewed — and found that the arguments resolved,
because the room could finally disagree about something concrete.
What does naming a specific person do that "the user" cannot?
Select all that apply — there are 3 to find.
What actually happened
Cooper's point is that a persona is a design tool, not a marketing
artefact. It exists to settle arguments about what to build, which is why
it needs a name, a goal, and a context specific enough that the answer
is sometimes no.
A persona's job is to make "who is this for?" answerable in a meeting. A
persona that never rules anything out is not doing that job.
From lesson 2
A persona with nothing behind it
A savings app
The persona on the wall. Every line was written in a workshop; no
customer was interviewed.
"Sarah, 34, Marketing Manager"
Line on the persona
Where it came from
Enjoys yoga and weekend brunch
Someone in the workshop
Wants to feel in control of her money
Assumed
Checks her balance most mornings
Assumed
Frustrated by hidden fees
A competitor's marketing
Would like to save for a house deposit
Assumed
Which lines would you cut, and why?
Select all that apply — there are 4 to find.
What actually happened
Rebuilt from fourteen interviews and the analytics, the persona lost the
yoga and gained one line that changed the roadmap: "checks the app only
when she is worried about money, roughly twice a month". Every
engagement feature on the plan had assumed the opposite.
Every line should be traceable to a specific piece of evidence and should
imply a decision. If it does neither, it is set dressing that makes
assumptions feel like findings.
From lesson 3
Using the persona to say no
A veterinary practice tool
The primary persona is a practice nurse who uses the system between
consultations, on a shared machine, often with an animal on the table.
Four requests arrive in one week.
Work each request against the persona.
Step 1 of 3
"Add a customisable dashboard so each user can arrange their own widgets." What does the persona say?
Rejected on context, not on merit. It would be a good feature for a different persona.
Step 2 of 3
"Add keyboard shortcuts for the ten most common actions." And?
Same persona, opposite answers, both from the context line.
Step 3 of 3
A request arrives from the practice owner: bulk financial reporting across sites. The persona says no. What now?
Personas do not decide. They make what you are deciding visible.
What actually happened
Shortcuts shipped and cut average consultation-note time by 40 seconds.
Reporting went to a separate admin view for the owner persona. The
dashboard was never built, and nobody asked again.
Point every request at the persona and see whether it is answerable.
When the answer is "that is a different person", you have found a
decision rather than a feature.