When three real users want different things from the same feature, someone has to come first. This framework decides who you optimise for — and, crucially, who you deliberately don't.
▸ Try the interactive toolA product often has several real personas — all genuine, all users. But the team can't serve all of them equally in every design decision, because when different personas want different things from the same feature, someone has to come first. The Primary / Secondary / Negative framework makes that choice explicit.
The primary persona is the one you optimise for — when there's a conflict, they win. Secondary personas are served as long as it doesn't compromise the primary. And the negative persona is the one you explicitly don't design for — naming who you're not building for is as clarifying as naming who you are. The framework's value is forcing a hierarchy where teams otherwise try (and fail) to please everyone.
Primary — optimise for them; they win conflicts
Secondary — serve them when it doesn't compromise the primary
Negative — explicitly not designed for; their needs don't drive decisions
A product optimised for everyone is optimised for no one. The hierarchy forces the trade-off that vague “we serve all our users” thinking avoids.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Serving all personas equally | Conflicting needs produce compromise designs that satisfy none. | A primary persona breaks ties cleanly — someone wins. |
| Implicit, shifting priorities | Whoever's loudest in the room wins each decision differently. | An agreed hierarchy makes the priority stable and explicit. |
| No negative persona | The team quietly tries to serve users it shouldn't, bloating the product. | Naming who you don't build for prevents scope creep. |
| Feature tug-of-war | Every feature debate restarts the “who matters” argument. | The hierarchy settles it once, so debates move faster. |
Identify the personas who genuinely use the product but want different things from the same decisions. These conflicts are why you need a hierarchy.
Pick the one persona you'll optimise for when needs conflict — usually the one most central to the value and the business. This is the hard, clarifying choice.
Decide who you'll serve as long as it doesn't compromise the primary. Their needs are honoured until they collide with the primary's.
Explicitly state who you are not designing for. This isn't hostility — it's focus. Their requests don't drive the roadmap.
Test it on an actual contested feature: the primary's need should win. If the team can't accept that, the hierarchy isn't agreed yet.
Three real personas all used a product and all wanted different things from one core feature. Designed to please all three, it became cluttered and confusing — the classic everyone-loses outcome.
The team named one persona primary (the one whose success drove retention and revenue), kept one secondary, and explicitly marked the third negative — a real user whose needs they would no longer let drive that feature. The redesign optimised cleanly for the primary, and although the negative persona lost some convenience, overall the feature finally worked because it was built for someone specific.
The deliverable is a stated ranking — primary, secondary, negative — with the rule for resolving conflicts written down.
| Role | Conflict rule | Effect on the product |
|---|---|---|
| Primary | Always wins | Product is optimised for them |
| Secondary | Served unless it hurts the primary | Honoured within limits |
| Negative | Needs don't drive decisions | Deliberately not catered to |
Deciding who comes first is half the work; deciding who comes last is the other half. The negative persona — explicit permission to disappoint someone — is what makes real focus possible.
The framework works because it converts an emotional, recurring argument into a settled rule. Without it, every feature debate re-opens the question of whose needs matter, and the answer drifts with whoever is most persuasive that day. With a named primary and negative persona, the team resolves conflicts by reference to an agreed hierarchy rather than re-litigating values each time — which is faster, more consistent, and produces products that are actually for someone.
“They're all important” is how you get a product for no one. Choose.
Without explicitly naming who you don't serve, scope quietly expands to everyone.
If the loudest stakeholder keeps overriding it, the hierarchy is decorative. Hold the line.
The negative persona is often a perfectly good person — just not who this product is for. It's focus, not judgement.
You first build the personas (Tool 12), then rank them here when their needs collide.
The hierarchy is the tiebreaker behind many prioritisation calls — the primary persona's needs score higher.
You position for the primary persona; the negative persona clarifies who you're not talking to (Tool 15).
Roadmap conflicts resolve in favour of the primary persona — the hierarchy is a standing filter.
Name two or three real user types for a product. Pick one as primary (wins conflicts), and — the hard part — explicitly name one as negative: whose needs won't drive decisions.
Test it on a real feature where the personas would want different things. Does optimising for the primary feel right, even at the negative persona's expense?
If naming a negative persona feels uncomfortable, that's the sign it's doing its job — focus always means consciously choosing to disappoint someone.