Double Diamond vs Design Thinking: How to Choose the Right Framework
Learn how to compare the Double Diamond with Stanford d.school Design Thinking and Lean UX so you can select—or combine—the right design framework for your project's goals, team maturity, and constraints.
The Double Diamond splits the design process into two explicit diamonds—Discover, Define, Develop, Deliver—emphasizing when to diverge and converge. Stanford d.school Design Thinking uses five stages: Empathize, Define, Ideate, Prototype, Test. Choose the Double Diamond when you need structured problem-framing before solution-finding. Choose Design Thinking when rapid prototyping and user testing are your primary drivers. Many teams blend both.
Outcome: You will be able to confidently evaluate, select, and justify the right design framework—or a hybrid—for any given project context.
Prerequisites
- Basic familiarity with the Double Diamond model and its four phases
- Understanding of Stanford d.school's five-stage Design Thinking process
- Experience participating in at least one structured design project
Overview
Every product team eventually faces the question: should we follow the Double Diamond, Design Thinking, Lean UX, or something else entirely? The frameworks share DNA—they all value empathy, iteration, and user-centredness—but they differ in structure, emphasis, and the contexts where they shine. Picking the wrong model (or forcing a favourite onto an ill-suited project) leads to wasted cycles, confused stakeholders, and process theatre.
This skill teaches you to move beyond surface-level comparisons of double diamond vs design thinking. You will learn the structural differences, the philosophical trade-offs, and the practical decision criteria that help you match a framework to your project's actual constraints. Whether your challenge is deep problem-framing for a government service or rapid MVP validation for a startup, you'll walk away with a repeatable decision process.
This skill sits within the broader Double Diamond method. Understanding the parent model's divergent-convergent rhythm is essential context, and you may also want to explore Mapping Divergent and Convergent Thinking Modes to deepen your grasp of the underlying mechanics.
How It Works
At its core, choosing between frameworks is a matching problem. You are matching a process model's strengths to a project's needs. The Double Diamond excels at problem-framing: its first diamond (Discover → Define) forces teams to spend serious time understanding the problem space before jumping to solutions. Design Thinking—particularly the Stanford d.school variant—places heavier emphasis on rapid prototyping and user testing loops, making it powerful when you need to learn quickly through making. Lean UX strips away deliverables in favour of outcome-driven experiments and is optimised for cross-functional agile teams.
The key insight is that these frameworks are not mutually exclusive. They operate at different altitudes. The Double Diamond is a macro-level process architecture that tells you when to open up and close down thinking. Design Thinking provides a set of mindsets and micro-methods (empathy maps, crazy eights, prototype sprints) that can plug into any phase. Lean UX contributes a hypothesis-driven experimentation layer that fits naturally inside the second diamond's Develop and Deliver phases.
The decision, then, is less about picking one winner and more about choosing a primary backbone and layering in complementary techniques. Your choice depends on four factors: (1) problem clarity—how well-understood is the challenge? (2) organisational context—does your team need explicit phase gates or fluid iteration? (3) stakeholder expectations—do sponsors expect a structured, visual process map or lean, continuous delivery? (4) team skill set—does the team have deep research capability or is it stronger in prototyping and engineering?
Step-by-Step
Step 1: Audit your project's problem clarity
Before comparing frameworks, assess how well the problem is understood. Ask: Do we have a clearly defined user need, or are we still exploring a vague opportunity area? Can we articulate the problem in one sentence that the whole team agrees on?
If the answer is 'no'—the problem space is ambiguous, multi-stakeholder, or politically contested—the Double Diamond's first diamond (Discover → Define) is especially valuable because it mandates dedicated problem-framing time. If the problem is already well-scoped and you need to explore solutions quickly, you may jump more directly into Design Thinking's Ideate → Prototype → Test loop.
Tip: Use a simple 1-5 scale for problem clarity. Score 1-2 = lean toward Double Diamond's full first diamond. Score 4-5 = consider starting with Design Thinking's Ideate phase.
Step 2: Map your organisational constraints
Frameworks don't exist in a vacuum—they have to survive contact with your organisation. Document three things: your team's composition (dedicated design team vs. cross-functional squad), your delivery cadence (waterfall milestones, two-week sprints, continuous deployment), and your stakeholder governance model (stage-gate approvals, lean portfolio management, or ad hoc).
The Double Diamond maps cleanly to organisations that use stage-gate governance because each diamond has a natural decision point. Design Thinking's iterative loops fit agile sprint cadences. Lean UX was purpose-built for cross-functional squads practising Scrum or Kanban.
Tip: If your organisation mandates formal phase-gate reviews, the Double Diamond's visual structure makes it far easier to communicate progress to senior leadership than Design Thinking's more fluid model.
Step 3: Compare framework structures side by side
Create a comparison table with columns for each candidate framework and rows for: number of phases, primary emphasis, key activities, artefacts produced, ideal team size, and typical duration. For double diamond vs design thinking, the critical structural difference is that the Double Diamond explicitly separates the problem space (Diamond 1) from the solution space (Diamond 2), whereas Design Thinking interleaves them—Empathize and Define set up the problem, but Prototype and Test often circle back to redefine it.
Also consider Lean UX as a third option. Lean UX replaces heavy deliverables with lightweight hypotheses and experiments, making it ideal when speed-to-learning matters more than comprehensive documentation.
This side-by-side analysis prevents you from choosing based on familiarity bias and ensures the decision is grounded in structural fit.
Tip: Keep the comparison visual—a one-page table or Miro board that the whole team can reference. This artefact also helps you explain your choice to stakeholders.
Step 4: Evaluate team capabilities and mindset
A framework is only as good as the team's ability to execute it. If your team is strong in user research and synthesis, the Double Diamond's Discover and Define phases will feel natural. If your team is stronger in rapid prototyping and engineering, Design Thinking's bias toward making will yield faster results.
Conduct a quick skills audit: list the core activities each framework requires (e.g., contextual inquiry, affinity mapping, concept sketching, usability testing) and rate your team's current proficiency. Gaps don't disqualify a framework, but they do flag where you'll need coaching or external support.
Tip: Don't confuse team preference with team capability. Designers often prefer the framework they learned first. Push for an honest assessment of actual skills rather than comfort zones.
Step 5: Decide on a primary backbone and supplementary techniques
Based on Steps 1-4, select one framework as your project's primary process backbone. This is the model you'll use to structure phases, set milestones, and communicate with stakeholders. Then identify specific techniques from other frameworks to layer in.
For example, you might choose the Double Diamond as your backbone because the problem is complex and stakeholders need clear phase gates, but borrow Design Thinking's rapid prototyping sprints for the Develop phase and Lean UX's hypothesis-driven experiments for Deliver. Document this hybrid explicitly so the team knows which model governs overall flow and which provides tactical methods.
Tip: Write a one-paragraph 'process rationale' that explains why you chose this combination. Revisit it at the project midpoint to see if the choice still holds.
Step 6: Align stakeholders on the chosen approach
Present your framework choice—and the reasoning behind it—to project sponsors and key stakeholders. Use your comparison table from Step 3 and your process rationale from Step 5. Focus on three things they care about: what decisions they'll be asked to make and when, what artefacts they'll see at each phase gate, and how the framework reduces risk of building the wrong thing.
This alignment step is critical because framework mismatches between the design team and leadership create friction throughout the project. If leadership expects a linear, phased process and you're running fluid Design Thinking sprints, you'll spend more time translating than designing.
Tip: Tailor your language to the audience. Executives respond to risk reduction and decision points, not to process philosophy.
Step 7: Build in retrospective checkpoints to reassess the framework fit
No framework choice is permanent. Schedule explicit retrospective checkpoints—at minimum, one after each major phase transition—to ask: Is the framework helping or hindering us? Are we skipping phases because they feel forced? Are stakeholders confused by the process?
If the framework isn't working, pivot. You might discover that what started as a well-defined problem (favouring Design Thinking) is actually far more ambiguous than expected, warranting a shift to the Double Diamond's first diamond. Build this adaptability into your project plan from the start.
Examples
Example: Government digital service redesigning a citizen portal
A government agency needs to redesign its citizen-facing benefits portal. The problem space is broad—citizens struggle with the portal, but the agency isn't sure whether the issues are informational, navigational, technical, or policy-driven. Multiple departments have different views on the root cause. The project has formal stage-gate governance with ministerial sign-off at key milestones.
The team runs the problem-clarity audit and scores a 1 out of 5—the problem is highly ambiguous. Organisational constraints include stage-gate governance and a large, multi-disciplinary team. The decision: use the Double Diamond as the primary backbone because its first diamond provides the structured Discover and Define phases needed to align multiple stakeholders on the real problem before investing in solutions. Within the Develop phase (second diamond), the team borrows Design Thinking's rapid prototyping sprints to generate and test solution concepts with citizens. The process rationale is documented and shared with the ministerial sponsor, who appreciates the clear decision points at the end of each diamond.
Example: Startup building an MVP for a validated market need
A fintech startup has already completed extensive customer discovery and validated a specific pain point: freelancers struggle to track invoices and tax obligations. The founding team is a small, cross-functional squad (designer, two engineers, product lead) working in weekly sprints. They need to ship an MVP within 8 weeks.
Problem clarity scores a 4 out of 5—the pain point is well-validated and specific. The team is small and agile-native. The decision: use Design Thinking's Ideate → Prototype → Test loop as the primary backbone because the emphasis is on rapid solution exploration and learning through making. They layer in Lean UX's hypothesis-driven experiment format to structure each sprint around testable assumptions (e.g., 'We believe freelancers will categorise expenses if we auto-suggest categories'). The Double Diamond's first diamond is unnecessary here because the problem has already been framed through prior customer discovery research.
Example: Enterprise product team modernising an internal tool
A large enterprise wants to modernise an internal supply chain management tool. Users have submitted hundreds of feature requests, but the product team suspects many requests mask deeper workflow problems. The team operates within SAFe (Scaled Agile Framework) with quarterly PI planning cycles.
Problem clarity is a 2—there are many surface-level requests but the underlying needs are unclear. The SAFe context requires alignment with quarterly planning cadences. The team chooses the Double Diamond as the macro backbone: Diamond 1 (one PI cycle) is dedicated to Discover and Define, using contextual inquiry and journey mapping to look beyond feature requests and identify root workflow problems. Diamond 2 (the following PI cycle) covers Develop and Deliver, using Lean UX experiment cards to validate solutions incrementally within each sprint. The comparison of double diamond vs design thinking is documented in the team's process brief, noting that Design Thinking's prototyping methods will be used tactically within Develop but the overall structure follows the Double Diamond to match the organisation's planning cadence.
Best Practices
Always start with the project's needs, not the team's favourite framework. Run the problem-clarity audit (Step 1) before defaulting to whatever you used last time.
Treat frameworks as composable toolkits, not religions. The most effective teams borrow specific techniques across Double Diamond, Design Thinking, and Lean UX rather than following one model dogmatically.
Document your framework choice and rationale in a lightweight process brief that every team member and stakeholder can access. This prevents 'process drift' mid-project.
Match your framework's artefact expectations to your stakeholder governance model. If leadership needs formal deliverables at phase gates, the Double Diamond's structure makes this natural.
When comparing double diamond vs design thinking for a specific project, weight problem ambiguity highest. The more ambiguous the problem, the more valuable the Double Diamond's explicit problem-framing diamond becomes.
Revisit your framework choice at project retrospectives. A framework that was right at kickoff may need adjustment as you learn more about the problem and solution spaces.
Common Mistakes
Treating the Double Diamond and Design Thinking as completely separate, incompatible approaches
Correction
Recognise that they share core principles (empathy, iteration, diverge-converge). Use one as a macro structure and borrow techniques from the other. For example, use Design Thinking's prototyping methods within the Double Diamond's Develop phase.
Choosing a framework based on team familiarity rather than project fit
Correction
Run the structured evaluation (problem clarity, org constraints, team skills) before selecting. A bootcamp-trained team might default to Design Thinking even when the project's deep ambiguity demands the Double Diamond's extended Discover phase.
Skipping the first diamond of the Double Diamond because it 'feels slow' compared to Design Thinking's prototype-first energy
Correction
The first diamond exists precisely to prevent solving the wrong problem. If you skip Discover and Define, you risk building elegant solutions to misdiagnosed needs. Budget the time upfront and communicate its risk-reduction value to stakeholders.
Over-engineering a hybrid framework with too many layers, stages, and artefacts
Correction
Keep your hybrid simple: one primary backbone, 2-3 borrowed techniques maximum. Complexity in the process model translates directly into confusion for the team and overhead that slows delivery.
Presenting the framework choice as a design team decision rather than a project-level alignment
Correction
Involve product managers, engineering leads, and sponsors in the framework discussion. When the whole project team understands the process, they can contribute meaningfully to each phase rather than waiting for 'design to finish.'
Other Skills in This Method
Converging on Solutions in the Deliver Phase
How to evaluate, test, and iterate on concepts to select and refine the final solution for implementation in the Deliver phase.
Synthesizing Insights to Define the Problem
How to apply convergent thinking in the Define phase to analyze discovery findings, create problem statements, and narrow focus to the right challenge.
Facilitating Divergent Ideation in the Develop Phase
How to run structured brainstorming, co-design workshops, and prototyping sessions to generate a wide range of potential solutions in the second diamond.
Mapping Divergent and Convergent Thinking Modes
How to deliberately switch between expansive exploration and focused decision-making at each stage of the Double Diamond process.
Conducting Discovery Research in the Discover Phase
How to use divergent thinking techniques like user interviews, desk research, and observation to broadly explore the problem space in the first diamond.
Creating Double Diamond Process Diagrams
How to visually map your design process onto the Double Diamond diagram to communicate project phases, activities, and progress to stakeholders.
Adapting the Double Diamond for UX Design Projects
How to apply the Double Diamond framework specifically to UX workflows, integrating user research, wireframing, usability testing, and iterative design.
Frequently Asked Questions
What is the main difference between the Double Diamond and Design Thinking?
The Double Diamond explicitly separates problem-framing (Diamond 1: Discover, Define) from solution-finding (Diamond 2: Develop, Deliver), with clear phase transitions. Design Thinking interleaves these through five stages (Empathize, Define, Ideate, Prototype, Test) with more fluid iteration between stages.
Can I combine the Double Diamond and Design Thinking on the same project?
Yes, and many teams do. A common approach is to use the Double Diamond as the macro process structure and borrow Design Thinking techniques—like rapid prototyping and usability testing—within the second diamond's Develop and Deliver phases.
When should I choose the Double Diamond over Design Thinking?
Choose the Double Diamond when the problem is highly ambiguous, when multiple stakeholders disagree on the root cause, or when your organisation uses stage-gate governance that benefits from the model's clear phase transitions and decision points.
Is Lean UX a better alternative to both the Double Diamond and Design Thinking?
Lean UX is not necessarily better—it's optimised for a different context. It works best in cross-functional agile squads focused on continuous delivery and outcome-driven experiments. It complements rather than replaces the Double Diamond or Design Thinking.
How does double diamond vs design thinking affect stakeholder communication?
The Double Diamond's visual two-diamond structure and explicit phase gates make it easier to communicate progress to senior stakeholders who expect milestone-based reporting. Design Thinking's iterative loops can be harder to translate into traditional project governance without additional framing.
Do I need to learn both frameworks before choosing one?
You should understand the core structure, key activities, and ideal contexts for each framework before making an informed choice. You don't need deep expertise in every method within each framework—focus on understanding their structural differences and when each excels.