Who killed the double-diamond?

The double-diamond design process model has been a mainstay of UX practice for some time. While some folks have been questioning or challenging it, it has held up reasonably well as a tool to communicate some of the key tenants of human-centred design practice. I recently saw a post that claimed that, in the age of LLMs, the “double-diamond is dead.” I didn’t find the argument particularly convincing, but it did get me thinking.

For some while, I’ve not really been a fan of the traditional double-diamond, as it tends to be read in quite a rigid, “waterfall” like manner, which was not it’s original intent, nor—as an agile practitioner—what I would consider the best application of it in practice.

Instead, I’ve long preferred the “Diverge-Converge” model, as proposed by the National Health Service in the UK. I can’t recall exactly where or how I first came across it (it was some years ago, I think I referenced it in an academic paper in my past life). However, nowadays the best reference I can find is in the Thinking Differently (PDF, 5MB).

The Diverge-Converge model, adapted from NHS Thinking Differently.

As the NHS describe on p. 26 of the book:

A final important concept for thinking differently is another one of J. P. Guilford’s insights involving the importance of deliberately alternating between divergent and convergent thinking.

• Divergent Thinking: Expanding the list of possibilities; purposefully looking for more, or looking at the issue from a variety of directions. Divergent thinking stresses quantity of thought, imagination, long lists, and many different ways. Divergent thinking is necessary in order to challenge “the way we have always done it”. The downside of divergent thinking is that it can go on forever and we end up with lots of new ideas but never actually do anything about them.
• Convergent Thinking: Reducing the list of possibilities; purposefully looking to condense, summarise, focus or select. Convergent thinking stresses quality of thought, good judgment, short lists, and a few selected ways. Convergent thinking is a necessary prerequisite to action, and without action ideas are not valuable. The downside of convergent thinking is that we might miss a possibility, or prematurely discard one and end up being very focused on an idea, but not on the best one.

While it’s a little more complex to take in, I think this is a more useful guide as to the “mental model” that we are intending and applying as we move through the fuzzy front-end of the design process, through to actively working on solutions, through to delivery and follow-up learning.

A common criticism I’ve seen of the double-diamond is that it slows delivery, especially when the first diamond involves intensive user research or stakeholder engagement.

I think this is where the idea that LLMs are collapsing or rendering the double-diamond as less valid emerges from. The argument goes that the risk of building is far less nowadays, so therefore the value of the Discover and Define component of the diamond is lessened.

But to me that misses what I see as the point of the Discover and Define component of that process, which is more about the application of Divergent and Convergent thinking. Divergent thinking reframes the problem. It doesn’t just derisk it—it provides an opportunity to find alternative pathways that design-out the problem, or to innovate in how we approach the solution space. (Jane Fulton Suri and Suzanne Gibbs Howard also highlight this approach in their paper, Going Deeper, Seeing Further, which unfortunately doesn’t seem to be available online anymore.)

While this process benefits from user- and stakeholder engagement, to be sure, it’s not necessary to gain value from this process.

I recall one particular example of this from my time at Wattwatchers. I was jamming ideas with my dear friend, colleague, and all ‘round amazing human Adriaan, for the “Flow” feature of the MyEnergy smartphone app.

We took a step back, and were looking at the problem from a different altitude. We started thinking about the problem as “how might we enable a conversation with your energy usage.” When we reviewed the resulting solution that came out of the “converge” step, we had actually responded to (if not resolved) multiple issues that we were grappling with at the time—around how we introduced new features in beta, about how we engaged partner organisations, around how people received alerts relating to their energy usage, and more.

This is part of the process where LLMs can contribute, to an extent—perhaps as a “sparring partner” or in synthesising ideas from across knowledge domains. But they certainly are incapable of doing it on their own, in my experience.

Another place where LLMs provide benefit is in increasing the number of options you can realistically produce and test in the “A few prototypes to test”—especially for digital products. The cost of creating a “throw-away” prototype, where code quality and maintainability is far less a factor, makes it much easier to get a higher fidelity, or more of them, to test with end users and stakeholders.

They also offer the opportunity to rapidly iterate the prototype in response to findings. For example, if you present a prototype to a few test participants, and a glaring issue emerges, you may be able to adapt the prototype in the space of a few minutes or hours, to address the issue and take advantage of further tests to evaluate the effectiveness of the adjustments.

Against this model—which confusingly is also depicted using diamonds!—I believe LLMs can assist, but certainly don’t replace, the process and the way of thinking.