Design Thinking “Double Diamond” process

1. What Is the Design Thinking “Double Diamond” Process?

The Double Diamond is a practical, visual process for solving ambiguous problems and designing products, services, or experiences that people actually want. It organizes work into two repeating patterns—diverging to explore many possibilities, and converging to make clear choices—across four stages: Discover, Define, Develop, and Deliver. Teams first broaden their understanding of the problem (Discover), narrow it to a sharp definition (Define), explore multiple solutions (Develop), and then converge on and validate the best options (Deliver).

Within Agile, Innovation & Networked‑Organization frameworks, the Double Diamond complements iterative delivery (Scrum, Kanban) by strengthening the front‑end of innovation—problem framing, insight generation, and concept validation—so delivery teams build the right thing, not just build quickly. It provides a shared language and cadence for designers, product managers, engineers, and business stakeholders to move from fuzzy problem to validated solution.

In plain terms: it’s a disciplined way to zoom out, make sure you’re solving the right problem, generate options, test them with users, and ship with confidence—without getting lost or stuck.

2. Origin and Background

The Double Diamond was created and popularized by the UK Design Council in 2005 as a simple, visual model of the design process. It was refreshed in 2019 as the “Framework for Innovation,” emphasizing iteration, inclusion, and systems thinking. The four stages—Discover, Define, Develop, Deliver—and the core logic (diverge, converge, diverge, converge) have since become a common design and product language across industries.

Why it was created: to demystify design, show the importance of both exploration and decision, and give organizations a flexible, repeatable approach to create better outcomes for users and the business. It became widely known through design education, corporate design teams, and consulting practice—often blended with Lean Startup, Design Sprints, and Agile delivery.

3. How the Double Diamond Works

The model is built on two simple moves done twice: divergence to broaden options and perspectives, and convergence to focus and decide. Each stage has typical activities and artefacts.

Diamond 1: Understand the Problem

• Discover (diverge): Explore the problem space. Activities: stakeholder and user interviews, contextual inquiry, data/behavior analysis, service/journey mapping, competitive scans. Artefacts: research plan, raw observations, themes, opportunity areas, “jobs to be done,” pain points, and drivers.
• Define (converge): Synthesize and decide what to solve. Activities: affinity mapping, insight statements, “How Might We” (HMW) questions, segmentation/personas (or jobs), problem framing, target outcomes and metrics. Artefacts: problem statement, success criteria, prioritized opportunity list, design principles.

Diamond 2: Create and Validate Solutions

• Develop (diverge): Generate and explore solution options. Activities: ideation workshops, storyboarding, service blueprinting, technical feasibility spikes, low‑fidelity prototyping. Artefacts: concept sketches, flows, wireframes, blueprints, assumptions to test.
• Deliver (converge): Test, refine, and ship. Activities: usability tests, multivariate/A‑B tests, concierge/MVP pilots, engineering spikes, launch planning. Artefacts: validated prototype, experiment results, MVP backlog, release plan, outcome tracking plan.

The key is evidence‑based decisions: each convergence step turns insights and experiments into explicit choices that shape what the team builds next. Iteration is expected—you may loop back if insights or tests contradict your assumptions.

4. When to Use the Double Diamond

Most helpful when:

• Problem and solution are ambiguous (new product, new journey, market shift, poor adoption of an existing feature).
• You need to align stakeholders around what problem matters and how to measure success.
• Customer, operational, or regulatory constraints are complex and require synthesis across functions.
• Agile teams are shipping fast but missing user or business outcomes (low activation, low conversion, high drop‑off).

Especially powerful: Paired with Agile sprints (for delivery), Design Sprints (rapid exploration inside Develop/Deliver), Lean Startup experiments (for MVP validation), and product OKRs (to define outcomes in Define and measure in Deliver).

Less suitable or potentially misleading:

• When the problem is well‑understood and standardized—go straight to delivery with light validation.
• If treated as a linear waterfall; the model is iterative—you jump back when evidence changes your view.
• If used as “research theater”: lots of discovery without decisions, tests, or shipped increments.

5. How to Apply the Double Diamond: Step‑by‑Step

1. Frame the challenge and outcomes (before Discover).

   Write a one‑page brief: scope, users, constraints, and business outcomes (e.g., “Increase onboarding completion from 62% to 80% in six months”). Align on guardrails (privacy, regulatory, brand, tech stack), time‑box the effort (e.g., 6–10 weeks), and agree on decision rights.

2. Discover: Plan and gather evidence.

   Blend qualitative and quantitative methods:

   • Data: funnel analysis, task success, operational metrics, support tickets, search logs.
   • Field research: short interviews, contextual inquiry, call listening, diary studies.
   • Journey/service mapping: frontstage experiences and backstage processes causing friction.
   • Constraints scan: legal, risk, platform, architecture.

   Keep it lean; “just enough” to surface patterns and opportunity areas.

3. Define: Synthesize and decide the problem to solve.

   Turn evidence into a focused brief:

   • Affinity map patterns; articulate key insights (“New users are overwhelmed in the first 5 minutes”).
   • Craft “How Might We” questions and candidate problem statements.
   • Select target problems and outcomes (OKR‑style) using an impact/effort or RICE lens.
   • Write design principles (e.g., “fewer than three decisions before value”).

   Produce a clear problem statement, success metrics, and constraints for ideation.

4. Develop: Generate options and prototype.

   Run short cycles (1–2 weeks) to create and iterate:

   • Ideate widely (brainwriting, “crazy 8s,” analogs from other industries).
   • Sketch storyboards and flows; select a few concepts to prototype.
   • Create low‑fidelity prototypes (paper, clickable wireframes) to de‑risk desirability and usability.
   • In parallel, run technical spikes to test feasibility (APIs, data availability, compliance).

   Capture assumptions and define the riskiest ones to test first.

5. Deliver: Test, learn, and prepare to ship.

   Move from “could work” to “does work”:

   • Usability tests (5–8 users per round); measure task success, time‑on‑task, error rates.
   • Quant experiments: smoke tests, fake‑door tests, landing pages, or in‑product A/B tests.
   • Define MVP scope, acceptance criteria, telemetry, and a rollout plan (feature flags, canaries).
   • Create the MVP backlog for engineering sprints; agree on outcome metrics and decision thresholds.

   Tight loops: test → learn → refine → commit or kill.

6. Integrate with Agile delivery.

   Translate validated concepts into a prioritized backlog with clear user stories/acceptance criteria. Plan engineering sprints; keep design 1–2 sprints ahead with continuous discovery. Instrument telemetry to track the OKRs defined earlier.

7. Govern with decisions and evidence.

   Use lightweight stage gates tied to evidence, not slide decks: “Problem framing signed off,” “Assumptions tested,” “MVP metrics met.” Keep stakeholders engaged through show‑and‑tells, not after‑the‑fact reviews.

8. Measure outcomes and scale what works.

   Post‑launch, track the outcome metrics (e.g., adoption, conversion, NPS, revenue, cost‑to‑serve). If the MVP meets thresholds, scale; if not, iterate or pivot—guided by the evidence from your Double Diamond work.

6. Example: Double Diamond in Action

Context: A 5,000‑employee SaaS company saw low activation for a new analytics product—only 28% of trials created a first dashboard within 48 hours. Engineering shipped on time, but adoption lagged. The CPO chartered a cross‑functional team to run a Double Diamond in eight weeks.

Application:

• Discover: Analyzed funnels, interviewed 18 trial users, reviewed 200 support tickets, and mapped the onboarding journey. Insights: users were confused by data source setup and didn’t see an example of value quickly.
• Define: Problem statement: “Trial users fail to see meaningful insight in the first session.” Target outcome: “Increase first‑dashboard creation to 60% in 60 days.” Design principles: “Value in five minutes,” “Guidance, not clutter.”
• Develop: Ideated and prototyped three concepts: guided setup, sample data with storytelling templates, and a one‑click Google Analytics connector. Quick feasibility spikes showed the connector was straightforward; sample data required careful privacy messaging.
• Deliver: Ran 12 usability sessions; the sample data + templates concept had 90% task success and highest satisfaction. Shipped an MVP behind a feature flag to 10% of traffic; A/B tests lifted first‑dashboard creation from 28% to 58% and 7‑day retention by 9 points.

Outcomes: The MVP scaled to 100% of trials in six weeks. Engineering instrumented telemetry per the Define metrics. Activation sustained at 60%+, support tickets on setup dropped 35%, and paid conversion rose 6 points. The model was then reused for the admin experience.

7. Strengths and Limitations

Strengths

• Sharpens problem framing: Forces teams to validate the problem before proposing solutions.
• Balances creativity with decision: Encourages many options, but also disciplined convergence with evidence.
• Common language: Simple stages executives and teams can align around; easy to plug into Agile delivery.
• Risk reduction: Early testing of desirability, feasibility, and viability cuts waste and cycle time later.

Limitations

• Can be misused as linear waterfall: If treated as a one‑way stage gate, it slows learning and delivery.
• Research bloat risk: Without time‑boxes and decision criteria, Discovery can expand indefinitely.
• Doesn’t replace prioritization or strategy: It’s a process, not a strategy—OKRs and portfolio choices still matter.
• Quality depends on craft: Weak synthesis or poor experiments lead to false confidence.

8. Common Pitfalls (and How to Avoid Them)

• Jumping to solutions.
  What goes wrong: Teams propose features before understanding user/jobs or constraints.
  Avoid by: Time‑box Discover/Define; require a clear problem statement and success metrics before ideation.
• Endless discovery.
  What goes wrong: Research continues without decisions or tests.
  Avoid by: Set explicit decision dates and criteria; move to Develop with the best available insight and iterate.
• Weak convergence.
  What goes wrong: Too many problem statements or concepts proceed; effort diffuses.
  Avoid by: Use prioritization (RICE, impact/effort), tie choices to metrics, and cut lower‑value options.
• Ignoring constraints.
  What goes wrong: Concepts die later due to compliance, privacy, or tech feasibility.
  Avoid by: Include legal, security, and engineering early; run feasibility spikes alongside design.
• Testing opinions, not behavior.
  What goes wrong: Over‑reliance on focus groups or preference surveys; poor predictive power.
  Avoid by: Use behavioral tests (task success, A/B, fake doors) and measure revealed preferences.
• Poor handoff to delivery.
  What goes wrong: Validated concepts stall; engineering lacks clarity.
  Avoid by: Produce an MVP backlog with acceptance criteria, telemetry plan, and decision thresholds.
• No outcome tracking post‑launch.
  What goes wrong: Teams declare victory on release, not results.
  Avoid by: Tie delivery to OKRs; review metrics weekly; iterate or roll back if targets are missed.

9. How the Double Diamond Relates to Other Frameworks

• Agile (Scrum/Kanban): Double Diamond informs what goes into the backlog; Scrum/Kanban deliver it. Many teams run Discover/Define slightly ahead of sprints and Develop/Deliver as pre‑MVP experiments inside sprints.
• Design Sprint (Google): A 4–5 day, time‑boxed slice mostly covering Develop/Deliver for one concept. Use Sprints within the Double Diamond when you need speed and focus.
• Lean Startup: The Build‑Measure‑Learn loop maps to Develop/Deliver. Double Diamond adds stronger problem framing in Discover/Define.
• Jobs‑to‑Be‑Done (JTBD): JTBD is a tool for Discover/Define—capturing user goals, struggles, and desired outcomes.
• Service Blueprinting & Journey Mapping: Methods primarily used in Discover/Develop to visualize experiences and backstage processes.
• OKRs: Set outcome targets in Define; track them in Deliver and post‑launch to close the loop.
• DevOps/SRE: Deliver benefits from feature flags, progressive rollouts, and observability to validate concepts safely in production.

10. Key Takeaways

• The Double Diamond is a simple, powerful process: diverge/converge on the problem (Discover/Define), then diverge/converge on solutions (Develop/Deliver).
• Use it to align on the right problem, generate options, test assumptions quickly, and feed validated work into Agile delivery.
• Make decisions with evidence—behavioral tests, usability results, and outcome metrics tied to OKRs.
• Time‑box each stage, involve engineering/legal early, and plan for iteration; avoid research or solution theater.
• Pair with Design Sprints, Lean Startup, Scrum/Kanban, and DevOps to turn insight into impact quickly and safely.

11. FAQs About the Double Diamond

Is the Double Diamond a waterfall process?
No. It’s iterative. The stages help you plan and communicate, but you can (and should) loop back when new evidence emerges. Fast, repeated Discover/Define and Develop/Deliver cycles beat one big pass.

How long does a typical Double Diamond take?
For a focused product problem, 6–10 weeks is common: 2–3 weeks Discover, 1–2 weeks Define, 2–3 weeks Develop, 1–2 weeks Deliver (pre‑MVP experiments). You can compress into a 1–2 week spike for smaller issues or expand for complex services.

What artefacts should we produce?
Keep it light and actionable: problem statement, success metrics (OKR‑style), key insights, HMWs, concept sketches/prototypes, assumptions to test, experiment results, and an MVP backlog with telemetry. Avoid heavy decks.

How does this differ from a Design Sprint?
A Design Sprint is a time‑boxed method inside the Develop/Deliver stages to quickly test one concept. The Double Diamond covers end‑to‑end—from understanding the problem to piloting and preparing for delivery.

Can B2B or internal processes use the Double Diamond?
Absolutely. Replace “consumer” research with customer interviews, sales/support insights, and workflow observation. Measure outcomes like time‑to‑complete, error rates, NPS/CSAT, adoption, and revenue impact.

How do we run this remotely?
Use collaborative tools for research synthesis and workshops; schedule shorter, more frequent sessions; record tests; and maintain a living board of artefacts and decisions. Remote works well if you keep time‑boxes and decision gates tight.

What if stakeholders want to skip discovery to save time?
Limit discovery, don’t skip it. A few days of targeted evidence often prevents months of building the wrong thing. Commit to a lightweight Discover/Define with a firm decision date and clear metrics to test.

How do we ensure decisions stick?
Document problem statements, design principles, and chosen concepts with the evidence behind them; gain sign‑off in short decision meetings; and link decisions to OKRs and MVP backlogs. Revisit only if new data warrants it.

How do we scale across many teams?
Adopt common artefacts and gates, run shared research repositories, and hold regular show‑and‑tells. Use chapters/guilds (communities of practice) to spread methods and maintain quality; tie initiatives to product area OKRs.