How to Create a Double Diamond Diagram

Create a Double Diamond diagram for your own project that shows its phases, activities, outputs and current position to stakeholders.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

A Double Diamond diagram is the model's own picture, adapted to one project. The generic version, two diamonds labelled Discover, Define, Develop and Deliver, explains the idea behind the Double Diamond. A project diagram goes further: it shows what this team will actually do in each phase, what each phase must produce, where decisions happen, and where the project is right now.

The diagram has been used this way since the start. The Design Council's history of the model lists uses such as kicking off a project, checking in on "where we are in the process," and helping people get comfortable with going broad and unfocused in the divergent phases (History of the Double Diamond). A project diagram serves all three.

The inputs are the project's plan (activities, rough timing, owners), the problem as currently stated, and the key decision points. The outputs are a diagram that fits on one page or one board, a version history as the project moves, and a shared reference the team and stakeholders can point to in conversation.

Drawing the diagram well matters because the diagram shapes expectations. Two symmetrical diamonds drawn with a straight arrow imply a tidy sequence of equal phases. Real projects are lopsided and loop back, and the Design Council says of its own framework diagram that "this is not a linear process as the arrows on the diagram show" (Framework for Innovation). A project diagram that shows its real proportions and loops sets honest expectations with stakeholders.

This skill covers choosing the audience and level of detail, drawing and labelling the structure, adding activities and outputs, marking decision points and loops, showing current position, and keeping the diagram current.

How It Works

A useful project diagram has four layers, added in order.

The structure layer is the two diamonds and four phase labels. Keep the standard names so the diagram is recognisable to anyone who has seen the model. The Design Council publishes its Framework for Innovation under a CC BY 4.0 licence, which allows adaptation with attribution (Framework for Innovation), and Wikipedia notes that it released an openly licensed visual and a Mural template for the model's anniversary (Wikipedia on the Double Diamond). Credit the Design Council when you base a diagram on theirs.

The content layer places this project's activities inside each phase: the research methods in Discover, the synthesis workshops in Define, the ideation sessions in Develop, the test rounds and pilot in Deliver. Place activities on the widening half or the narrowing half according to their mode. Add the output of each phase at its right-hand point, such as "agreed problem statement" at the end of Define.

The decision layer marks the points where the project commits: the end of Define, the concept selection in Deliver, and any funding or go-or-stop gates. Show who decides. Add return arrows where the team expects to loop back, for example from Deliver testing to Define.

The status layer shows where the project is today and what has been completed. A simple marker and a date are enough. This layer changes most often, so keep it easy to update.

Proportions carry meaning. If the team plans a long Discover and a short Develop, draw the first diamond wider. Dan Nessler's widely shared revamp of the model notes that diamond sizes vary with a project's scope and needs (Nessler's revamped Double Diamond). A diagram with honest proportions starts useful conversations about where time is going.

Different audiences need different levels of detail. Executives need the structure, outputs, decisions and status. The working team needs activities and owners too. Draw one detailed version and derive a simpler one from it, instead of maintaining two unrelated drawings.

Step-by-Step Guide

Step 1: Decide who the diagram is for

Name the main audience: the working team, sponsors, a steering group or a mixed workshop. Decide what they need to take away, such as where decisions will happen or what research will be done. That decides the level of detail. If you need more than one audience, plan a detailed version and a summary derived from it.

Step 2: Draw the structure with standard labels

Draw two diamonds side by side with the challenge on the left and the outcome on the right. Label the four phases Discover, Define, Develop and Deliver. Size each diamond to match the planned effort instead of drawing them equal. If you adapt the Design Council's own artwork, credit it under the terms of its CC BY 4.0 licence.

Step 3: Add activities in the right half of each diamond

Place each planned activity in the phase and half it belongs to: widening halves for research and ideation, narrowing halves for synthesis and testing. Use short labels such as "interviews with drivers" or "concept test round two." Add owners if the audience is the working team. Keep the number of labels low enough to read at a glance, grouping minor tasks.

Step 4: Mark outputs and decision points

At each diamond's right-hand point, write the output that phase must produce: the agreed problem statement for Define and the chosen, tested solution for Deliver. Mark each decision with who makes it. Add any external gates, such as funding approvals. These markers are what stakeholders look for first.

Step 5: Show the loops

Draw return arrows from later phases to earlier ones where you expect to revisit them, such as from Deliver testing back to Define. The Design Council's own framework diagram shows these loops (Framework for Innovation). Label each loop with the trigger, such as "tests show problem framing is wrong." This prepares stakeholders for loops as a planned part of the process.

Step 6: Mark current position and keep it current

Place a clear marker showing where the project is now and the date of the update. Tick off completed activities. Update the diagram at a regular point, such as the weekly team meeting. Keep old versions, since the history of the diagram shows how the project really moved.

Step 7: Use it in conversation

Open reviews and stakeholder updates with the diagram. Point to where the project is and what the next decision is. When someone asks for a solution during Discover, point to the diagram to show where solutions will be developed. The diagram earns its keep when people start using it to ask better questions.

Best Practices

• Keep the standard phase names. Recognisable labels let newcomers read the diagram without explanation.
• Draw honest proportions. Size diamonds to the planned effort. Equal diamonds on an unequal plan mislead.
• Put outputs at the points. The narrow tips are where each diamond produces something, so label them with the actual deliverable.
• Show loops as planned, not as failure. Return arrows tell stakeholders that revisiting a phase is expected.
• Update on a rhythm. A diagram that is weeks out of date is worse than none, because people trust it.
• Credit the source. Attribute the Design Council when you adapt its artwork.

Common Mistakes

• Drawing the generic model and stopping: Two labelled diamonds explain the idea but tell nobody what this project will do. Add activities, outputs and decisions.
• Making it too detailed to read: A diagram with every task becomes a plan in disguise. Group minor tasks and keep the full plan elsewhere.
• Implying a straight line: A single forward arrow suggests no revisiting. Add loop arrows where the team expects them.
• Never updating the status: A stale "you are here" marker misleads stakeholders. Update it at a fixed point each week.
• Hiding decisions: If decision points and owners are missing, stakeholders cannot tell when to weigh in. Mark them clearly.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Double Diamond

Related Skills

• Conducting Discovery Research in the Double Diamond
• Synthesizing Insights to Define the Problem
• Facilitating Divergent Ideation in the Double Diamond
• Converging on Final Solutions in the Deliver Phase
• Double Diamond Thinking: Divergent and Convergent Modes
• Double Diamond vs Design Thinking: Choosing a Framework
• Adapting the Double Diamond UX Framework for Design Projects

Sources

• Design Council: History of the Double Diamond
• Design Council: Framework for Innovation
• Wikipedia: Double Diamond (design process model)
• Dan Nessler: How to apply a design thinking, HCD, UX or any creative process from scratch

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.