Understand the Double Diamond design process, what happens in each phase, and how solving the right problem differs from building a solution that works well.
We used the Double Diamond at the web design agency where I worked. What I like about it is that it makes room for a question that is easy to skip: are we working on something that actually needs solving? I like making things work. Fixing a broken interaction, shipping a feature, or getting a dashboard to show the right numbers is satisfying. But choosing what to work on deserves just as much attention.
Digital analyst and developer helping teams turn unreliable measurement into evidence they can use.
Imagine a team looking at a website's contact form. People start filling it in, then leave. Someone suggests a redesign. Fewer fields, a clearer button, maybe a nicer layout. All reasonable ideas. But what if visitors leave because they cannot tell how much the service costs? You could build a lovely form and still leave their main question unanswered. This is a hypothetical example, but it captures why the design process matters to me.
The Design Council's Double Diamond describes four phases: Discover, Define, Develop, and Deliver. The first diamond explores the problem and narrows it into a clear challenge. The second explores possible solutions and narrows them through testing. Each diamond opens up, then closes down. Exploring options is called divergent thinking; choosing a direction is called convergent thinking. The Framework for Innovation explains this movement between exploration and focus.
Discovery means learning about the people affected by a problem before settling on an explanation. In our contact-form example, I would start by checking whether the tracking works. An apparent drop-off is not much of a foundation if the submission event is broken. Then I would examine where people leave, compare devices, and look for technical errors. Those checks tell us where to investigate. They cannot tell us everything a visitor is thinking.
This is where interviews, observation, and conversations with the people handling enquiries can help. Ask someone to walk through the page and explain what they expect to happen. What information are they looking for? What makes them hesitate? Suppose visitors keep asking whether an enquiry commits them to buying anything. That gives us a different lead from “the button needs to stand out.” I would keep both the observations and the unanswered questions. At this point, the useful output is evidence about the situation, with room for competing explanations.
Definition means turning what you learned into a focused challenge. Typical activities include grouping interview notes, comparing those themes with behavioural data, mapping the user's journey, and deciding which need to address first. For our hypothetical website, suppose the evidence points towards uncertainty about price and what happens after submitting an enquiry. “Redesign the form” would lock us into a particular answer too early.
A more useful problem statement would be: “Potential customers need to understand the likely cost and the next step before they feel comfortable contacting us.” Now we can discuss what improvement would look like. Can visitors explain what happens after submission? Can they find enough pricing information to decide whether the service suits them? We might also track completed, relevant enquiries. I would choose those criteria before testing a solution. Otherwise, it is tempting to call any increase in clicks a success, even when it tells us little about whether we helped anyone.
Development explores different ways to address the defined problem. Common activities include sketching ideas, working through them with users and colleagues, and making rough prototypes. The important part for me is giving alternatives a fair chance before polishing a favourite. For our website, options could include a pricing range near the form, a short explanation of the enquiry process, or a way to book an initial conversation. These options address the same uncertainty in different ways.
I would start with simple versions that people can react to. A sketch or clickable mock-up may be enough to test whether the explanation makes sense. Ask visitors what they believe will happen next, rather than only whether they like the page. Bring in the people who will deliver the service, too. A promise of a quick response is only useful if somebody can fulfil it. The output is a set of possible approaches and evidence about their strengths, weaknesses, and practical limits. A prototype is useful when it helps us make a decision.
Delivery means testing promising solutions on a small scale, dropping weak ones, and improving the ones that work. In our example, this could mean checking the revised page with users, fixing confusing wording, and verifying that the form works on mobile and with a keyboard. Before release, I would also check that submissions reach the right person and that the analytics record them correctly. The page, the tracking, and the follow-up all need to work together.
Once the change is live, we can compare what happens with the success criteria we chose earlier. Are visitors clearer about the next step? Are enquiries relevant? Are the same questions still reaching the team? An increase in submissions would be encouraging, but a simple before-and-after comparison would not prove that our change caused it. Traffic and other conditions may have changed too. I would use the available evidence to decide whether to keep, adjust, or revisit the solution. Launch gives us another opportunity to learn.
The way I remember the two diamonds is “doing the right things” and “doing things right.” I use the first phrase for choosing a problem worth solving. The second is about carrying out the solution well. You need both. A perfectly functioning form can still fail to address the reason people hesitate. Equally, identifying the right need achieves little if the resulting page is confusing or the enquiry never reaches anyone.
That distinction is a useful shorthand, rather than a strict boundary between the diamonds. Testing a solution can reveal that we misunderstood the problem. Early prototypes can help us discover what people need. The Design Council explicitly describes the process as iterative in its Framework for Innovation, with learning sometimes sending teams back to earlier work. I would use the model to keep track of what we know, what we are assuming, and which decision needs evidence next.
You do not need a huge workshop for every small change. You do need enough understanding to explain why you are making it, and a way to check whether it helped. Before opening the design tool or writing the first line of code, I would ask: what makes us confident that this is the problem worth solving? The answer can change the whole project. Thanks for reading.