The design process framework that changed how agencies think
The Double Diamond is one of the most referenced frameworks in UX — and one of the most misunderstood. Here's what it actually means in a real product context, and how to adapt it for teams that can't afford long discovery cycles.
Where It Came From
The Double Diamond was introduced by the UK Design Council in 2005 as a way to visualise the design process. It was one of the first frameworks to make explicit that design involves two distinct activities: figuring out the right problem, and figuring out the right solution.
That distinction sounds obvious. In practice, most teams jump straight to solutions, build for six months, discover they were solving the wrong problem, and wonder why the product isn't working. The Double Diamond exists precisely because that pattern is so common.
The Four Phases
The framework maps to four phases across two diamonds:
Diamond 1 — Problem Space
Discover — explore widely. Talk to users, analyse behaviour data, map the competitive landscape. Don't converge yet. The goal is to understand the problem space without filtering it through existing assumptions.
Define — synthesise what you've learned. Identify the specific problem worth solving. This is where {{LINK:affinity-mapping}} earns its place — turning raw research into clear problem statements the whole team can act on.
Diamond 2 — Solution Space
Develop — explore widely again, but this time for solutions. Sketches, prototypes, concept testing. Generate options before committing to one.
Deliver — converge on the best solution, build, test, and ship.
The "double" is the key insight: you diverge and converge twice — once around the problem, once around the solution.
What It's Not
The Double Diamond is not a process prescription. It doesn't tell you how long each phase takes, which methods to use, or how many people to involve. It's a mental model, not a project plan.
It's also not linear. You'll often cycle back — a prototype test might reveal that your problem definition was wrong, sending you back to the first diamond. That's not failure. That's the framework working correctly. The teams that treat it as a one-way conveyor belt are the ones who ship things nobody needs.
It also isn't the same as Agile or Scrum. Those are delivery frameworks. The Double Diamond is a thinking framework. They can coexist — and should.
Adapting It for Fast-Moving Teams
The most common adaptation: compress the first diamond without skipping it. Startups and fast-moving product teams can't always afford full discovery cycles. A lean discover-define phase — two or three user interviews, a quick competitive review, a half-day synthesis session — is still infinitely better than no discovery at all.
The teams that skip the first diamond entirely consistently solve the wrong problems faster. Speed of execution without clarity of problem is expensive.
If you need to explain your design process to stakeholders or clients, the Double Diamond is probably the most legible option available. It maps cleanly onto how {{INTERNAL:/services/ux-research}} fits within a broader product design engagement.