Double Diamond Thinking: Divergent and Convergent Modes

Use Double Diamond thinking to tell a team when to diverge and when to converge, and manage the switch between the two modes in every phase.

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

Double Diamond thinking is the habit of knowing, at any moment in a project, whether the team should be opening up options or closing them down. The shape of the Double Diamond encodes it: each diamond widens (divergent thinking) and then narrows (convergent thinking). The Design Council describes the two diamonds as "a process of exploring an issue more widely or deeply (divergent thinking) and then taking focused action (convergent thinking)" (Framework for Innovation).

The two terms predate the diagram by decades. The psychologist J. P. Guilford introduced divergent and convergent thinking in 1956. Divergent thinking generates many possible solutions in a free-flowing way, while convergent thinking organises and structures information to arrive at one answer (Wikipedia on divergent thinking). Neither is better. Each is useful at a different moment, and each does damage at the wrong one.

Most teams have a default. Delivery-focused teams converge by instinct: they want a decision, a ticket and a date. Research-heavy or creative teams can diverge indefinitely, always finding one more angle. The Double Diamond asks for both, in a set order, twice.

This skill is about managing that switch. It covers how to name the current mode for a team, how to design sessions that stay in one mode, how to handle the uncomfortable transition between them, and how to diagnose a project that is stuck in the wrong one. The Design Council's own history of the model lists this as one of its uses: helping people check where they are in the process and get comfortable with going broad in Discover and Develop (History of the Double Diamond).

How It Works

Each of the four phases has a dominant mode. Discover and Develop are divergent: gather evidence, generate options, suspend judgement. Define and Deliver are convergent: cluster, compare, choose and commit. Within each phase, individual sessions still mix modes on a small scale. An ideation workshop ends with a light clustering step. A synthesis session begins with everyone reading all the notes. Each activity should still run in one mode at a time, and everyone should know which.

The modes need different rules. Divergent activities need deferred judgement, volume, variety of voices and permission for odd ideas. IDEO.org's brainstorm rules (defer judgement, encourage wild ideas, build on others, go for quantity) are rules for divergence (Design Kit brainstorm rules). Convergent activities need agreed criteria, evidence, structured comparison and a named decision-maker. Mixing the two rule sets produces the most common failure: people critique ideas as they are offered, and generation stops.

The transition between modes is where teams struggle most. The facilitator Sam Kaner's diamond of participation describes a "groan zone" between divergent and convergent thinking, where a group has to organise a mass of ideas, focus on what matters and make decisions, and where discomfort is normal (i2Insights on the groan zone). Naming the groan zone helps: people tolerate confusion better when they know it is expected and temporary.

The diverge-then-converge shape was not new with the Design Council. Wikipedia's entry on the model traces it to a 1996 divergence-convergence model by Béla H. Bánáthy (Wikipedia on the Double Diamond). The Double Diamond's contribution was to apply the pattern twice, once to the problem and once to the solution, and to give each half a memorable name.

Diagnosis follows from the mapping. A project in Discover that is already debating features has converged too early. A project in Deliver still generating new concepts has failed to converge. Both are visible in meetings if you listen for the verbs: "what if," "what else" and "who else" signal divergence, while "which," "should we" and "when" signal convergence.

Step-by-Step Guide

Step 1: Map each phase and session to a mode

List the project's phases and the main sessions planned in each. Mark each session as divergent or convergent, and note where a session contains both. Make sure the sequence runs widen then narrow in each diamond. Share the map with the team so the plan and the expected mode are visible.

Step 2: Announce the mode at the start of every session

Open each session by saying which mode it is in and what that means for behaviour. For divergent sessions, state the rules for deferring judgement. For convergent sessions, restate the criteria and who decides. This takes a minute and prevents most mode clashes. Write the mode on the board or at the top of the agenda.

Step 3: Design activities that fit the mode

For divergence, choose activities that produce volume and include quiet voices: silent individual writing, sketching, field visits, analogies. For convergence, choose activities that impose structure: clustering, criteria grids, critique against goals, silent voting. The NN/g guide to dot voting is a useful reference for running a convergent vote without persuasion taking over. Avoid open discussion as the only activity in either mode, since it favours confident speakers.

Step 4: Plan the transition as its own step

Between a divergent and a convergent activity, add an explicit bridge: read everything back, remove duplicates, group loosely. Tell the group that confusion here is normal, drawing on Kaner's description of the groan zone. Allow a break or an overnight gap before the decision when stakes are high. Do not rush through this step to reach a decision on time.

Step 5: Watch for mode drift and correct it

During sessions, listen for critique in divergent time and new options in convergent time. When you hear it, name it neutrally ("that sounds like evaluation; let's park it until the next step") and capture the point so it is not lost. Keep a visible parking area for comments that belong to the other mode. Repeated drift usually means the mode was not announced clearly or the rules were not agreed.

Step 6: Check convergence quality before moving on

At the end of each convergent phase, check that the choice rests on the evidence from the divergent phase before it. Ask whether any strong option was dropped without a stated reason. Confirm that the output (a problem statement or a chosen solution) is written down and agreed. If any of those checks fail, the team has not really converged yet.

Step 7: Review the balance at project checkpoints

At each phase boundary, look back at the time spent in each mode. A project that spent a day in Discover and a month in Deliver may have converged on the wrong problem. A project that is still generating concepts late in Deliver has a decision problem. Adjust the plan for the next phase accordingly.

Best Practices

• Give every session a single declared mode. Mixed sessions are fine when the switch is announced, and harmful when it happens by accident.
• Match the rules to the mode. Deferred judgement and volume for divergence; criteria, evidence and a named decider for convergence.
• Expect discomfort at the switch. The groan zone is a normal part of convergence, and naming it keeps people from abandoning the process.
• Use silent individual work at both ends. Silent writing widens divergence; silent voting reduces bias in convergence.
• Listen for the verbs. "What if" and "which one" tell you which mode people are actually in, whatever the agenda says.
• Make the outputs of convergence explicit. A written problem statement or decision record is how you know convergence happened.

Common Mistakes

• Critiquing during divergence: Evaluating ideas as they appear stops generation. Park critique and schedule it as a separate convergent step.
• Diverging forever: Some teams keep adding options because deciding feels risky. Set a clear end condition for each divergent activity and hold to it.
• Converging without criteria: A choice made without agreed criteria defaults to the loudest or most senior view. Agree criteria before comparing options.
• Skipping the transition: Jumping from a wall of ideas straight to a vote produces shallow decisions. Read back, cluster and pause first.
• Treating the modes as personality types: People are not "divergent thinkers" or "convergent thinkers." Everyone can do both when the activity and rules support it.

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
• How to Create a Double Diamond Diagram
• Double Diamond vs Design Thinking: Choosing a Framework
• Adapting the Double Diamond UX Framework for Design Projects

Sources

• Design Council: Framework for Innovation
• Design Council: History of the Double Diamond
• Wikipedia: Divergent thinking
• Wikipedia: Double Diamond (design process model)
• IDEO.org Design Kit: Brainstorm Rules
• i2Insights: Collaboration, from groan zone to growth zone
• NN/g: Dot Voting

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