The UX design process. Five stages, and what each produces.
Most descriptions of this are a diagram with five arrows and no detail about what you actually get. This one names the deliverable at each stage, the decision it unlocks, and the point at which skipping it starts to cost money.
On this page
- 01The five stages are research, structure, interface, prototype, validate. Names differ between studios; the sequence does not.
- 02Each stage should end in an artefact someone can disagree with. If a stage produces only a feeling of progress, it did not happen.
- 03The expensive mistake is jumping to interface design first, because a beautiful screen makes structural problems very hard to raise.
- 04On a small marketing site you can compress stages one and four heavily. On anything with accounts and workflows, you cannot.
- 05Design does not end at handoff. What ships is the design; everything before it was a proposal.
What each stage produces.
1. Research
Understand who uses this, what they are trying to finish, and where the current thing fails them. Interviews, session recordings, support tickets, search queries, and the analytics you already have.
Deliverable: a short written summary of who the users are, the top tasks, and the specific failures observed. Two pages that change decisions, not a forty-slide deck.
2. Structure
Decide what exists and how it is organised before deciding what it looks like: information architecture, the primary flows, and the states each screen can be in. This is where most usability is won or lost.
Deliverable: a sitemap or screen inventory, flow diagrams for the two or three journeys that matter, and low-fidelity wireframes with real labels rather than lorem ipsum.
3. Interface
Now the visual layer: type scale, colour, spacing, components, states. On any project of size this should produce a system rather than a set of screens, or the tenth screen will not match the first.
Deliverable: a component library and the key screens built from it, including empty, loading, error and long-content states. Those states are the ones that get skipped and then improvised in code.
4. Prototype
Make it clickable enough that someone can attempt a task without you narrating. The point is not polish, it is exposing the moments where a real person hesitates.
Deliverable: an interactive prototype covering the primary flows end to end, at whatever fidelity is enough to be tested.
5. Validate
Put it in front of people who resemble your users and watch them try. Five participants surfaces most of the serious problems; you are looking for patterns, not statistics.
Deliverable: a prioritised list of observed problems, each with the evidence attached, and a decision on which get fixed before build.
What you can safely skip.
Running the full process on a five-page marketing site is theatre, and charging for it is worse. The honest version scales with the risk of getting it wrong.
A marketing site can compress research into a couple of conversations and existing analytics, and replace formal testing with launching and reading behaviour. Structure still matters; skipping it is what produces a site nobody can navigate.
A product with accounts, roles and workflows needs all five. The cost of a structural mistake here is a rebuild, not a redesign, and it will not be visible in a screenshot.
A redesign of something that already exists should invert the emphasis: you already have users and data, so research is cheap and unusually reliable. Look at what people actually do before deciding what to change. See website redesign.
The stage nobody should skip is the one that produces states: empty, loading, error, and content much longer than the mock. Skipping it does not save design time, it moves those decisions to a developer at 5pm on a Friday.
Six answers.
What is the difference between UI and UX?
UX is whether the thing works for the person trying to finish a task: what exists, how it is organised, what happens next. UI is the surface they touch: type, colour, spacing, components, states. In practice they are done by the same people and separating them is mostly useful for explaining where a problem lives, not for dividing the work.
How many users do we need to test with?
About five per distinct user type gets you most of the serious usability problems. This is qualitative work: you are looking for repeated hesitation and repeated wrong turns, not a statistically significant result. If you need statistics, that is a different exercise, run on live traffic after launch.
Do we need wireframes if we have a design system?
Yes, though they can be fast and rough. A design system answers what things look like; it does not answer what should be on the page or in what order. Skipping straight to composed screens is how teams end up debating a button colour while the flow underneath is wrong.
How long does the process take?
A compressed marketing-site pass is a couple of weeks. A product with several roles and real workflows is a couple of months before build starts. The reliable predictor is not the number of screens, it is how many distinct user types and states exist, and how quickly your side can make decisions.
Where does accessibility fit?
In stages two and three, not as an audit at the end. Contrast, focus order, target size, form labelling and keyboard paths are design decisions. Retrofitting them after build is far more expensive than making them in the component library, and an end-stage audit only tells you what you now have to undo.
What should we get at handoff?
The component library with its states, the screens composed from it, the prototype, the tokens for type, colour and spacing, and written notes on behaviour that a static file cannot show: what happens on error, what happens with no data, what happens on a slow connection. A folder of pretty screens is not a handoff.
Tell us what you are designing.
How many user types, whether there are accounts, and whether something exists today. That is enough for us to say which stages you actually need and which would be us billing you for ceremony.
Published .
