Double Diamond vs Design Thinking: Choosing a Framework

Compare Double Diamond vs design thinking and Lean UX, then choose the framework, or the combination, that fits your project and team.

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

Teams often ask whether to run a project with the Double Diamond or with design thinking, and sometimes whether Lean UX would suit them better. The frameworks overlap heavily, so the choice is about emphasis and fit, and the answer is often a combination. This skill gives you a way to compare Double Diamond vs design thinking and Lean UX against your project and pick a backbone deliberately.

The Double Diamond describes the shape of a project: two rounds of widening and narrowing, first on the problem, then on the solution. The Design Council presents it inside a Framework for Innovation that adds design principles, a methods bank and the conditions of leadership and engagement (Framework for Innovation). It says little about which methods to use in each phase.

Design thinking, as taught by Stanford's d.school, is organised as modes: Empathize, Define, Ideate, Prototype and Test. The d.school's Design Thinking Bootleg presents these as a set of tools and methods you "can start wherever you'd like," rather than a fixed sequence (d.school Bootleg). The Nielsen Norman Group's version adds a sixth phase, Implement, and groups the phases into understand, explore and materialise (NN/g Design Thinking 101).

Lean UX, from Jeff Gothelf and Josh Seiden, applies lean and agile ideas to design. Its current edition is organised around the Lean UX Canvas, a one-page tool for identifying and testing a project's most important assumptions within an agile team (Lean UX). It assumes a team is already building and focuses on short cycles of hypothesis, experiment and learning.

The inputs to the choice are the project's clarity (how well the problem is understood), its time frame, how the organisation funds and approves work, and the team's experience. The output is a stated backbone framework, the methods you will borrow from the others, and a checkpoint at which you will review the choice.

How It Works

Compare the three frameworks on what each makes explicit, since that is what each will protect under pressure.

The Double Diamond makes the problem definition an explicit phase with its own output. That protects against solving the wrong problem. It fits projects where the problem is unclear or disputed, where a sponsor needs a visible decision point before committing build budget, and where several teams need a shared, simple picture of the process. Its weakness is that it says little about methods and can be read as a linear sequence, which the Design Council explicitly rejects.

Design thinking makes empathy and prototyping explicit. It gives teams a vocabulary of modes and a large toolkit of methods, and it encourages moving between modes freely. It fits teams that need practical methods for each activity and projects where hands-on prototyping will teach the most. Its weakness is that the flexible order can let teams skip or rush the problem-framing work that the Double Diamond protects.

Lean UX makes assumptions and experiments explicit. It fits teams already shipping software in short iterations, where the fastest way to learn is to release something small and measure it. Its weakness is that it presumes a reasonably well-framed problem and a product to iterate on, so it is less suited to open-ended discovery.

The frameworks combine well. A common arrangement uses the Double Diamond as the project-level backbone, design thinking methods inside each phase, and Lean UX cycles in Develop and Deliver once a product exists. The UK government's service phases (discovery, alpha, beta, live) are another backbone with the same arc, and add a decision on whether to continue at the end of discovery (GOV.UK discovery phase).

Two questions usually decide the backbone. First, how clear is the problem? The less clear it is, the more a separate problem diamond is worth. Second, how does your organisation commit money and people? If it wants a clear go or stop decision before build, the Double Diamond's first convergence point, or the GOV.UK end of discovery, gives it one. If it funds a standing product team, Lean UX's cycles fit its rhythm.

Step-by-Step Guide

Step 1: Rate how clear the problem is

Write down what the team knows about the problem and how it knows it. If the problem is disputed or based on assumptions, rate it unclear. If it is backed by recent research and agreed by stakeholders, rate it clear. Be honest: many "clear" problems are one senior person's view. This rating is the biggest single factor in the choice.

Step 2: Map how your organisation decides and funds

Find out how work is approved: a project budget with gates, a standing team with a roadmap, or a client contract with fixed deliverables. Note who must approve moving from research to build. Frameworks that match these decision points meet less resistance. Record any fixed deadlines that limit how long exploration can run.

Step 3: Compare the frameworks against your project

Put the three frameworks side by side against your ratings. Use the Design Council framework, the d.school Bootleg and the Lean UX book site as reference descriptions. For each framework, note what it would make the team do that it might otherwise skip, and where it would feel awkward. Keep the comparison to a single page.

Step 4: Check your team's experience

Consider what the team has done before. A team new to research may benefit from the Double Diamond's clear phases and outputs. A team that already runs experiments in production may find Lean UX natural. Mixed teams need a shared vocabulary more than a sophisticated framework. Plan any coaching the choice requires.

Step 5: Choose a backbone and name what you borrow

Pick one framework as the backbone that defines phases and decision points. List the methods you will borrow from the others, for example design thinking's empathy and prototyping methods inside the Double Diamond's phases, or Lean UX's hypothesis format in Deliver. Write the choice and the reasons in a short note. Avoid running two backbones in parallel, which confuses stakeholders.

Step 6: Explain the choice to stakeholders

Present the backbone as a picture with phases, outputs and decision points. Explain what it protects against in plain terms, such as "we will agree the problem before committing build budget." Answer the question "when will we see something" directly. Invite objections now rather than mid-project.

Step 7: Review the choice at a checkpoint

Set a point, such as the end of the first diamond or after a few sprints, to review whether the framework is helping. Ask what it made the team do well and where it got in the way. Adjust, or switch backbone if the project has changed shape. Record what you learn for the next project.

Best Practices

• Choose on problem clarity first. The less you know about the problem, the more a separate problem phase is worth.
• Match the organisation's decision rhythm. A framework whose checkpoints line up with approvals will be followed. One that fights them will be abandoned.
• Use one backbone and borrow methods freely. Frameworks differ most in structure; their methods are largely shared.
• Explain the choice in terms of risk. Stakeholders care less about framework names than about what could go wrong without them.
• Review the choice explicitly. A checkpoint makes it normal to adjust instead of silently drifting.

Common Mistakes

• Treating the choice as a doctrine: Arguing over which framework is correct wastes time. Pick the one that best protects against this project's biggest risk.
• Running Lean UX cycles on an unframed problem: Rapid experiments on the wrong problem produce fast, confident answers to the wrong question. Frame the problem first.
• Using design thinking's flexibility to skip Define: Jumping from empathy to ideation without an agreed problem statement leads to scattered ideas. Keep an explicit problem definition whichever framework you use.
• Presenting a framework as a straight line: All three frameworks expect iteration. Show loops in your plan so stakeholders are not surprised.
• Adopting a framework without adapting it to your organisation's gates: If the framework's decision points ignore how money is approved, the team will be forced off it. Align them before starting.

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

Sources

• Design Council: Framework for Innovation
• Stanford d.school: Design Thinking Bootleg
• NN/g: Design Thinking 101
• Lean UX by Jeff Gothelf and Josh Seiden
• GOV.UK Service Manual: How the discovery phase works

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