Is the Double Diamond Design Model Still Relevant? In today’s world where code can be pushed multiple times a day, and prototypes quickly tested, the rigid phases of the Double Diamond can feel constraining. The model’s omission of execution for three-quarters of the process could create significant risk. Do you think is it time to reconsider this design approach?

2.3k viewscircle icon1 Comment
Sort by:
Director of IT in Finance (non-banking)2 years ago

The Double Diamond approach is absolutely still relevant. It just shouldn't be considered as rigid or universal!

The idea that, when exploring and delivering new capabilities, products or services, we should first creatively explore the range of potential problems, opportunities and approaches before narrowing our focus to those we can most usefully address; and then look creatively at the available solution and implementation paths before zeroing in on what we will implement is a powerful one.  It encourages us to be creative and expansive so that we find the right problem but also to be focused and analytical in working out how to address - but not at the same time!

This general approach is just as applicable to a small change that might be implemented in a few days as it is to a major change project that runs for many months. Even in small cases, if I don't think creatively about the problem before I focus on the solution, what will I end up implementing?  Potentially, it will be the solution that I (or someone first thought of) that may solve the wrong problem.

Addressing the point in the question about the ability to implement IT change multiple times a day: Yes, new features can be deployed frequently but they don't each represent a new business problem, idea or solution.  They are more likely to be a stream of features (or fixes) that progressively implement the solution that has been chosen as the response to a particular opportunity. In the terms of the Double Diamond, they allow the final, narrowing stage of the process to be implemented incrementally and iteratively rather than in a single "launch".

(I could make the same points about almost any framework or methodology that helps businesses put some structure around their processes: It's a valuable guide but if considered as a rigid recipe that must be followed exactly in all cases, it will fail in many or even most situations.)  

Content you might like

Cloud-based solutions 19%

Modular and microservices architecture 56%

Data virtualization 38%

API-driven integration 56%

Containerization (e.g., docker, kubernetes) 56%

Schema-on-read approaches 19%

Automated data management tasks 19%

Prioritize interoperability and standards 6%

Real-time data processing 6%

View Results

Budget allocation13%

Potential process improvements67%

Onboarding & training bandwidth8%

Security & compliance8%

Reviewing prior purchase overlap2%

View Results