Converging on Final Solutions in the Double Diamond Model Deliver Phase

Overview

How It Works

Step-by-Step

1. Step 1: Establish Evaluation Criteria Before Reviewing Concepts

   Before you look at any candidate solutions, define the criteria you'll use to evaluate them. This prevents anchoring bias — the tendency to evaluate everything relative to the first concept you see.

   Pull your criteria from three sources: the problem statement from your Define phase (what user need must this solve?), business constraints (budget, timeline, technical stack, regulatory requirements), and design principles your team has established.

   Organize criteria into two tiers: must-haves (non-negotiable requirements — if a concept fails these, it's eliminated regardless of other strengths) and differentiators (qualities that separate good solutions from great ones, like delight, scalability, or brand alignment). Weight the differentiators so your team agrees on what matters most before emotions enter the picture.

   Tip: Write your criteria on a shared document or whiteboard before the evaluation session. Having them physically visible prevents scope creep during discussions.

2. Step 2: Screen Concepts Against Must-Have Criteria

   Run a rapid screening pass across all candidate concepts from the Develop phase. This is a binary exercise: does each concept meet every must-have criterion? If not, it's eliminated.

   This step should be fast — 5-10 minutes per concept maximum. Use a simple matrix with concepts as rows and must-have criteria as columns. Mark each cell as pass or fail. Don't debate edge cases at this stage; if a concept requires significant assumptions to pass a criterion, mark it as a fail.

   The goal is to reduce your set from potentially dozens of concepts down to 2-5 viable candidates worth investing prototyping effort into.

   Tip: If every concept fails a particular criterion, that's a signal to revisit the criterion itself or loop back to the Develop phase for more ideation. Don't force a bad fit.

3. Step 3: Score Surviving Concepts with a Weighted Decision Matrix

   For the concepts that passed screening, conduct a more nuanced evaluation using your weighted differentiator criteria. Create a decision matrix where each team member independently scores each concept on each differentiator (e.g., 1-5 scale), then multiply by the agreed-upon weight.

   Have team members score independently before revealing results to avoid groupthink. Once scores are visible, discuss the outliers — where did people disagree most? These disagreements are the most valuable part of the exercise because they surface hidden assumptions about user needs, technical feasibility, or business strategy.

   The matrix output gives you a ranked list, but don't treat it as gospel. Use it as a conversation tool to build alignment around which 2-3 concepts deserve prototyping investment.

   Tip: Include at least one stakeholder from engineering/development in the scoring. They'll catch feasibility issues that designers often underestimate.

4. Step 4: Prototype the Top Candidates at Appropriate Fidelity

   Build prototypes of your top 2-3 concepts. The critical decision here is fidelity level. Match your prototype fidelity to the questions you need to answer:

   • Low fidelity (paper sketches, wireframes): Use when you need to test information architecture, user flows, or core value propositions. Takes hours, not days.
   • Medium fidelity (clickable prototypes in Figma/Sketch): Use when you need to test interaction patterns, visual hierarchy, or compare the feel of different approaches. Takes 1-3 days per concept.
   • High fidelity (coded prototypes or pixel-perfect mockups): Use only when lower fidelity has already validated the core concept and you need to test edge cases, performance, or emotional response to visual design. Takes a week or more.

   The most common mistake is building too high a fidelity too early, which wastes time and creates emotional attachment to a particular solution. Start as low as you can while still getting meaningful signal.

   Tip: Build prototypes that are just good enough to test your riskiest assumptions. If you're unsure whether users understand the core concept, a paper prototype is sufficient — you don't need polished visuals yet.

5. Step 5: Test Prototypes with Real Users

   Run structured usability tests with 5-8 representative users per concept. Design your test protocol to directly measure performance against your evaluation criteria — don't just ask users if they "like" the design.

   For each test session:

   • Give participants realistic tasks that exercise the core user flow
   • Observe where they struggle, hesitate, or succeed
   • Capture both quantitative metrics (task completion rate, time on task, error rate) and qualitative observations (verbal feedback, facial expressions, workarounds they invent)
   • Ask follow-up questions that probe comprehension and perceived value, not just preference

   After testing all concepts, synthesize findings into a comparison that maps directly back to your evaluation criteria. Which concept performed best on the criteria that matter most?

   Tip: Record sessions (with permission) so the broader team can review key moments. Seeing a real user struggle with a concept is far more persuasive than a summary slide.

6. Step 6: Select the Winning Concept and Document the Decision

   Using your test results, updated decision matrix scores, and team discussion, select the concept that will move forward into refinement. This is a convergence point — commit fully to one direction.

   Document your decision and the evidence behind it. This serves two purposes: it creates accountability (you can explain why you chose this path), and it provides a reference point if stakeholders later question the direction.

   Include in your documentation: the concepts you evaluated, the criteria you used, key test findings for each concept, the rationale for your selection, and any known risks or open questions about the chosen concept.

   Tip: If the decision is genuinely close between two concepts, consider whether elements from the runner-up can be incorporated into the winner. Sometimes the best solution is a hybrid — but only if the combination is coherent, not a Frankenstein.

7. Step 7: Iterate on the Selected Solution Through Refinement Cycles

   With one concept selected, begin iterative refinement. Each cycle follows a tight loop: identify the biggest remaining weakness or open question → adjust the prototype → test the change → evaluate results.

   Increase prototype fidelity with each cycle as you resolve major issues and move toward implementation-ready specifications. Early cycles might focus on flow and content; later cycles address visual design, edge cases, error states, and accessibility.

   Plan for 2-4 refinement cycles minimum. Set clear exit criteria — what level of task completion rate, user satisfaction, or stakeholder sign-off constitutes "ready for implementation"? Without exit criteria, refinement becomes infinite polishing.

   Tip: Time-box your refinement cycles. Two-week sprints with a test at the end of each sprint create healthy pressure to make decisions and prevent perfectionism.

8. Step 8: Prepare the Solution for Implementation Handoff

   Once the solution passes your exit criteria, prepare it for the teams who will build it. This typically includes:

   • Detailed design specifications (annotated mockups, interaction specifications, responsive behavior)
   • A design rationale document linking key decisions back to research findings
   • A prioritized backlog of features if the solution will be built incrementally
   • Known constraints, trade-offs, and future iteration opportunities
   • Success metrics that will be tracked post-launch to validate the solution in production

   The handoff is not a wall — stay involved during implementation to answer questions, make micro-decisions, and ensure the built solution matches the tested prototype. The Deliver phase of the double diamond model doesn't end when design files are shared; it ends when the solution is live and delivering value.

Examples

Best Practices

• Define evaluation criteria before reviewing any concepts to prevent anchoring bias and HiPPO (highest-paid person's opinion) dynamics from distorting your decision.

• Prototype at the lowest fidelity that still answers your most critical question — this maximizes learning speed and minimizes sunk-cost attachment to specific solutions.

• Test with users who match your target audience, not colleagues or friends. Internal testers have too much context and will navigate your prototype differently than real users.

• Separate desirability testing (do users want this?) from usability testing (can users use this?). A concept can score well on one dimension and fail on the other.

• Set explicit exit criteria for your refinement cycles before you begin iterating. Without a clear definition of 'good enough,' teams oscillate between solutions or polish indefinitely.

• Invite a cross-functional group — design, engineering, product, and business — to the concept evaluation sessions. Each discipline catches risks the others miss.

Common Mistakes

Frequently Asked Questions