User Personas: Cooper’s Method, and When an Archetype Works Better
A user persona is a short profile of one invented person who represents a real group of users, built from research and used to keep design decisions anchored to someone specific.
Before you start
Is a persona your framework?
A persona answers one question: who are we building this for? It does not tell you what they are trying to achieve, what they go through, or what to build next. Those are different questions with better tools for each.
Then check whether you have any research. A persona built from a room full of opinions is a group guess wearing a photograph, and it will be quoted for years as though it were evidence.
| If your real question is… | You probably want |
|---|---|
| What is the customer actually trying to get done? | Jobs to Be Done — focuses on the job, not the person doing it, so it survives when your users change Compare Personas and Jobs to Be Done |
| What does the customer go through, step by step? | Customer Journey Mapping — lays out the experience over time; a persona is usually the character who walks that map Compare Personas and Journey Mapping |
| What is one user thinking and feeling in a particular moment? | Empathy Mapping — a single-session tool for one situation, much lighter than a persona |
| How should we divide the market and choose who to sell to? | STP Framework — segmentation for marketing strategy, where personas are for design |
| How do we turn what we know about users into things to build? | User Story Mapping — converts understanding into a release plan |
| We have no research at all and need to start somewhere today | Start with a proto-persona — covered below — but treat it as a list of guesses to go and test |
| We need one shared, memorable picture of who we are designing for, grounded in research | User Personas — you are in the right place |
The test that separates a persona from a character
Point at any detail on the persona and ask which piece of research put it there. The behavior, the goal, the frustration and the skill level should all have an answer. The name, the face and the coffee order should not, and that is fine, because they are only there to make the rest memorable.
The trouble starts when nobody can tell the two kinds of detail apart. Then the team argues about what she “would” do, and an invented biography quietly becomes the evidence.
What Is It?
A persona is a short profile of one made-up person who represents a real group of your users. It usually fits on a single page: a name, a photograph, what this person is trying to do, what gets in the way, and how comfortable they are with the kind of tool you are building.
The reason to invent a person rather than write a summary is that teams argue differently about people than about data. “Users want a simpler screen” is a sentence anyone can agree with and nobody can act on. “Rina has ninety seconds between customers and cannot use both hands” settles design questions on its own.
That strength is also the risk, and it runs through the whole of this page. The invented details are what make a persona memorable, and they are also what make it easy to mistake for knowledge. Everything below is really about keeping those two things apart.
Quick Reference
The canonical structure
What goes into a persona
Six parts, and they do not all do the same job. One of them is there to make the persona stick in people’s heads. Five of them are the actual findings. The last column tells you which is which.
| Part | What it is | Where it comes from |
|---|---|---|
| Name and face | A first name and a photograph, so people can refer to her in a meeting without saying “persona two”. Pick a name that fits the market you are actually in. | Invented. Nothing here is a finding. |
| Behavior pattern | What this group of people actually does, described as a habit rather than a one-off. This is the spine. If two personas have the same behavior pattern, they are the same persona wearing two photographs. | Research. This is the finding everything else hangs on. |
| Goals | What she is ultimately trying to achieve — not the steps she takes. “Get paid before rent is due” is a goal. “Tap the transfer button” is a task. Cooper’s whole method turns on this difference, because tasks change whenever you redesign the screen and goals do not. | Research. |
| Context | Where she is, on what device, and what else is competing for her attention at the time. Standing at a market stall in the rain is a design constraint. Sitting at a desk is a different product. | Research. |
| Frustrations | What currently stops her reaching the goal. Keep these specific to the goal above; a general list of annoyances tells you nothing about what to build. | Research. |
| Skill level | How comfortable she is with this kind of tool and with the subject itself. A confident phone user can still be a nervous borrower, and those are two different problems. | Research, though teams routinely guess it. |
The part almost everyone leaves out: pick a primary
Cooper’s method does not stop at making a set of personas. It asks you to choose one primary persona — the one who will not be satisfied by a design built for any of the others, while the others can live with a design built for her.
Without that choice a persona set is just a menu, and a team will try to please every entry on it. Designing for everyone produces a product that fits nobody in particular, which is the exact problem personas were invented to solve. It is also worth naming one or two negative personas: people you have decided you are not building for. Saying so out loud saves an argument every quarter.
Reconciling sources
Persona or archetype?
A user archetype is the same research presented differently. Instead of a named person with a face and a life story, you get a titled behavior pattern — something like “the careful comparer” or “the last-minute topper-up”. Everything factual stays. The invented biography goes.
That sounds like a cosmetic difference and it is not, because the invented parts are the parts that cause trouble.
| Persona | Archetype | |
|---|---|---|
| How it looks | A named person with a photo, an age, a job and a short story | A title describing a behavior, with no invented person attached |
| What people notice first | The person — her age, her photograph, her job title | The behavior itself |
| Strongest when | You need a team, especially outside design, to remember and care about someone | You want attention on what people do, or your research is thin, or you are wary of designing around a stereotype |
| Main risk | The invented details get treated as facts, and a photograph quietly imports assumptions about age, gender and income | Less memorable. Harder to rally people around a title than around a face. |
Why some teams have stopped using personas entirely
Yale’s university IT design team now prefers archetypes, and their reason is worth borrowing whichever you choose. Without a made-up name, a set of demographics and a stock photograph, an archetype does not put a label on your user. It keeps attention on behavior, goals and problems — the things that came out of the research — instead of on the invented person carrying them.
A reasonable middle path: do the research once, then present it as a persona for the people who need to care about someone, and as an archetype for the people who need to design. It is the same finding either way.
Core Features
- Built from research: interviews, observation or usage data, not a workshop of opinions
- Grouped by behavior: people are sorted by what they do, not by how old they are
- Goal-led: each persona is anchored to an end goal that outlives your current design
- Deliberately few: three to five for most products, and one of them primary
- Written to be quoted: short enough that a developer will actually read it
- Kept alive: revisited when the user base moves, or quietly retired
Worked example
An e-wallet in Jakarta, and the persona that misled the team
An illustrative composite. An Indonesian e-wallet with roughly four million monthly users wanted to grow the number of people sending money inside the app. The team ran forty interviews and built three personas.
| Stage | What happened |
|---|---|
| The research | Forty interviews across Jakarta, Bandung and Surabaya, plus six months of app data. Solid material, honestly gathered. |
| The personas | Three profiles, each led by demographics: “Rina, 24, marketing executive, South Jakarta”, and two others built the same way. Photographs, ages, job titles, neighborhoods. |
| What went wrong | Within two months the team was arguing about what Rina “would” do. Nobody could remember which parts had come from an interview and which had been written to round her out, so the invented biography became the evidence. |
| What they missed | The strongest pattern in the data was not demographic at all. A large group topped up in cash at neighborhood shop agents because their income arrived irregularly and in cash. That behavior cut straight across all three personas, so no persona carried it and nobody designed for it. |
| The rebuild | Same research, presented as archetypes named for behavior: the Cash Topper-Up, the Salary Sweeper, the Split-Biller. Nothing new was learned. The findings simply became visible. |
| The result | The roadmap changed within a fortnight. Making the shop-agent network more reliable moved above the redesign of the send-money screen, because the first problem blocked the second. |
What the photograph cost, and what it bought
Sorting people by who they were hid the thing they had in common. Age and job title made three tidy groups, and the behavior that actually mattered ran underneath all three. That is the specific way demographic personas fail: they group on the wrong axis and then look convincing.
But the first set was not wasted, and it is worth being fair about why. It stopped the company saying “the user”. Before Rina existed, engineering and marketing had been arguing about an abstraction; afterwards they were arguing about a person, which is a better argument to have. The mistake was not inventing her. It was failing to mark which parts of her were invented.
When to Use
- You have real research and need the whole team to act on it, not just the researchers
- People outside design keep saying “the user” and meaning different things by it
- Your users clearly split into groups that behave differently
- You are prioritizing features and need a way to ask who each one is for
- Loud customers are dominating decisions and you need to represent the quiet majority
- You are entering a market you do not personally belong to
When NOT to Use
- You have no research, and no plan to get any
- You have few enough customers to simply talk to them individually
- Your users genuinely all behave the same way
- The real question is what people are trying to achieve — use Jobs to Be Done
- The team is likely to treat the personas as real customers and stop doing research
- Someone senior wants personas as a deliverable rather than as a decision-making tool
In practice
How personas go wrong
Almost every failure below comes from the same root: the invented parts and the researched parts get mixed together, and after a few months nobody can separate them again.
| Failure mode | What it looks like | What to do instead |
|---|---|---|
| Made up in a meeting room | A workshop produces three personas in an afternoon, and they are quoted for two years as though they were research | Call an unresearched persona a proto-persona, write the assumptions down as questions, and go test them. |
| Grouped by demographics | Personas split by age, income or job title, while the behavior that matters cuts across all of them | Group by what people do. If two personas behave the same way, merge them. |
| Wall art | Beautifully designed posters that nobody has opened since launch day | Judge them by whether they get cited in a decision. If they never are, they are decoration. |
| No primary | Five equal personas, and a product that tries to satisfy all five | Name the primary one and say out loud what the others will have to live with. |
| Left to rot | Personas built for the users you had three years and two markets ago | Put a review date on them. Retiring a persona is a perfectly good outcome. |
| The stereotype problem | A stock photograph and an age quietly decide what the team assumes about income, ability and confidence | Switch to an archetype, or strip the persona back to behavior and goals. |
Sourced
Evidence, and how to cite it
The usual date is wrong. Personas were in use from 1983 and published in 1998.
Alan Cooper is often credited with inventing personas in 1999, which is the year of a later printing rather than a first appearance. By his own account he was writing a project-management program called Plan*It in 1983 when he interviewed seven or eight likely users and found they fell into three distinct groups, separated by their goals, tasks and skills. One of them, a woman named Kathy who handled scheduling at an advertising agency, became his first rough persona. The technique reached the public in The Inmates Are Running the Asylum, published in 1998.
Cooper, A., ‘The Origin of Personas’, Cooper Journal; Cooper, A. (1998) The Inmates Are Running the Asylum. Indianapolis: Sams.
Cooper said himself that the book everyone learned from was never a manual.
Personas spread through the software industry on the strength of a single chapter about twenty-five pages long. Cooper later wrote that many designers had been using those pages as a how-to guide, and that a proper how-to had still not been written. Designers at his own firm, he noted, needed months of practice before he considered them ready. Much of what circulates online as “the persona method” is therefore other people’s reconstruction of a short chapter, which explains why no two templates agree.
Cooper, A., ‘The Origin of Personas’, Cooper Journal.
In practice, personas often decorate a project rather than steer it.
Reviews of how personas are used in industry find the practice scattered, with little agreement on method beyond broad claims that they help. Personas do get referenced across a project, but the reference tends to work as a reminder that customers exist rather than as something that changes a design decision. That is the honest baseline for your own set: not whether people liked them, but whether a decision went differently because of them.
Summarized in the persona research literature; see the review in Personagram (arXiv, 2026) and the sources it collects.
A persona with no research behind it has a name, and using it honestly is fine.
A proto-persona is one a team writes from its own assumptions, without field research. The idea comes from the Lean UX approach of Jeff Gothelf and Josh Seiden, and the method is explicitly a loop: state your assumptions as a rough persona, go and research whether they hold, then correct it. Used that way it is a reasonable first move when there is no budget. The failure is stopping after the first step and letting a guess harden into a fact, which is what most criticism of personas is actually about.
Gothelf, J. & Seiden, J. (2013) Lean UX. Sebastopol: O’Reilly.
How to cite it.
Harvard: Cooper, A. (1998) The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis: Sams.
APA: Cooper, A. (1998). The inmates are running the asylum. Sams.
For the origin story, cite Cooper’s own essay ‘The Origin of Personas’ rather than a secondary blog, since the 1983 date and the Kathy account come from him directly. For proto-personas, cite Gothelf and Seiden’s Lean UX (2013).
Key Strengths
- They travel: a persona carries research to people who will never read a research report
- They settle arguments: a concrete person turns taste debates into questions with answers
- They protect the quiet users: someone in the room now represents people who do not complain
- They are cheap once the research exists: the cost is the interviews, not the artifact
- They make exclusion explicit: naming who you are not building for is a real decision
Key Weaknesses
- Invented detail looks like evidence: the single biggest problem, and it worsens with time
- Only as good as the research: thin research produces a confident, wrong picture
- They can import stereotypes: a photo and an age carry assumptions nobody chose
- They date quietly: nothing announces that your users have moved on
- Easily decorative: the poster is finished long before the thinking is
- They describe people, not problems: for the underlying need, you need another tool
Sequencing
What to run before and after
A persona is a way of presenting research. It is worth very little on its own, and quite a lot in the middle of a sequence.
Before
Do the research, and sort people by behavior
Interviews, observation or usage data first. Then group people by what they do, not by who they are. This step decides whether the personas will be useful, and it is the step most often skipped.
During
Give the persona somewhere to walk
A persona on its own is a portrait. Put her through a journey map or an empathy map and she starts producing findings — where she gets stuck, what she is feeling at the point she gives up.
After
Turn the understanding into a plan, and set a review date
Personas earn their keep when they shape what gets built. Carry them into the backlog, and put a date in the calendar to check whether they still describe your users.
Common questions
User personas: quick answers
What is a user persona?
A short profile of one invented person who stands in for a real group of your users. She has a name and a face so people can talk about her, but the parts that matter — what she does, what she wants, what gets in her way — all come from research. The purpose is to stop a team saying “the user” and meaning something different each time.
Who invented personas, and when?
Alan Cooper. He first used the technique in 1983 while writing a project-management program called Plan*It, after interviewing seven or eight likely users and finding they fell into three groups separated by goals, tasks and skills. Kathy, who handled scheduling at an advertising agency, was his first rough persona. He published the method in The Inmates Are Running the Asylum in 1998. The widely quoted date of 1999 refers to a later printing.
What is the difference between a persona and a user archetype?
The research is the same; the presentation differs. A persona is a named person with a photograph, an age and a short life story. An archetype is a titled behavior pattern, such as “the careful comparer”, with no invented person attached. Personas are easier to care about. Archetypes keep attention on what people do and avoid importing assumptions through a stock photo, which is why some design teams now prefer them.
What goes into a user persona?
Six parts. A name and face, which are invented. Then five that should come from research: the behavior pattern that defines the group, the goal she is ultimately trying to reach, the context she is in, the frustrations blocking her, and her skill level with this kind of tool. Keep the invented parts clearly separate from the researched ones, because that distinction is what most persona failures come down to.
What is a primary persona?
The one you design for. In Cooper's method the primary persona is the one who would not be satisfied by a design built for any of the others, while the others could live with a design built for her. Skipping this choice means trying to please every persona at once, which produces a product that suits nobody in particular. It is also worth naming a negative persona: someone you have decided you are not building for.
What is a proto-persona?
A persona built from a team's own assumptions rather than from research. The term comes from the Lean UX approach of Jeff Gothelf and Josh Seiden, where it is the first step in a loop: write down what you think is true, test it, correct the persona. That makes it a sensible start when there is no research budget. The failure is stopping after step one and letting a guess be quoted as a finding.
How many personas should we have?
Three to five for most products, and fewer is usually better. The number should come from how many genuinely different behavior patterns your research found, not from how many market segments the business talks about. If two personas do the same things for the same reasons, they are one persona with two photographs. Whatever the count, one of them has to be primary.
Do personas actually work?
It depends entirely on what happens after they are made. Reviews of industry practice find personas widely produced and only loosely used — referenced as a reminder that customers exist more often than as something that changes a decision. They work when built on real research, grouped by behavior, given a primary, and cited in real decisions. They fail when invented in a workshop and pinned to a wall. Judge your own set by whether a decision ever went differently because of them.
How do I cite personas?
Harvard style: Cooper, A. (1998) The Inmates Are Running the Asylum. Indianapolis: Sams. APA style: Cooper, A. (1998). The inmates are running the asylum. Sams. For the origin story and the 1983 date, cite Cooper's own essay The Origin of Personas rather than a secondary blog. For proto-personas, cite Gothelf, J. and Seiden, J. (2013) Lean UX. Sebastopol: O'Reilly.
Deep Resources
Frameworks related to User Personas
- Empathy MappingA visual tool that captures what users think, feel, say, and do to build shared understanding…
- Jobs to Be DoneUnderstand what customers are trying to accomplish by analyzing functional, emotional, and…
- Customer Journey MappingVisual representation of all customer interactions across channels and touchpoints, revealing…