User Personas: A Practical Guide to Personas That Change Decisions

Most teams who build personas shouldn't have. If your product has one kind of user pursuing one goal, the set is overhead — talk to eight of them and skip the artifact. Personas earn their cost in one situation, narrower than their reputation suggests: when two groups of users want incompatible things, and somebody has to decide whose problem gets solved first.

The reputation comes from the poster — stock photo, alliterative name, a quote in large italics nobody said — which has hung in an office somewhere for two years without changing a decision. When people argue that personas are dead, that is generally what they are arguing with.

What a persona is actually for

Every design decision of consequence is that tradeoff wearing a different hat. The power user wants density, the newcomer wants breathing room. The admin wants control, the person using the thing daily wants defaults that already work. A persona set makes the tradeoff explicit and assigns it a winner in advance, so the argument gets had once rather than in every review.

The second job is memory. Research decays fast — a report gets read once, filed, and six weeks later the team is designing for itself again. A persona compresses a pile of interviews into something a room can hold, and, more usefully, something a room can argue with (NN/g on what personas are for). "Would she really do that?" is a productive sentence in a design review. It only stays productive if the answer is checkable, which means the persona has to be built out of things somebody watched happen.

What earns its place on one

One filter, applied to every attribute: name the design decision this would change. If you can't, cut the line.

What usually survives the filter:

• The goal, in their terms rather than your feature's. Not "uses the reporting module" — needs to walk into Monday's meeting able to defend last week's numbers.
• The context of use. Where, on what device, under what interruptions, with how much time. It decides whether the design has to survive one hand and thirty seconds.
• The current workaround. What they do today instead of using you. Leave it off and you lose the roadmap — whatever people currently do instead is what you are actually competing with.
• Expertise, split in two — domain expertise and tool expertise. These are separate axes, and collapsing them into one "tech-savviness" bullet is how onboarding ends up wrong for both ends.
• What would make them leave. The failure they won't forgive.

What usually doesn't: marital status, favorite brands, the personality sliders with no units, the invented quote. A stock photo does one legitimate job, which is making the persona easy to refer to in conversation, and one illegitimate one, which is lending made-up details the texture of evidence.

Age shows the filter working. On a product with an accessibility floor to clear, or a real generational split in the install base, age changes decisions and belongs on the sheet. On most B2B tools it changes nothing and is there because the template had a slot for it.

Deriving them from behavior

Here is where sets go wrong before anyone writes a word. The intuitive order is to pick some plausible customer types, then hunt for behaviors to hang on them. Personas built that way can only return what you already assumed — which is also the quiet reason so many sets ratify the roadmap the team had already agreed on, the confirmation bias problem in artifact form.

Reverse it. Start from behavior and let the attributes attach at the end:

1. Get eight to twelve people to walk you through the last time they did the thing. Last time specifically, not what they generally do — the interview technique matters here more than the sample size.
2. Extract behavioral variables — what people do, and how it varies. Each becomes an axis with two ends. Six to ten axes is normal.
3. Plot every participant on every axis. Physically, one row per person. This step is boring and is the step that works.
4. Look for people who land together on four or more axes at once. Those co-occurrences are the candidate personas. Two people agreeing on one axis is noise.
5. Name each cluster by the thing that distinguishes it. If the only name you can find is a demographic, you clustered on the wrong axes.

If nothing clusters, the honest read is that you have one persona — a real finding, and a cheaper one to reach in week one than in the third review of a set nobody believes.

A worked example

Abstract advice about personas is how you get posters, so here is the shape of the output on a concrete case — a payroll tool, illustrative rather than from a specific engagement.

The axes that came out of the interviews:

• runs payroll alone ↔ needs a finance lead to sign off
• steady monthly cycle ↔ constant contractor churn
• inherited the system from someone who left ↔ chose and configured it themselves
• trusts the defaults ↔ reconciles every line against their own spreadsheet
• an error is an inconvenience ↔ an error is a compliance event

Two clusters, and note that neither is a demographic:

The inheritor. Didn't choose the tool. Learned it from a predecessor who is gone. Reconciles everything against a spreadsheet, because they don't trust configuration they didn't do and can't see the reasoning behind. Treats every error as a compliance event.

The operator who set it up. Configured it, trusts the defaults because they picked them, absorbs weekly contractor churn, treats errors as friction.

That set settles a real argument: whether the settings surface optimizes for configuring the system or for auditing what somebody else configured. Those are different screens. The inheritor never sees the setup wizard — they arrive needing what is this currently set to, and why, which no amount of polish on a first-run flow will answer. Without the set, that argument is two senior people's intuitions. With it, it's a question about which persona is primary.

Proto-personas, buyer personas, and segments

Four things get called personas. NN/g sorts them by how much evidence sits underneath, which is the distinction that matters.

Proto-personas are assumption-based — an afternoon in a room capturing what the team currently believes. Genuinely useful as a hypothesis and as a screener for the research that will replace them. The failure mode is that nothing on the sheet announces itself as a guess, so it hardens. Mark the assumed cells in the file itself, not in the meeting where you made them.

Buyer personas model a purchase: budget, objections, approval chain, where they look for comparisons. User personas model use. In B2B these are frequently different people with opposing interests, and merging them is how a product ends up optimized for whoever signs the cheque and merely tolerated by whoever opens it daily.

Segments are statistical groupings — 25–34, urban, iOS, two sessions a week. A segment can size an opportunity. It can't settle a design argument, because it says nothing about what anyone is trying to do. Keep both and don't expect either to do the other's work.

Jobs to be done gets framed as the rival and mostly isn't. The job models the situation and the outcome someone is hiring the product for; the persona models the person and their constraints. If you can only afford one, build the job — it tells you what the product must do. The persona answers the question the job leaves out, which is who is doing it, with what expertise, and under what interruptions.

Designate a primary, or the set decides nothing

A persona set needs a primary: the one whose needs, if unmet, mean the product has failed, even if everyone else is perfectly served.

This is the load-bearing part, and the part that gets skipped. Designing for all your personas averages them into a person who doesn't exist, which lands in the same place as having no personas — for more money. In the payroll example, picking the inheritor as primary means the audit view gets built first and the setup wizard waits. Picking the operator means the reverse. The set made that choice visible and forced someone to own it.

Naming a primary is uncomfortable because it's a real prioritization with real losers, and "they're all important to us" is the available exit. NN/g's account of why persona projects fail points at adoption rather than craft, and this is where adoption is won or lost: a set that has never been given the authority to decide anything won't be consulted, no matter how good the research under it was.

When it isn't worth building

Before committing, name the argument that's currently stuck. We can't agree whether the setup flow serves the evaluator or the person who inherits the account is a stuck argument, and a set will unstick it. "It would be good to have a shared picture of our users" is a wish for alignment, and research is an expensive way to buy alignment the team could simply agree on.

Three months on, the same question works as an audit. If nobody can point to a decision that went differently, the set isn't being used, and rebuilding the sheet won't fix that. Attach it to a live argument or retire it.

FAQ

How many personas should we have? Two to four, one of them primary. Past four, nobody holds the set in their head, and a set that isn't remembered isn't consulted.

Do personas need a name and a photo? A name, yes — being referable in conversation is most of the point. A photo is optional and carries a cost: it invites biographical invention that no research supports. If you use one, keep the evidence-bearing lines visually distinct from the decorative ones.

Should I use a persona template? For layout, fine — a persona generator saves the afternoon that would otherwise go into formatting. For content, templates are where the useless attributes come from: the slot exists, so somebody fills it. Delete the fields you can't trace to an observation rather than guessing at them.

What is a negative persona? A group you're explicitly not building for, named out loud. Cheap to produce and unusually effective, because it converts "we should probably support that too" from an open question into a decision already taken.

Are personas dead? The poster version earned its reputation. The behaviorally derived version with a designated primary keeps getting rediscovered under new names, because the problem it solves — whose needs win when needs conflict — hasn't gone anywhere.

How is this different from a journey map? A persona describes a person; a journey map describes a sequence. The map needs the persona as its subject, which is why building maps for "our users" produces a journey nobody actually takes.

Take it further

Personas are one artifact in a kit, and knowing which artifact settles which decision is the part worth getting right — the rest of the UX deliverables guide covers the others on the same terms. If your open question is where the experience breaks rather than who it breaks for, start from the research methods overview instead.

Sources: NN/g — Personas: Study Guide · NN/g — 3 Persona Types · NN/g — Why Personas Fail · NN/g — Personas vs. Jobs-to-Be-Done.

Not sure which of your users your product is currently optimized for? Apply for a Full UX Audit →