The double diamond process

A nifty depiction of a design process is the double diamond. I have found it useful for clarifying the intent of product development activities, and the purpose of various design tools. The process was originally developed in 2005 by The Design Council in UK (sources one and two), but many design companies have their own version of it (examples one, two, three, and four).


Even if details vary, one thing is constant in every version of the process: alternating phases of convergent or divergent thinking. In other words, expanding the number of options followed by collapsing them. It is important to understand what phase of the process we are in.

Here is my version that I like to use when illustrating the place of user insight and design when discussing product or service development. (Incidentally, it is precisely this thing that is missing from software development that results in poor IT-systems. But that is another blog post.)

(Please note that the double diamond is a concept of a process, not a flow-chart or activity diagram with detailed steps to follow. Design is messy and always filled with iterations and all kinds of feedback loops everywhere. They are just omitted for clarity.)

The idea of this process is to find a problem worth solving and to develop a solution to it. It starts by collecting and capturing user/customer insight by various means, such as talking with users over coffee or more sophisticated methods like contextual inquiry or co-design. In any case it boils down to interaction with potential users and customers.

After a pile of information has been gathered, some sense needs to be made out of it by analysing and synthesising it. Again tools can vary from an informal chat between designers to a an affinity diagram session spanning weeks. The end result is condensed and captured into some form of key insights or identified problems. This can be in the form of  a story-board, a narrative, drama, or one of those agile user stories, depending on the situation.

Now that a problem or problems has been discovered, understood and selected is the time to move to solution space and start creating ideas for solutions. Perhaps a solution is obvious, or perhaps some technique like brainstorming or something more wacky is needed. The next step is to evaluate all those ideas in terms of feasibility, usability, and whether they actually do solve the problem or not. Various tools and methods can be used here, but in the end it boils down to some kind of prototyping or experimentation.

The end result is, hopefully, a good, tested and validated design solution to a problem worth solving. The next step would be implementation, whether that means building a new service, manufacturing a product, or writing some software.