Why People Keep Attacking the Double Diamond
It’s 2023 and the mini-industry of Design Thinking detractors is still getting bigger. It’s partly an effect of the limitless supply of employed-by-business people having free access to so many social media channels (i.e., so much attention) in the “psychological safety space” of competitive branded thought marketing. (Spoiler alert: we’re in one right now.)
But mostly it’s an effect of willful disinformation. Why does this willfulness prevail?
One thing is that being contradictory is now seen as a way to gain notoriety, if not popularity; and there’s an easy point of attack to get it. But another is FOMO, even if the idea not being missed out on is wrong.
I.
Here is the infamous Double Diamond Diagram that has become synonymous with Design Thinking.
Okay, no cheating. What is this actually a diagram of? In fact, what kind of diagram is it?
If you just said, without looking up anything, something like “design thinking process”, “design model”, or really, anything that includes the word “design”, you failed.
What you’re looking at is a Value Development Model for a Solution. Six words.
Relax, it’s okay to default to the Fewest Words Possible mandate, so that makes it “Solution Value Development Model”... which is convenient in business or competition because, well, Value Management.
II.
Here’s a thought: let’s use up a lot of effort over a lot of time to produce something we’ll call a “solution” that turns out to not be valuable. Here’s another thought: let’s NOT. The model is used to help manage the development of the production’s (i.e. solution’s) value.
The first interesting thing about the diagram, then, is that if no one cares about the production’s value, then no one needs the model. You can just do all the stuff you were going to do, for some other reason. Your production might develop something other than value.
Second: the diagram is not identifying a process. Despite the Western bias of left-to-right forwarding, the diagram does not iterate a process. What makes any dynamic a “process” is that it can be described as elements that are repeatedly identifiable, in causal associations that are repeatedly identifiable, in a named set of interactions. You can recognize something as a process even if you can’t prescribe it. Additionally, a “process” can be continuous without ever progressing. This is also a good time to point out that a “process” is not by definition something that is linear, and for that matter, despite being describable, it may not even be something that is necessarily familiar or even understandable. It’s just recurringly observable per description. And finally, if there is a process that is even just echoed strongly in the diagram, that process is not Design; it’s Fulfillment. Require, specify, source, ship.
III.
Instead, to stay on topic, the diagram is identifying states that represent degrees of effective progression towards a target value. (Short Attention Span allows us to just say “progress” here, but does that abbreviation make the diagram clearer? No. It just makes your boss more comfortable about your grip on things. Forget that! Be your own boss!)
There’s nothing in the diagram that actually informs processes other than to call out multiple interesting beneficial states that might be reached by using one or more processes. Unfortunately, those states — objectives that are under management — are labelled as verbs (i.e. “discover”) rather than as adjectives (“discovered”).
Given that the whole thing is about winding up with someone’s receipt of a solution, the salient value logic already here should have been labelled (left to right) WHY, WHAT, HOW, and WHERE . From the outset, the context of the value is a “problem”, and the vector of the diagram is contingency, identifying that one state — e.g. discovered — is logically prerequisite to another state — e.g. defined — whether or not you ever realize a subsequent state, much less a solution. Nothing in the diagram expresses the notion that you can’t stay in one state indefinitely or can’t keep coming back to it. It only says that at least three of the states each need the support of something else that already exists.
In retrospect, a vertical diagram stacking the four states would have been less likely to get mauled by anyone who at least understood why the building that they lived in stands up. Each lower level satisfied requirements made on it by the level above it.
[RECIPIENT]
DELIVERED
DEVELOPED
DEFINED
DISCOVERED
The rest of the diagram identifies one function four times, namely, issuing an FYI: “Typically, to get from here to there, your scope of effort is going to get wider or narrower”.
Such a simple diagram is so useful.
For one thing, if you’re asked what the point is of what you’re doing “here”, you can see that your answer should be I’m trying to get closer to “there”. For another, it’s a logical checklist. If the state you’re in isn’t so promising, back up and do more prep.
But also, people who are working on different things, but that may have inter-dependencies, can use it to talk to each other in a consistent way about status. That conversation — a Why What How When talk — helps to avoid the situation in which something being produced by one party winds up not being valuable enough to the other party that receives it.
So, in a nutshell, used as guidance, it links discretion to accountability. The diagram is of a model that parties can use in common to communicate about what’s being done and why.
IV.
A model demonstrates specified relationships of selected components that express hypothetically “how something will work” and in that way “why something should work”. The work here is to manage a progressive development of value in production of a solution.
Developing a solution’s value is obviously part of a value management practice, and who doesn’t want that? Practice models — especially “Best Practice” models — are not new, and nothing has made them obsolete. The idea of “best” does continually come under pressure from current reality, as it should.
Taking that all into consideration, there are differing answers for why some people try to change, discredit, or reposition the model.
- One is because they have an agenda that the model doesn’t try to promote, but they know you’re already paying attention to the model, so the bait-n-switch is easy.
- For someone who “identifies as” a designer, it may be frustrating to be told that the model is about design when it isn’t, and one impulse is to “correct” the model so that it is about design.
- But even people who really like the double diamond as is frequently misrepresent it, because they don’t know it’s a model but under pressure they feel like they can use it prescriptively as a framework, process or method for something without being challenged for doing it, and they expect to get credit for doing that.
But, given all that, with the next double diamond riff you run across, if it doesn’t start talking about value really early on, just walk away. Make that decision part of your knowledge management pertaining to managing change.
