What is the Double Diamond? The two-diamond model

In short

The Double Diamond describes the steps of a design project with two diamond shapes. According to the Design Council, the model is a simple way to describe the steps taken in any design and innovation project, irrespective of the methods and tools used.

The diagram shows what you think about in which phase and when you decide. I draw it in the first meeting with the team. That way, everyone sees which diamond we’re in.

In the UX design guide, which describes the UX process step by step, I mentioned the Double Diamond briefly. This page describes the model itself.

Four phases: Discover, Define, Develop, Deliver

The first diamond is about the problem, the second about the solution. Where the two diamonds meet, there is a clear problem definition. In the Design Council’s first description, the output of this point is a design brief.

Diamond diagram

1. Discover First diamond · Divergence

Goal

Understanding, rather than simply assuming, what the problem is. You speak to and spend time with people who are affected by the issue. In the Design Council’s first description, this phase means questioning the brief and researching user needs.

Methods

User interviews, observation where the product is used, analytics data and support requests. If needed, a first reaction to a very rough prototype.

Output

Interview notes, observations and raw data. There’s no decision yet in this phase, but plenty of material.

2. Define First diamond · Convergence

Goal

Using what you learned in discovery to define the challenge in a different way. The material gathered is interpreted and narrowed down to a single problem.

Methods

Grouping notes by similarity, creating a persona and a customer journey map.

Output

Design brief: the problem to solve, who it’s solved for and how success will be recognised.

3. Develop Second diamond · Divergence

Goal

Finding different answers to the clearly defined problem. You seek inspiration from elsewhere and co-design solutions with a range of different people.

Methods

Sketches, flow drafts, wireframes, co-design sessions with users or within the team, clickable prototypes.

Output

A few solution directions and their rough prototypes.

4. Deliver Second diamond · Convergence

Goal

Testing solutions at small scale. What won’t work is rejected; what will is improved. At the end, one solution is chosen and prepared for launch.

Methods

Usability test, test with a limited group of users, A/B test.

Output

A tested solution that’s ready to launch. Often a list of new questions too.

Press a phase: in the diagram, that half-diamond turns orange, and the goal, methods and output appear below. The goals are based on the Design Council’s text, shortened by me. The methods and outputs come from my own practice.

1. Discover

According to the Design Council, the first diamond helps people understand, rather than simply assume, what the problem is. To do that, you speak to and spend time with people who are affected by the issue.

Think of a city water utility’s app for reporting water outages. The team starts with “The form is too long”. If it talks to residents during discovery, the real problem may turn out to be a different one: after reporting, nobody gets back to them.

2. Define

With the insights from discovery, you define the challenge in a different way. The team in the example no longer says “Let’s shorten the form”. It writes: “Residents can’t see the status of their report.”

This sentence is the entrance to the second diamond. The more clearly it’s written, the better the ideas that follow. Working on a persona helps me sharpen the definition.

3. Develop

In the second diamond, you look for different answers to the clearly defined problem. Here the Design Council recommends seeking inspiration from elsewhere and co-designing with a range of different people.

In the example, that means a few ideas for status tracking, such as a text notification, a timeline in the app or a lookup by report number. Each is drawn as a rough prototype.

4. Deliver

In the last phase, different solutions are tested at small scale. What won’t work is rejected; what will is improved. Here I run a usability test and show real users two variants at most.

Divergence and convergence

The two halves of a diamond are two different ways of thinking. The Design Council describes it on the Framework for Innovation page like this: first an issue is explored more widely or deeply, which is divergent thinking. Then comes focused action, which is convergent thinking.

Divergence is about increasing the number of options. Criticism is postponed. In convergence, you compare the options and narrow them down.

Trying both in the same meeting is the problem I see most often. One person suggests an idea; the next immediately says, “That won’t work.” I split the session into two halves: in the first, ideas are only collected; in the second, they’re chosen.

The process isn’t linear

The diagram reads from left to right, but the process doesn’t run in only one direction. On the Framework for Innovation page, the Design Council writes clearly that it is not a linear process, as the arrows on the diagram show.

The organisation’s own observation points the same way: many of the organisations it supports learn something more about the underlying problem. That can send them back to the beginning. Building and testing very early ideas can also be part of discovery.

The Design Council adds one more observation: in an ever-changing, digital world, no idea is ever “finished”.

So if you find a new problem in the deliver phase, it isn’t a failure. The model expects it from the start.

The Framework for Innovation: principles and methods

The Framework for Innovation is a broader framework with the Double Diamond at its centre. Besides the process model, it contains design principles, a methods bank and guidance on working culture.

Four design principles

Principle	What it means
Put people first	Start with an understanding of the people using a service: their needs, strengths and aspirations.
Communicate visually and inclusively	Help people gain a shared understanding of the problem and ideas.
Collaborate and co-create	Work together and get inspired by what others are doing.
Iterate, iterate, iterate	Try again and again. That way you spot errors early, avoid risk and build confidence in your ideas.

The first principle is the core of the idea of user-centred design. The fourth explains why I run small, frequent tests instead of one big test.

Methods bank

The Design Council groups the design methods it has authored, adapted or adopted into three areas. Explore is for researching challenges, needs and opportunities. Shape forms prototypes, insights and visions. Build develops ideas, plans and expertise.

Engagement and leadership

The framework also names two conditions of culture. The first is engagement: working with the people who deliver and receive the ideas, and with partners who might have other ideas. The Design Council considers building relationships as important as creating ideas.

The second is leadership. According to the Design Council, leadership encourages innovation, builds skills and capability, and provides permission for experimentation and learning. In my experience, the first diamond is most likely to be cut short when that permission is missing.

Where the model comes from

The story the Design Council tells starts in 2003. That year, the organisation was promoting the benefits of a strategic approach to design but had no standard way to describe the process. Richard Eisermann, then Director of Design and Innovation, asked his team how to describe the design process.

The team examined its own projects and methods from the outside and derived a common process. The four phases were named Discover, Define, Develop and Deliver. In 2004, the Design Council started to share the model at conferences and in presentations.

The idea didn’t come out of nowhere. According to the organisation’s history, research from the 1960s to the 1990s had produced process models with elements of divergence, convergence and iteration.

Eisermann recounts that the diamond shape was already present at IDEO in the late 1990s, although it may not have been called that.

According to the Design Council, this representation of the diagram remains unchanged today. The model is licensed under CC BY 4.0. The license allows sharing and adapting if you give credit, link to the license and indicate if changes were made.

How I use it in a UX project

I use the Double Diamond as a decision tool. At the end of each diamond, I ask one question: have we understood the problem enough, have we tried the solution enough?

• At the start of a project, I draw the diamonds on the whiteboard and write an output for each phase. These outputs show the team what’s finished.
• At the point where the diamonds meet, I put the problem definition in one sentence. Until this sentence is confirmed, I don’t start drawing screens.
• In a short project, the first diamond can be as short as a few interviews and a look at the analytics. I don’t skip the phase; I just make it smaller.
• If there is already a live product, the first diamond can start with an audit. Seeing where the product snags is a fast way to discover.

In the develop phase, choosing the right one among wireframe, mockup and prototype saves time. A rough draft lets you try more options during divergence.

Common mistakes

Skipping the first diamond. The team assumes it knows the problem and draws a solution straight away. The wording the Design Council uses for the first diamond says exactly the opposite: understand rather than assume.

Mixing divergence and convergence. Criticism in an idea-generation session kills options before they exist.

Treating the diagram as a fixed sequence. Learning something new in the deliver phase and going back to define is part of the model. Plan for it from the start.

Not writing down the problem definition. If there is no written definition where the two diamonds meet, everyone in the second diamond solves a different problem.

Staying inside the team. The framework’s principles ask you to put people first and co-create. A discovery phase without a single conversation with users is a meeting called discovery.

My note

What I like most about the Double Diamond: it lets the team say, “We’re not deciding yet.” If you get something wrong in the first diamond, it costs a few pages of notes. If you notice the same mistake only after launch, it costs rewritten screens.

I often see one situation. The team is in the middle of the second diamond, has a design and asks why it doesn’t work. The answer usually lies in the first diamond: the problem was never written down.

That’s why, in the Design & Ship Sprint, I divide the two weeks into diamonds. I give the first days to clarifying the problem. The rest of the time goes into trying out the solution and the code.