Death to the double diamond
Having just recently emerged from (yet another) "messy" design process myself, this thought-provoking critique of the "double diamond" process model strikes a chord with me:
The double diamond process offers a “prescriptive” approach to real-life complex problems. It gives you specific steps to take, irrespective of the unpredictable challenges a designer often encounters. There isn’t a right way to solve a problem, especially complex ones. It’s not helpful to think of design as process of discovering, defining, ideating and delivering (or whatever version of those double diamond steps you prefer) because following those steps often does not get you closer to a solution.
Now, the double diamond model in itself, in my opinion, has a lot of merit as to describe a framework of first applying divergent thinking to explore an issue in depth and then convergent thinking by taking focused action. The author's critique, it appears (or then I am just projecting my own critique here?), is more directed towards seeing the double diamond as a blueprint for good design. Which it is not.
The article describes what is called "emergent design", and this is a process that I experience to be much more the reality in most projects I have been involved in, especially when it is outside corporate contexts with rigid process models. When design is given the freedom of a more "organic" process, the reality is just that – emergent:
An emergent design mindset takes into account the inherited complexity designers encounter in the problems they aim to solve. Emergent design is about being critically aware of the evolving situations designers find themselves in and understanding the unknowns they encounter so they can apply the right design tool for the job.
I concur that it is hard to prescribe design processes a certain model before even digging into the project. But this is a hard sell, and maybe even organizationally impossible to do in big, corporate contexts. Design, from my experience, can only be seen as a formal "process" in hindsight. While knee-deep in the work, it is all about constant reflection, adaptation, and the intuition (this is where experience comes in just as much as a multi-disciplinary background) to choose the right tool and procedure for the next step at hand. The author summarizes this thought brillantly, stating:
The key design skill is less about beautiful all-encompassing Figma documentation with all the kinds of journey maps and personas, or mastering a “process”. It’s about being so keenly situationally aware of what unknowns are in front of you so you can pick out what tools or design activities target them precisely.
This "process of muddling through" is what I enjoy so much about design work …and what is so hard to explain to others who would just love for design to be this clinically clean problem-solution-continuum process models like the double diamond promise.
I posted about another recent take about "breaking up the double diamond" a few weeks ago:
No Handoff: close the gap between product and engineering
Always curious about improving design processes to put user needs over a rigid process – and even more so if the alternatives are prototype-centred – the "No Handoff" method presented by Shamsi Brinn is an interesting amalgamation of a broken-up double diamond and agile processes:
Collaboration is the biggest challenge for any project. We have deeply entrenched ideas about disciplines, roles, and hierarchies to overcome. No Handoff is simple… but not easy.
No Handoff closes the space between product and engineering teams by iterating as a team. The grounding principles are:
- Foreground user needs as our northstar
- Iterate together, and
- Prototyping is key
Rather than pouring energy and resources into documentation, Figma mockups and the like (the author also has written about reasons to drop Figma), the whole team iterates together on a prototype that enables exchange, evaluation and iteration:
Software development has long matured far beyond bringing flat visuals to life, and discovery and design need to share the process of iteration. Prototyping is the catalyst for product and engineering to truly become one team, and move beyond project handoff. Eliminating handoff and iterating together is more efficient, enjoyable, and user focused… and much less risky.
All this stunningly resembles a recent project of mine, so reading about this formalized approach to such process afterwards is fascinating.
…and earlier this year, I encountered this article, looking at how the prescriptive understanding of design as a process is largely rooted in justifying its value to other functions in an organisation:
Design is not a formula, it’s an odyssey: replacing the Double Diamond
The ultimate reason why these methods of Design Process, Design Thinking, and Design Doing have been so over-defined is rooted in a need to help legitimize Design amongst other functions, departments, and domains within Companies.