Adapting the Double Diamond UX Framework for Design Projects
This skill teaches you how to map the Double Diamond's four phases—Discover, Define, Develop, and Deliver—to concrete UX activities like user research, persona synthesis, wireframing, and usability testing so your design process is both structured and user-centered.
To adapt the Double Diamond for UX, map each of its four phases to specific UX activities. Use the Discover phase for user research and contextual inquiry, Define for synthesizing personas and problem statements, Develop for wireframing and divergent ideation, and Deliver for usability testing and iterative high-fidelity design. Embed continuous user feedback loops between phases to validate decisions.
Outcome: You can confidently structure any UX design project using the Double Diamond, assigning the right UX methods to each phase and knowing when to diverge, converge, and iterate.
Prerequisites
- Basic understanding of the Double Diamond framework and its four phases
- Familiarity with core UX methods (user interviews, wireframing, usability testing)
- Experience working on at least one digital product design project
Overview
The Double Diamond is a powerful design process model, but its original formulation by the British Design Council was intentionally generic—applicable to service design, product innovation, policy design, and more. When you're running a UX design project, you need to translate its abstract phases into the specific artifacts, rituals, and feedback loops that UX practitioners actually use.
Adapting the double diamond UX process means deciding which research methods belong in Discover, how to translate raw findings into actionable problem statements in Define, which fidelity of prototyping fits the Develop phase, and how usability testing and iteration drive Deliver. Getting this mapping right prevents the common failure mode where teams either skip research and jump to wireframes, or conduct research that never connects to design decisions.
This skill gives you a practical playbook for running the Double Diamond as a UX team. You'll learn how to layer in user-centered activities at every phase, create checkpoints that prevent wasted effort, and maintain the divergent-convergent rhythm that makes the framework so effective—all while producing the deliverables stakeholders expect from a UX process.
How It Works
The Double Diamond works by alternating between divergent thinking (expanding possibilities) and convergent thinking (narrowing to decisions) across two problem spaces. The first diamond is about finding the right problem; the second is about finding the right solution.
In a UX context, this translates to a critical insight: you cannot design a good interface until you deeply understand the user's world, and you cannot ship a good product until you've tested your design with real users. The framework enforces this discipline by making research and synthesis precede any design work, and by making testing and iteration precede any final delivery.
Each phase maps to a UX-specific mindset:
- Discover (Divergent): Cast a wide net with user research. You're not validating ideas—you're uncovering needs, behaviors, and pain points you didn't expect. Methods include contextual inquiry, diary studies, stakeholder interviews, and analytics review.
- Define (Convergent): Synthesize research into actionable artifacts. Create personas, journey maps, jobs-to-be-done statements, and a clear problem brief. The goal is a single, well-scoped problem statement your team commits to solving.
- Develop (Divergent): Generate many possible solutions. Sketch, wireframe, run design studios, and explore interaction patterns without prematurely committing. Low-fidelity is key here—speed matters more than polish.
- Deliver (Convergent): Refine the strongest concepts through high-fidelity prototyping, usability testing, and iteration. Converge on a validated solution ready for development.
The UX adaptation adds one critical element the original framework underemphasizes: feedback loops between phases. Usability testing in Deliver often reveals that the problem was defined too narrowly, sending you back to Define. A wireframe exploration in Develop might surface a user need you missed, looping back to Discover. These loops aren't failures—they're the mechanism that makes UX design rigorous.
Step-by-Step
Step 1: Audit Your Project Context and Constraints
Before mapping the Double Diamond, assess what you're working with. Identify the project timeline, team composition, existing research, stakeholder expectations, and technical constraints. This determines how you'll weight each phase.
For a greenfield product with no existing users, you'll invest heavily in Discover. For a mature product with a specific conversion problem, you might compress Discover and expand Develop and Deliver. The Double Diamond is a framework, not a rigid recipe—adapting it to your context is the entire point.
Document your constraints in a brief project canvas: what's the business goal, who are the users, what's the timeline, and what existing knowledge can you build on.
Tip: Create a simple 2x2 matrix plotting 'What we know' vs. 'What we need to learn' for both the problem space and solution space. This instantly reveals which diamond needs more investment.
Step 2: Plan the Discover Phase with UX Research Methods
Select research methods that match your constraints and knowledge gaps. For generative discovery, plan contextual inquiries, user interviews (5-8 participants minimum for qualitative saturation), diary studies, or ethnographic observation. Supplement with quantitative data: analytics, support ticket analysis, and competitive audits.
The key UX adaptation here is making Discover about the user, not about the business. Stakeholder interviews are important, but they inform your understanding of business constraints—they don't define the problem. Schedule stakeholder interviews early, then shift entirely to user-facing research.
Plan to capture raw data in a format that's easy to synthesize later: interview recordings with timestamps, observation photos, verbatim quotes on sticky notes or a digital equivalent like Miro or FigJam.
Tip: Schedule a 'download session' at the end of each research day where the team shares surprising findings. This builds shared understanding and prevents the researcher from becoming a bottleneck in Define.
Step 3: Synthesize and Define the Core UX Problem
Transition from Discover to Define by running a structured synthesis workshop. Use affinity mapping to cluster research findings, then extract patterns into themes. From these themes, build UX artifacts that make the problem tangible:
- Personas grounded in real research data (not demographic fiction)
- Journey maps showing current-state pain points and moments of truth
- Jobs-to-be-done statements that capture user motivation
- How Might We questions that frame the design challenge
The Define phase must produce a single, clear problem statement the entire team agrees on. Use a format like: '[Persona] needs a way to [user need] because [insight from research], but currently [barrier].' This statement becomes the brief for the second diamond.
This is the most critical phase for UX teams because skipping or rushing it is the #1 reason design projects fail. A well-defined problem prevents the team from solving the wrong thing with beautiful wireframes.
Tip: Post the problem statement prominently in your workspace or project channel. Reference it explicitly in every design review. If a proposed solution doesn't address the defined problem, flag it immediately.
Step 4: Run Divergent Ideation with Low-Fidelity UX Artifacts
Enter the Develop phase by generating multiple possible solutions—not just one. Use techniques like Crazy 8s, design studio workshops, and collaborative sketching to produce many ideas quickly. The goal is volume and variety, not quality.
For UX projects, the artifacts at this stage should be deliberately low-fidelity: paper sketches, rough wireframes, simple user flows, and concept maps. Low fidelity serves two purposes—it's fast to produce, and it signals to stakeholders and team members that ideas are open for radical change.
Organize a structured critique after ideation. Use the problem statement from Define as the evaluation lens: which concepts best address the defined user need? Dot voting, impact-effort matrices, or a simple 'best of' selection process all work. The goal is to narrow from many concepts to 2-3 promising directions to explore further.
Tip: Invite engineers and product managers into ideation sessions. They bring feasibility awareness that prevents pursuing technically impossible concepts, and their participation builds buy-in for the eventual solution.
Step 5: Prototype at Increasing Fidelity
Take your 2-3 strongest concepts and build them into testable prototypes. Start with mid-fidelity wireframes—enough structure to communicate the interaction model, but not so polished that users focus on visual details.
Tools like Figma, Sketch, or even PowerPoint can produce clickable prototypes sufficient for early validation. Focus on the critical user flows that address your problem statement. Don't prototype the entire product—prototype the decision points that matter most.
As you get signal from testing (next step), increase fidelity selectively. The screens and flows that test well get visual design treatment. The ones that don't get redesigned or discarded. This progressive fidelity approach prevents the sunk-cost fallacy where teams ship a bad design because they spent too long making it pixel-perfect.
Tip: Create a 'prototype plan' that lists exactly which screens and flows you're building, what question each one answers, and what level of fidelity it needs. This prevents scope creep in prototyping.
Step 6: Validate with Usability Testing and Iterate
The Deliver phase in a double diamond UX process is defined by testing. Run moderated usability tests with 5 representative users per round (based on Nielsen's research on diminishing returns). Give participants realistic tasks tied to your problem statement and observe where they succeed, struggle, or fail.
Capture findings with severity ratings: critical (blocks task completion), major (causes significant confusion), and minor (cosmetic or preference-based). Address critical and major issues immediately, then retest.
Plan for 2-3 rounds of testing and iteration. Each round should show measurable improvement in task completion rates, time-on-task, or error frequency. This iterative loop is what separates a UX-adapted Double Diamond from a waterfall design process—you're converging on a validated solution, not just a finished one.
After the final round, compile your usability findings, final designs, and a specification document for engineering handoff.
Tip: Record usability sessions (with consent) and create a 3-minute highlight reel of the most impactful moments. This is the most effective stakeholder communication tool in UX—more persuasive than any report.
Step 7: Build Feedback Loops Between Phases
The most important UX adaptation of the Double Diamond is making the phases non-linear. After each major activity, ask: 'Did we learn something that challenges our assumptions from a previous phase?'
Common feedback loops in UX projects include:
- Deliver → Define: Usability testing reveals users need something different from what you defined. Revisit the problem statement.
- Develop → Discover: Ideation surfaces questions about user behavior that require additional research.
- Deliver → Develop: Testing shows the chosen concept doesn't work. Return to your other concepts from ideation.
Build explicit checkpoints into your project plan where the team reviews whether the current phase's outputs still align with previous phases. These aren't gates that block progress—they're moments of reflection that prevent expensive mistakes downstream.
Tip: Use a simple 'confidence tracker' where the team rates their confidence (1-5) in the problem definition and solution direction at the end of each week. A drop in confidence is a signal to loop back.
Examples
Example: Redesigning a SaaS Onboarding Flow
A B2B SaaS company sees 60% of new users abandon the product within 3 days of signing up. The product team assumes the onboarding flow is confusing, but has no research to confirm this. They have 6 weeks and a team of 2 UX designers, 1 researcher, and a product manager.
Discover (Week 1-2): The researcher conducts 8 interviews with recent sign-ups—4 who became active users and 4 who churned. They also analyze product analytics to identify the exact screens where users drop off, and review 50 support tickets from the first week of sign-up. Surprising finding: users don't find the flow confusing—they don't understand why they should complete it. The value proposition is unclear.
Define (Week 2, latter half): The team runs an affinity mapping session and creates a journey map of the first 72 hours. They define the problem as: 'New users need to experience the product's core value within their first session because they don't yet trust that the setup effort is worthwhile, but the current onboarding asks them to configure 12 settings before showing any results.' They write three How Might We statements focused on delivering value faster.
Develop (Week 3-4): The team runs a design studio generating 3 concepts: (A) a guided tour that shows pre-populated sample data, (B) a 'quick start' mode that skips configuration and uses smart defaults, and (C) a progressive onboarding that unlocks features as users hit milestones. They wireframe all three as clickable prototypes covering the first 5 minutes of the user experience.
Deliver (Week 4-6): Round 1 usability testing with 5 users shows Concept B (smart defaults) gets users to the 'aha moment' fastest, but users feel confused about what they missed by skipping configuration. The team iterates by combining B's fast start with C's progressive disclosure—configuration surfaces naturally as users need each feature. Round 2 testing with 5 new users shows a 4x improvement in task completion for the core action. The team finalizes high-fidelity designs and hands off to engineering with annotated specs.
Example: Designing a Mobile Health Tracking Feature
A health app wants to add medication tracking. The PM has a feature spec, but the UX team wants to validate assumptions before designing. They have 4 weeks.
Discover (Week 1): The team conducts a competitive audit of 6 medication tracking apps and runs 6 remote interviews with people who currently track medications (some using apps, some using pill organizers or memory alone). Key insight: the biggest pain point isn't logging medications—it's remembering in context, especially when routines change (travel, weekends, illness).
Define (End of Week 1): The team reframes the problem from 'users need a way to log medications' to 'users need contextual reminders that adapt to their changing daily routines.' This significantly shifts the solution space away from the PM's original spec of a simple checklist.
Develop (Week 2): Three concepts emerge: smart reminders tied to phone activity patterns, a 'routine builder' that lets users link meds to daily habits, and a simple list with aggressive notification scheduling. Low-fidelity wireframes and flow diagrams are created for each.
Deliver (Week 3-4): Concept testing with 5 users reveals the routine-linking approach resonates most strongly, but users want the ability to quickly adjust when their routine breaks. The team iterates on the routine builder to include a 'flexible mode' for irregular days. Final usability testing confirms the approach, and the team delivers a design spec that's substantially different from—and more effective than—the original feature request.
Best Practices
Keep the first diamond (Discover + Define) at least 30-40% of your total project timeline. Teams consistently underinvest in problem understanding and overinvest in solution creation.
Use a shared research repository (Dovetail, Notion, or even a structured spreadsheet) so that Discover findings remain accessible throughout the entire project—not locked in one researcher's head.
Match prototype fidelity to the question you're answering. Testing navigation structure? Paper prototypes work. Testing micro-interactions? You need high-fidelity clickable prototypes.
Run a formal 'problem lock' ceremony at the end of Define where the team and stakeholders explicitly agree on the problem statement. This prevents scope drift in the second diamond.
Schedule usability testing sessions before you start designing. Having a fixed test date creates healthy pressure and prevents the Develop phase from expanding indefinitely.
Document design decisions with the reasoning behind them, linked to specific research findings. This creates traceability from user insight to final design and helps justify decisions to stakeholders.
Common Mistakes
Skipping the first diamond entirely and jumping straight to wireframing because the team 'already knows the problem'
Correction
Even with strong intuitions, run at least a compressed Discover phase (5 user interviews + analytics review). Teams that skip research consistently solve the wrong problem or solve the right problem for the wrong user segment.
Treating Develop as 'design the one obvious solution' rather than genuinely diverging with multiple concepts
Correction
Force the team to generate at least 3 meaningfully different concepts before converging. Use structured ideation techniques like Crazy 8s or design studios that make it physically impossible to just refine one idea.
Creating high-fidelity mockups during the Develop phase, making the team emotionally attached to a specific visual direction too early
Correction
Enforce a 'wireframe-only' rule during Develop. Visual design happens only after concept validation in early Deliver. This keeps the team open to pivoting based on test results.
Running usability tests only once at the very end of the project, treating it as validation theater rather than a learning tool
Correction
Plan for iterative testing: test early with low-fidelity prototypes, test again with refined designs. Each round should have a specific hypothesis to validate, not just 'see if users like it.'
Applying the Double Diamond identically to every project regardless of size, timeline, or existing knowledge
Correction
Scale the framework to your context. A 2-week sprint might compress all four phases into lightweight versions. A 6-month initiative might run the full framework. The phases should always be present, but their depth varies.
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.
Choosing Between Double Diamond and Design Thinking
How to compare the Double Diamond with other design frameworks like Stanford d.school Design Thinking and Lean UX to select the right approach for your project.
Frequently Asked Questions
How is the Double Diamond different from Design Thinking for UX?
The Double Diamond explicitly separates problem-finding (first diamond) from solution-finding (second diamond), while Design Thinking's five stages (Empathize, Define, Ideate, Prototype, Test) blend these more fluidly. For UX teams, the Double Diamond's structure is often easier to plan against and communicate to stakeholders. See our comparison in [Choosing Between Double Diamond and Design Thinking](/methods/double-diamond/choosing-between-double-diamond-and-design-thinking).
How long should each phase of the double diamond UX process take?
A common split is 25% Discover, 15% Define, 30% Develop, 30% Deliver, but this varies by project. Greenfield projects need more Discover time. Projects with established user research can compress the first diamond and invest more in Develop and Deliver.
Can I use the Double Diamond in agile sprints?
Yes. Run a compressed first diamond (Discover + Define) as a 'Sprint 0' or discovery sprint, then execute the second diamond (Develop + Deliver) across subsequent sprints. Each sprint can also contain a mini double diamond for individual features.
What UX deliverables come out of each Double Diamond phase?
Discover produces research reports, interview transcripts, and raw data. Define produces personas, journey maps, and a problem statement. Develop produces sketches, wireframes, and concept prototypes. Deliver produces tested high-fidelity designs, usability reports, and engineering-ready specifications.
How do I convince stakeholders to invest time in the Discover phase instead of jumping to design?
Frame Discover as risk reduction, not delay. Show examples where skipping research led to expensive rework. Propose a time-boxed Discover phase (e.g., one week of interviews) and promise a concrete deliverable—a problem statement the team commits to—at the end.
What's the minimum viable version of the Double Diamond for a small UX project?
At minimum, conduct 5 user interviews (Discover), synthesize into one problem statement (Define), sketch 3 concepts and pick one (Develop), and run a single round of usability testing with 5 users (Deliver). This can fit in 2 weeks and still provides the framework's core benefit of separating problem-finding from solution-finding.