The UX Design Process: Six Stages, and Which Ones You Can Skip

Search the UX design process and you get the same diagram every time. Five circles, arrows clockwise, empathise through to test. It is a fine teaching model and a poor description of what happens when a real team with a deadline designs something.

What follows is the version we actually use, stage by stage. For each one: what it produces, what it is protecting you from, and the specific conditions under which you can skip it. That last part is the useful bit, because on most projects you will skip at least two, and the question is which.

One framing before the stages. The UX design process is a sequence of decisions, not a sequence of deliverables. Every artefact exists to make a decision safe. If a stage is not changing a decision, it is theatre, and you should cut it.

Stage 1: Framing

Produces: the decision this work exists to make, the constraints that are genuinely fixed, and the measure that would tell you it worked.

Not "improve onboarding" but "decide whether the drop-off between signup and first project is a comprehension problem or a value problem, because the fix is completely different".

Protects you from: the most expensive failure available, which is doing excellent work on the wrong question. It happens in week one and nobody notices until launch.

Skip it when: never. It takes a day. The only version of skipping this that is defensible is doing it in an hour rather than a day.

Stage 2: Research

Produces: findings with a confidence level attached to each. Twelve interviews and one support anecdote should not carry equal weight in the next decision.

Some combination of user interviews, conversations with the people who sell and support (who often know more), analytics and session review, and a structured walk through the existing product.

Protects you from: building for the loudest user, or for an imagined user who behaves the way the pitch deck says.

Skip it when you already have current, structured evidence about the specific question. That is rarer than teams think, but it does happen: if you have funnel data showing exactly where people drop and session recordings showing why, you do not need to re-interview anyone. Use what you have.

Compress it when the change is small and reversible. A week of interviews for a button placement is not diligence, it is avoidance.

Stage 3: Structure

Produces: information architecture, user flows, and the decision about what a person does immediately before and after each screen.

The least glamorous stage and the one most often skipped, which is why so many products look fine and feel confusing. Structure is cheap to change now and brutal to change later, because by then it is in the navigation, the URLs, the database and everyone's muscle memory.

Protects you from: a product that grows into a patchwork, where feature four does not have anywhere sensible to live.

Skip it when you are adding something inside an existing, working structure and it has an obvious home. If you find yourself arguing about where a new thing should go, you are not skipping this stage, you are doing it badly in a meeting.

Stage 4: Design and states

Produces: the actual screens at production quality, and every state each one needs.

Two things separate this from drawing screens. First, states: empty, loading, error, partial, dense data, long text, no text. That is where products fail in real use, and where most design work is quietly incomplete. Second, systemisation: anything appearing more than twice becomes a component, and the components become the start of a design system. Doing that during design costs almost nothing; doing it afterwards is a separate project.

Engineering should be in the room throughout, not at the end. The cheapest quality improvement available to any product team is an engineer looking at designs while they are still free to change.

Protects you from: the last ten percent of the build turning into a negotiation, which is where timelines actually go.

Skip it when: you cannot. You can reduce fidelity, but you cannot skip deciding what the thing looks like.

Stage 5: Testing

Produces: evidence that the design works for people who did not design it.

Five or six sessions per round surfaces the major problems, and the problems will surprise you. They always do. Prototyping has become dramatically cheaper, which removed the last real excuse for skipping this.

Protects you from: shipping something that makes complete sense to the eleven people who built it.

Skip it when the change is small, reversible, and instrumented, so you can ship it and watch. Shipping to measure is a legitimate alternative to testing, as long as you actually look afterwards.

Stage 6: Handover and measurement

Produces: specs, tokens and components an engineer can build from, plus a return to the measure defined in stage one.

This is the stage almost every agency engagement quietly drops, because the contract ended at handover. It is also the only stage that tells you whether the previous five were worth the money.

Protects you from: learning nothing, and starting the next project from zero.

Skip it when: never, although the measurement half is frequently deferred by a quarter, which is fine as long as someone's name is on it.

Which stages you can actually skip

In practice, three common shapes.

A small feature in a working product. Framing, design, handover. Research only if the feature touches a workflow nobody understands. Typically three to five weeks.

A redesign of something live. All six, but research is compressed because you already have behaviour data, and structure is the heaviest stage because changing it is the whole point. Eight to twelve weeks.

A new product. All six, weighted hard toward framing, research and structure. The risk is building the wrong thing, so most of the budget goes into reducing that before production code exists.

Our longer piece on how this runs as an engagement, with the decision gates between phases, is in the product design process.

Where the process actually breaks

Research that cannot change the plan. If the roadmap is already fixed, do not commission research. You are paying for reassurance.

One concept, polished. Iterating a single direction feels productive and produces the best possible version of a mediocre idea. Two or three genuinely different approaches is where the value sits, and generative tools have made that nearly free.

Structure decided in a meeting rather than a stage. It still gets decided, just by whoever spoke last.

No measure. The retrospective becomes a debate about taste.

How AI changed the sequence

The middle of the process compressed hard. Prototypes that took a week take an afternoon, three directions cost what one used to, and copy for every state exists in draft before the flow is final.

The less obvious consequence matters more. When building gets cheap, the constraint moves upstream, so framing and research become a larger share of the work rather than a smaller one. Faster production of the wrong interface is just faster failure. We went into this in AI UX design.

FAQ

What are the stages of the UX design process?

Framing, research, structure, design and states, testing, then handover and measurement. The names vary between teams; the decisions they protect do not.

How long does the UX design process take?

A feature is three to five weeks, a significant redesign eight to twelve, a new product ten to sixteen. The variable is how much genuine uncertainty exists at the start, not how many screens there are.

What is the difference between the UX design process and design thinking?

Design thinking is a mindset and a teaching framework. The UX design process is what a team actually runs on a deadline, with the stages weighted by what is at risk.

Can we start in the middle?

Often, yes. With solid research, start at structure. With a validated direction, start at design. The one stage not worth skipping is framing, because it costs a day and prevents the most expensive category of mistake.

The takeaway

Treat the stages as a menu, not a ritual. Frame always. Research unless you genuinely already know. Structure unless it has an obvious home. Design and hand over always. Test unless you can ship and watch instead.

And keep asking the only question that matters at each stage: what decision is this changing? If the answer is none, cut it and spend the time on the one that does.

If you want a read on which stages your project actually needs, that is the first conversation we have about any product design engagement, and we will tell you when the answer is fewer than you expected.