There seems to be a consensus among in the UX and product design industry that the Double Diamond design process, developed in 2005 by the British Design Council, is too outdated and too cumbersome. The talk around the water cooler is that Agile is the way forward and that we should distance ourselves from the Double Diamond approach for it faster, younger and hotter cousin.
There is merit to this sentiment. As our teams become leaner, our computers become faster and our software becomes smarter, we are able to design, prototype, test and iterate at such speeds that would make 2005’s head spin.
But is this reason enough to dig a grave and bury the Double Diamond, or is it still a solid foundation to build our design processes upon?
We need to do our due diligence before we make absolutes, so how does the double diamond work?
The double diamond is broken up into four quarters. The first quarter represents the start of a project and is labeled as the ‘discovery‘. This is where user needs are identified, data is gathered, market research is conducted, analysis is undertaking and the information gathered in this phase will help shape the entire project.
The second quarter is labeled ‘define‘ and is where the data gathered in the previous phase is used to define the scope of the project, which is developed into a brief for the design team and sign off for the project is attained.
The third quarter is labeled ‘design‘ and is typically where the design team will take the project scope and brief and begin creating design solutions. Wire-framing, iteration and prototyping is the name of the game here and the previously designed scope is put through its paces by a design team that understands the capabilities and limitations of a chosen platform.
The final quarter is labeled ‘deliver‘ and involves final testing, sign-off and the launching of the product.
Now that we have defined what the double diamond design process is, it seems like it would cover off all aspects of the design of a product or software, it is a tested and proven design process and appears to have a clear separation of roles and requirements.
I can see why from a business level this design process seems like the most logical approach. It is only when you get yourself in the design trenches, specifically in the tech space, that you start to notice some holes in the process.
- Rigidity
The rigidity of the design process is the first red flag you will come across. There is no wiggle room outside of the clear separation of powers with the double diamond model. The speed in which technology moves, almost daily now days, means that designers have to be multi-disciplined and constantly on our game. We have to be able to renegotiate scope as technology moves and shifts, for example: Apple decide to push out an update tomorrow that could completely kill a feature within the scope of our project, does this mean the design process has to be restarted? It’s my contention that it should not and that we should account for wild variances in the capabilities of our platforms and devices.
2. Separation
The separation that the double diamond design process invokes can be a momentum, and creativity, killer. Separating strategy, product, design and development into rigid and segmented sections, with handover being the only connecting point, yields poor results.
This separation approach does make sense for a manufacturer, which is who the British Design Council gathered their data for in the development of the double diamond design process, but does not make sense for the lean and agile teams that create some of the greatest software of our generation.
This is not to say that UXers should be developing the same products they design, as typically these require completely different skillsets and temperaments, but it does meant that by keeping strategy, product, design and development engaged through the entire design process, the outcome is simply a better product.
3. Speed
The double diamond is simply cumbersome. Now days cross-disciplinary teams will go from strategy through to prototype in a matter of days, sometimes hours, with the use of modern platforms and infrastructure. Double diamond cannot move as fast as designer can, it is heavy and has checks and balances in place that were necessary in 2005 but aren’t any longer.
Here is an example:
I have just finished a prototype in Figma and I ping my dev lead on Slack to take a look. He logs in and drops a note in Figma that a specific function cannot be done in Swift, but can be done in HTML5 and offers a solution. Since we want uniformity across devices, we redesign in this interaction in Figma.
This is a simple process that took all of 10 minutes with the help of some of the latest in design tools, however if we were to follow the Double Diamond design model – the prototype would have to be completed and it would only be during handover that this interaction issue would be picked up.
It’s not all bad news for our old friend the Double Diamond though, its principals were used to create some of the greatest software ever made and were the foundation of the Design Sprint and Lean processes. Understanding the fundamentals of it does have its place in the design community, especially regarding the divergent and convergent thinking, but we have moved past it’s rigid and slow processes.