Design Sprints vs. the Double Diamond process model (2016 vs. 2005)
Guest Contribution
The British Design Council developed the Double Diamond model in 2005. It is still a good conceptual tool for understanding and talking about creative processes, user-centered design, and wicked problems. But the world has changed since 2005. The design field has accomplished a lot of things since then, not least of which is the Google Ventures Design Sprint. I was curious how design sprints would complement and alter the Double Diamond model. This brief article is an exploration and clarification of that idea.
Pictured above is the BDC’s DD model (incidentally, do also check out Dan Nessler’s article on his revised DD model). The model basically conceptualises a creative process as problem discovery, problem definition, concept development and delivering a tested solution.
Enter Google Ventures design sprints, which has at its core a very simple idea: “what if we took a shortcut and went straight to learning if our idea is desirable? What if we could learn about this without actually building or delivering anything?”
In a design sprint you run a short, 1-week learning loop where you build pretotypes and test them with users. There is only one goal: to learn about your ideas, design concept, assumptions, questions…
Now obviously the process you follow in the Double Diamond way of thinking is also about learning?—?but on a larger time scale! The short turnaround time of design sprints is one of the reasons it is such a potent tool: you rapidly gain feedback and learn, which lets you make decisions and stay agile!
As the model above hopefully shows, the initial discover + define stages result in a number of insights / decisions regarding areas to focus on. These are based on user research, which is good! But we still need to learn whether we have made good decisions?—?design sprints allow us to do this.
At this point you might ask “why should we need to complicate a perfectly good and simple model?”. Such a question would lead me to two shortcomings of the Double Diamond model: 1) it doesn’t account for time spent (i.e. cost), 2) it doesn’t show how or when risk is reduced. Both are pretty obvious parameters in a development process. You might even say risk and cost reduction is the entire point of following a structured design process. You do it, because you want to avoid screwing up and building something nobody wants, right?. Below is an augmented visualisation including time and risk:
In the visualisation above, I have indicated that user research does lower risk?—?but by how much? In my view, you still need to test your decisions to know if you actually made the right ones.
This, again, leads me to my next and final point: by fusing the DD model with Design Sprints, it is possible to reach a greater risk reduction earlier in the process, with less time spent. Design Sprints alone, however, could be seen as somewhat lacking with regards to user research. As such, combining the two approaches could be a rational move in a fast-paced world.
Thanks for reading! I hope you got something out of this, and I would love to discuss it further if you have anything to add or criticise.
Design Sprints vs. the Double Diamond process model (2016 vs. 2005) was originally published in Prototyping: From UX to Front End on Medium, where people are continuing the conversation by highlighting and responding to this story.
Powered by WPeMatico
