UX Design Process: The 3 Real Frameworks, and Which to Use

Almost every description of the UX design process you will find online is the same five boxes with arrows between them: research, define, ideate, prototype, test. It is not wrong, but it is a summary of a summary, and it leaves out the thing a team actually needs, which is a defensible reason for working in that order and a way to tell your stakeholders what happens next.

Underneath those five boxes sit three real frameworks, each with a different purpose. One is an international standard you can cite in a contract. One is the visual model your clients have probably already seen. One is what the organisation that created that visual model now uses instead, because it concluded the original was too linear for messy problems. Knowing which of the three you are invoking, and when, is most of the skill.

Framework 1: ISO 9241-210, the one you can cite

ISO 9241-210:2019, “Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems”, is the formal standard. It is the document to reach for when someone asks why your process is the way it is, or when human-centred design is a contractual requirement, which it is in a lot of public sector and regulated work.

It specifies four human-centred design activities, run iteratively rather than once:

1. Understand and specify the context of use. Who the users are, what they are trying to achieve, and the environment they are doing it in.
2. Specify the user requirements. Turning that context into stated requirements, including usability and accessibility ones.
3. Produce design solutions that meet those requirements.
4. Evaluate the designs against the requirements, then loop back until they hold up.

Alongside those activities sit its principles: the design is based on an explicit understanding of users, tasks and environments; users are involved throughout; the design is driven and refined by user-centred evaluation; the process is iterative; the design addresses the whole user experience; and the team includes multidisciplinary skills and perspectives.

That last principle is the one people forget in practice. ISO 9241-210 is explicit that the team is part of the standard, not just the method.

What it is not is a method catalogue. It tells you what activities must happen, not which research technique to run on a Tuesday. That is deliberate, and it is why you still need one of the other two frameworks to actually organise work.

Framework 2: the Double Diamond, the one everyone recognises

The Design Council created the Double Diamond in 2003, publishing it the following year, when its director Richard Eisermann asked the team to codify how design actually gets done. It has since become the most reproduced diagram in the field.

Two diamonds, four phases, alternating divergent and convergent thinking:

The genuine insight in the model is the gap between the two diamonds. The first diamond is about the problem. The second is about the solution. Most failed projects skip the join: the team gathers research, then jumps straight to designing screens without ever reframing the brief. Define is the phase that gets cut when a deadline moves, and it is the phase that determines whether everything downstream is aimed at the right thing.

Its second useful property is political. The diagram gives you a shared vocabulary for telling a stakeholder that widening options now is intentional, not indecision. As Tim Brown of IDEO put it, it is “not an instruction manual on how to design, it’s an invitation to get involved.”

Framework 3: what the Design Council uses now

Here is the part missing from nearly every UX design process article: the Design Council moved on. It evolved the Double Diamond into the Framework for Innovation, and then in 2021 into the Systemic Design Framework.

The core idea, diverging then converging, survives. What changed is the acknowledgement that on complex problems these modes are not linear, and the phases were deliberately renamed to break the habit of reading the diagram left to right: explore, reframe, create, catalyse rather than discover, define, develop, deliver.

It also names the work that surrounds the design process and usually goes unmanaged: orientation and vision setting, connections and relationships, leadership and storytelling, and continuing the journey. Anyone who has watched a well-researched design die because nobody sustained the relationships or told the story internally will recognise why those got promoted into the model.

The practical read: use the Double Diamond when the problem is bounded and you need a clear phase structure people already understand. Reach for the systemic framing when the problem crosses teams or organisations and a linear diagram would be a lie.

What the process looks like on an actual project

The frameworks describe shape. Here is the sequence in practice, with the parts that get skipped flagged.

1. Frame the problem before researching it. Write down the business outcome, the assumption you are least sure about, and what would change your mind. Without this, discovery becomes an unbounded reading exercise. Our guide to writing a design brief covers the artefact this produces.

2. Discovery, mixed methods. Qualitative for why, quantitative for how many. Interviews and contextual observation on one side; analytics, funnel data and search behaviour on the other. Neither alone gives you a decision. What user research actually involves goes deeper on choosing methods.

3. Synthesis, and this is where it goes wrong. Turning notes into insight is the least visible and most skilled part of the whole process. Budget real time for it. The output is a reframed problem statement, not a folder of quotes. If you produce personas here, make them decision-shaping, not decorative.

4. Diverge on solutions, properly. More than one concept, from more than one person, before anyone opens a design tool. The failure mode is a team converging on the first plausible idea in the first hour.

5. Prototype at the lowest fidelity that answers the question. Paper answers “is this the right flow”. A clickable prototype answers “can people complete this”. Production code answers “does this convert”. Match the fidelity to the question, and stop building when it is answered.

6. Evaluate, and be specific about what you are evaluating. Usability testing tells you whether people can. An A/B test tells you whether a change moves a number, on a scale you may not have. They answer different questions and neither substitutes for the other. An expert UX audit catches a different class of problem again.

7. Loop. Both the standard and both Design Council frameworks are explicit that this is iterative. In practice, iteration means budgeting for a second and third pass at the start, because nobody ever gets extra time for it later.

Choosing between them

• Need to justify the process formally, or meet a contractual requirement? ISO 9241-210. It is the citable one.
• Need to explain the process to stakeholders and structure a bounded project? Double Diamond. Universal recognition is its main asset.
• Working on something that spans teams, services or organisations? Systemic Design Framework, because the linear model will mislead everyone about how the work will actually go.

None of the three tells you which research method to run. That is the layer below, and it is chosen per question, not per framework.

Frequently asked questions

What are the stages of the UX design process? Most teams work in some version of discover, define, develop, deliver, alternating between widening options and narrowing them. Formally, ISO 9241-210 specifies four iterative activities: understand and specify the context of use, specify user requirements, produce design solutions, and evaluate those designs against the requirements.

Is the Double Diamond still the current model? It is still the most widely used and recognised diagram, but the Design Council itself evolved it, first into the Framework for Innovation and then in 2021 into the Systemic Design Framework, which renames the phases explore, reframe, create and catalyse to signal that the work is not linear on complex problems.

What is the difference between the UX design process and design thinking? Design thinking is a broader problem-solving mindset applied well beyond digital products. The UX design process is the application of human-centred design to interactive systems specifically, and unlike design thinking it has a formal standard behind it in ISO 9241-210.

How long should the discovery phase take? Long enough to change your mind about something. If discovery ends with the brief you started with intact, it either was not needed or was not done properly. The more useful control is the define phase, which is the one that gets cut under deadline pressure and the one that determines whether the rest of the work is aimed correctly.

Do small teams need a formal UX design process? The activities matter more than the ceremony. A two-person team still needs to understand context, state requirements, produce options and evaluate them, but it can do all four in a week without documentation overhead. What does not scale down is skipping evaluation.

Which framework should I put in a client proposal? The Double Diamond, because clients recognise it and it makes the phase structure legible. Cite ISO 9241-210 alongside it if the work is regulated, in the public sector, or if accessibility compliance is part of the contract.