Converging on Final Solutions in the Deliver Phase

Converge on final solutions in the Double Diamond Deliver phase by testing concepts at small scale, rejecting weak ones and refining one to ship.

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

Converging on final solutions is the work of the Deliver phase, the closing half of the second diamond in the Double Diamond. Develop hands over several concepts that take different approaches to the agreed problem. Deliver tests them, drops the ones that fail, improves the ones that work, and prepares one for launch.

The Design Council describes delivery as "testing out different solutions at small-scale, rejecting those that will not work and improving the ones that will" (Framework for Innovation). Its earlier study of design in large companies listed the key activities of this stage as final testing, approval and launch, and targets, evaluation and feedback loops (Eleven lessons).

The inputs are the concepts and their riskiest assumptions, the problem statement from Define, the constraints the organisation works under (budget, technology, regulation, operations), and access to real users. The outputs are test results for each concept, a documented decision on which direction to take and why, a refined prototype or pilot, and a plan for measuring the solution after launch.

Convergence goes wrong in two opposite ways. Some teams choose by opinion: the concept the sponsor liked in the workshop wins, and testing becomes a formality. Others never converge: they keep testing and polishing several options until the time runs out. This skill aims between the two. Decide the criteria before you see results, test the riskiest assumptions first with small rounds, and make the choice explicit once the evidence is good enough.

This skill covers setting criteria, choosing what to test first, running small rounds of testing, comparing results, making and recording the decision, raising fidelity, and handing the solution to the people who will build and run it.

How It Works

Deliver runs as a series of short test-and-refine loops, each narrowing the field.

Criteria come first. Before anyone sees test results, agree what a good solution must do. Criteria usually come from three places: the problem statement (does it solve the problem for the people named?), the constraints (can we build, afford and operate it?), and the goals that funded the work. Writing criteria in advance protects the decision from whichever result arrives first or loudest.

Testing starts with the riskiest assumption behind each concept, which the UK government's service guidance treats as the focus of its alpha phase, alongside building prototypes and expecting to throw away much of the code and many of the ideas (GOV.UK alpha phase). If a concept depends on people trusting an automated message, test that before testing its layout.

Rounds are small and frequent. Jakob Nielsen's analysis found that about 5 users reveal roughly 85% of the usability problems in a design, and recommended spending the budget on 3 studies with 5 users each rather than one large study (NN/g on testing with 5 users). The reasoning carries over beyond interface testing: each small round tells you what to fix, and the next round checks the fix and finds the next layer of problems.

Fidelity rises as confidence grows. Early rounds use rough prototypes that can change during a session; later rounds use prototypes realistic enough that people behave as they would with the real thing (NN/g on prototype fidelity). Service concepts may move from role-play to a small live pilot.

Group decisions need structure too. Critique sessions should judge each concept against the agreed goals, as the NN/g guide to design critiques recommends. When a group has to pick among options, dot voting can surface preferences quickly, but it is prone to persuasion, split votes and groupthink, so vote silently and treat the result as input to the decision (NN/g on dot voting).

Delivery ends with launch, but the Design Council notes that no idea is ever finished in a digital world. Measures and feedback loops set up in Deliver are what tell the team whether to iterate or to loop back to Define.

Step-by-Step Guide

Step 1: Agree the decision criteria before testing

Write down what the chosen solution must achieve for users, what constraints it must respect, and which organisational goals it should serve. Separate must-haves from nice-to-haves. Get the sponsor and the people who will build the solution to agree the list. Keep it short enough that everyone can remember it during a review.

Step 2: Identify the riskiest assumption in each concept

For each concept, list the assumptions it depends on and mark the one that would sink it if wrong. Typical examples are whether people will trust it, whether they can use it without help, and whether the organisation can run it. Plan the first test round around those assumptions, following the GOV.UK alpha guidance. Drop any concept whose riskiest assumption cannot be tested at all within the time available, or flag it clearly.

Step 3: Run small, fast test rounds

Test each concept with a small number of people from the segments in your problem statement. Keep prototypes rough enough to change between sessions. After each round, list what failed, fix what can be fixed, and test again. Several small rounds tell you more than one large study, which is the argument in Nielsen's analysis.

Step 4: Compare concepts against the criteria

After a few rounds, lay the concepts side by side against the agreed criteria with the evidence for each judgement. Run a structured critique that ties every comment to a criterion. Eliminate concepts that fail a must-have. Combine strengths where two concepts complement each other, and test the combination before assuming it works.

Step 5: Make and record the decision

Choose the direction and write down why: which criteria it meets, which evidence supports it, and which concepts were rejected and why. If a group vote is part of the process, use silent voting and treat it as one input to the decision. Name who made the decision. A recorded decision stops the question being reopened every time someone new joins the project.

Step 6: Raise fidelity and test the full experience

Build a higher-fidelity prototype or a small pilot of the chosen solution. Test it end to end, including the moments before and after the main interaction, such as notifications, support contact and hand-offs between staff. Involve the engineers and operations staff who will run it so feasibility problems surface now. Fix, retest and keep a list of known issues.

Step 7: Prepare launch and the feedback loop

Agree how the solution will be released, starting with a small group where possible. Set the measures that will show whether it solves the problem named in Define, and decide who watches them and how often. Hand over the evidence, decision record and known issues to the delivery team. Schedule a review after launch to decide whether to iterate, scale or loop back.

Best Practices

• Write criteria before you see results. Criteria written afterwards tend to describe the concept people already prefer.
• Test the assumption most likely to kill each concept first. Polishing a layout is wasted effort if the underlying idea fails.
• Keep rounds small and frequent. Each round should change something before the next one starts.
• Include the people who will build and run the solution. Their objections in Deliver are cheaper than their workarounds after launch.
• Record rejected options and reasons. Future teams will ask why the obvious alternative was not chosen.
• Treat a failed test as information about the problem. If every concept fails for the same reason, the problem definition may need revisiting.

Common Mistakes

• Choosing the sponsor's favourite by default: When testing is a formality, the Deliver phase adds cost without reducing risk. Agree criteria first and let test results drive the choice.
• Testing only the preferred concept: Without a comparison, you cannot tell whether a concept is good or just acceptable. Test at least two genuinely different options early on.
• Raising fidelity too soon: Polished prototypes invite comments on colour and wording and make teams reluctant to change direction. Stay rough until the core idea holds up.
• Treating dot voting as the decision: Votes reflect persuasion and group dynamics as much as evidence. Use them as input and decide against the criteria.
• Launching without measures: Without agreed measures, nobody knows whether the solution worked. Define them before release.

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
• Double Diamond Thinking: Divergent and Convergent Modes
• How to Create a Double Diamond Diagram
• Double Diamond vs Design Thinking: Choosing a Framework
• Adapting the Double Diamond UX Framework for Design Projects

Sources

• Design Council: Framework for Innovation
• Design Council: Eleven lessons, managing design in eleven global brands
• GOV.UK Service Manual: How the alpha phase works
• NN/g: Why You Only Need to Test with 5 Users
• NN/g: UX Prototypes, Low Fidelity vs. High Fidelity
• NN/g: Design Critiques
• NN/g: Dot Voting

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