Leon Gauhman, Co-Founder & Chief Product and Strategy Officer, Elsewhen
Making software is one of the most complex activities that we humans engage in. It takes countless hours of work, thousands of lines of code, and collaborations between many different people, from many different disciplines, with many different points of view. Making a great product involves strategy, tactics, data, empathy, communication and a little bit of luck.
As an industry, the most important thing we’ve ever learned is that the best way to de-risk is to stop talking, and start shipping. In the words of Jason Fried, “If you want to feel good, brainstorm it. If you want to appear good, test it. If you want to know if you’re any good, ship it”.
The Double Diamond design model was invented back in 2005. A lot has happened in the software industry since then, and so the question is: how is something that was dreamed up in 2005 still relevant today? And why are consulting companies still pushing this outdated model?
What is it?
In 2005, the British Design Council conducted research on design processes in global organisations, including some of the most forward thinking companies at the time such as Microsoft, British Telecoms and Yahoo. The conclusion? These companies’ design processes could be neatly described in one simple schematic:
“Divided into four distinct phases, Discover, Define, Develop and Deliver, the Double Diamond maps the divergent and convergent stages of the design process, showing the different modes of thinking that designers use”
Neat, how does it work?
The first quarter of the double diamond model marks the start of a project. This is the phase where user needs are identified and described, market research is conducted, and consultancy partners help to shape a strategy for moving forward. Anyone in the industry will already know that this can be a very time consuming process. With almost anthropological zest, researchers will go into the field and eagerly study their subjects, emerging with findings that will be used to shape the rest of the project.
The second quarter of the double diamond model represents the definition stage, i.e. the ‘big idea’ phase. With the findings in hand, a consultant will fire up the excel sheets and start Googling. The project scope will be signed off, and a brief will be put together. The outcomes of this stage are well documented and passed on to designers to do some thinking.
The third quarter of this model marks a period where design-led solutions are developed, iterated and tested. Prototyping and experimenting is encouraged, as is iteration on the design solution. At this stage it’s pretty likely that a few analysts will get taken into a room and asked to predict if a developer can build some basket of features in X amount of weeks.
The final quarter of the double diamond represents the delivery stage — where the majority of the work gets done. In some cases, especially with software companies, this is the point where a project is packed into an Agile delivery, based on tight specifications. Build and launch: the easy part, right?
Wrong
This is a very linear, ‘pass on the grenade to the next team to deal with the implications’ approach. Does this fit well into a Gantt chart? I think it does.
The majority of the companies mentioned in the Design Council’s report are manufacturers. It can be argued that the software industry was still in its infancy in 2007 (and in many ways it still is), when Web 2.0 was just raising its head, as were companies like The Facebook and Flickr. Given that this technological territory was so new at the time, it’s not surprising that a lot of the processes used to approach it were inspired by the way things were done in manufacturing.
For the last 11 years, we in the software industry have understood that meeting market assumptions is the most important signifier for a digital product. In this timespan, technology has quickly developed to support much more efficient software development paradigms compared to that of the Double Diamond. This outmoded model doesn’t reflect any of these developments, understandably, because these archetypes just didn’t exist in 2007.
It imposes rigidity
The Double Diamond puts executing and delivering software to the back of the queue — a ‘don’t let the engineers ruin the dream’ type of thing. Nothing says ‘don’t worry, someone will build it’ like that last, boring delivery quadrant. Meanwhile the model also implies that the important work is clearly in the hundreds of (billable) hours devoted to deep thinking about what’s to be done and why.
Consultants love to plan. De-risking is done by planning, and modeling predicts success. By this logic execution is just a follow up process; an assembly line task for the code monkeys in the bigger process of ‘prepare for sign off, sign off, execute.’ The problem is that this unrealistic approach attempts to fix a definitive structure with a rigid framework, when what’s actually at stake is a highly complex and chaotic activity.
Agile and Lean exist because we failed to adapt to the fluid reality of finding problem-market fit. What actually works better is just accepting the nebulous uncertainty of software design, and preparing to deal with rapid change.
It fragments
The separation of disciplines (strategy, design, product, tech) over a linear path of handovers produces poor results, because theorising a solution for so long without putting something in users’ hands leaves too much opportunity for describing a castle in the sky. It’s simply not needed.
Omitting execution for three quarters of the process is wasteful and creates enormous risk. What happens if you were wrong and it turns out that actually, something doesn’t need to be built? Or it can be built differently? Maybe it takes 3x as long to build compared to what you originally thought, and perhaps it ends up not providing any real value at all. Why not validate those assumptions on a much tighter decision loop, and adjust your strategy to reflect the learning?
Coming to terms with the forces of change is something that everyone in software development has to do. It’s the reason that Agile exists, be that Scrum, Kanban or whatever interpretation of that works for your organisation. The Double Diamond model has a very limited scope to propagate change throughout the entire process chain. In organisations that use it, the Agile mindset starts only in the fourth quadrant, leaving virtually no scope for a product to pivot. A digital product that can’t pivot can’t change and learn from meeting the customers. Inevitably, a digital product that doesn’t learn from customers, dies.
It doesn’t compare
Sophisticated, cross-disciplinary teams can go from whiteboard, to prototype, to live product, fast. Small, experienced teams using modern infrastructure, design systems and prototyping tools can work on all elements of the proposition at once, using data to discard what bombs and amplify what works. These days we can cheaply throw away and redo, quickly and at-scale, as a response to the live data our customers give us. With the Double Diamond model, you just can’t.
Learnings from qualitative and quantitative feedback loops are actioned exponentially faster than the Double Diamond suggests. Where is the Pivot in this model? And how do you Pivot your solution once the product’s out there? No first solution ever survives the market.
So what’s the Double Diamond good for?
13 years has passed since this model was made. The world has moved on. When it comes to the design process, we know that design is important, and we know that innovation is important. We’re on the edge of creating artificial intelligence on a distributed ledger! We can afford to work in a more sophisticated way now. This means using an approach that takes into account the technological, economical and cultural shifts of the last decade, even in a corporate environment (remember, GAFAs are huge corporates too).
Admittedly, the Double Diamond isn’t all bad. As a visual model it’s great at describing the expanding and collapsing nature of coming up with ideas: start by thinking about loads of ways to solve a problem, then eliminate the solutions that don’t work, and focus on the solution that does. Expand, contract, expand, contract, rinse and repeat. Design Sprints or other Lean processes follow this rhythm too, and any group exploration activity should follow that beat.
The results are in.
The Double Diamond design model is old and self indulgent. It doesn’t take into account how we as an industry have evolved over the last 10 years, or what executing a digital product is actually like in real life, in the wild. Just look at companies like Spotify, Facebook and Intercom who are far more adaptable and agile.
In 2018, in a world where you can push code 10 times a day to your customers, pull a prototype together in a day and put it in front of users, all this theorising is irresponsible. If you want to emulate a modern tech company and compete with startups, you won’t achieve that by following a decade-old manufacturing inspired paradigm. You’ll do it by embracing the uncertainty, and preparing for change.
Originally posted here.