User-first
User-first puts the end user’s experience and needs among the first-class inputs to a feature: present at inception, and still present while it is being built.
Also called UX-first. The two halves are equally important and the second is the one that gets dropped.
First-class, and what that actually means
Section titled “First-class, and what that actually means”A concern is first-class when it can change the decision. By that standard, most products that describe themselves as user-centred are not: the user appears as a persona slide at kickoff and as a satisfaction survey after release, and in between, every decision that shaped the experience was made on other grounds.
First-class means the user’s need is one of the things that can send a story back, alongside feasibility and cost — and that somebody in the room is accountable for it.
The cheap diagnostic: who can say no, and on what grounds? If cost and feasibility can stop a story and usability cannot, the priority order is already written down, whatever the strategy deck says.
At inception
Section titled “At inception”The journey is the first artefact, ahead of the screens and ahead of the schema. Before the system is described, describe:
- who has to live with this, in the plural — the primary user, and the people downstream of them who never chose the software;
- what they are trying to accomplish, in their words, not as a feature name;
- what it costs them when it goes wrong — the actual cost, in time, money, embarrassment or risk, which is what tells you how much to invest;
- what they do today instead, which is the thing you are really competing with and is almost never nothing.
This feeds directly into story mapping, where the journey becomes the backbone of the map, and then into example mapping, where the needs become rules and concrete examples.
During development
Section titled “During development”This is the half that gets dropped, and dropping it quietly undoes the first half. A journey agreed at inception and not revisited for six weeks is an assumption, not a requirement.
Keeping it first-class during development means:
- the running thing is reviewable by a designer and a user before it is done — preview deployments per pull request, not a demo at the end of the sprint;
- accessibility is a design constraint, checked in the acceptance suite rather than audited late, when the only affordable fixes are cosmetic;
- the UX designer is a participant rather than a supplier — in the same session where the examples are written, not upstream of it handing over mockups.
What user-first produces
Section titled “What user-first produces”The output of this attitude is not a set of screens. It is the raw material the contracts are written from:
| Finding about a person | Becomes |
|---|---|
| The journey and its decision points | The backbone of the story map |
| What happens when it goes wrong for them | A state card, checked against the states the design system already covers |
| What they need to be able to perceive and operate | The accessibility guarantees the contracts already make on every screen’s behalf |
| How urgent, how frequent, how recoverable | Which established patterns this story reaches for — and, occasionally, a change request for one that is missing |
Two directions are running here, and it is worth separating them.
Over the life of the system, user-first is what the contracts were built out of. Every role, state and guarantee in them started as a finding about a person.
Within one feature, the contracts are already there, and user-first decides which of them this story needs — and, in the small number of cases where nothing fits, raises a change request against them.
Both matter, and confusing them is expensive in a specific way: a team that thinks each feature must re-derive the contract from research will re-derive it slightly differently every time, and call the result inconsistency. Contract-first is what stops findings from being renegotiated quietly; being established is what stops them being re-litigated weekly.
The failure modes
Section titled “The failure modes”Three, and they are recognisable from across the room.
The proxy. Nobody has spoken to a user; the product owner speaks for them. This can be fine for a while and is unfalsifiable, which is the danger: there is no moment at which the team discovers the proxy was wrong.
The late review. The user sees it at the end, when the only fixes that fit the budget are cosmetic. The feedback is real and arrives after the point where it could have changed anything, which teaches the team that user feedback is expensive noise. The cure is not more feedback but earlier feedback, on a prototype, before it is expensive to act on.
The persona in amber. A research artefact written once, never revisited, increasingly wrong, and cited with more authority every quarter precisely because nobody remembers how it was made.
Where it connects
Section titled “Where it connects”- Journey mapping is the artefact this attitude produces first.
- Story mapping and example mapping are where the findings enter the team’s own rituals rather than sitting beside them.
- Contract-first is what makes any of it enforceable.
- Journey tests are where the journey stops being a document and becomes something that can fail.
- Usability testing is where this attitude is checked rather than asserted: a person who did not build it, attempting the thing.