Hi Mauricio Wolff, thanks for your article.
If I understand well, your aim is to clarify what is a Design Sprint and how does it relate to agile sprints, right?
But the problem is that your definition is self-refuting, and I will show you why. First, let’s take your affirmation that:
“Design Sprint is Design Thinking in action.”
You kindly provided a definition to Design Thinking, the one from Interaction Foundation:
Design thinking is a non-linear, iterative process that seeks to understand users, challenge assumptions, redefine problems, and create innovative solutions to prototype and test.
Indeed, as you explained it right away, Design Thinking (DT) is a framework that does not prescribe any particular application. But let’s clarify first here that “not prescribing a specific method or application” does not mean that any method or application fits into the DT framework. In fact, we could exclude any application that would contradict DT’s definition.
And here is the point of contention: Design Sprint (DS) is, by its very nature, contradicting DT’s definition. Yes, Design Sprint seems to be similar to Design Thinking. As you explained it, you find similarily the same stages (which are not stages in the case of DS). And in the end, you prototype and test. But that doesn’t make it equal to DT.
Why? Because, as the definition goes, Design Thinking IS non-linear & iterative. Design Sprint, on the other hand, IS linear and non-iterative. You have to follow the process — you even have to trust it, no matter what. All the exercises lined-up (surely) make it “efficient” in a certain way but non-flexible and very much linear. DS contradicts DT’s definition by (at least) two core principles. And because of that, DS posses no stages at all (from which you can back and forth) but instead just “steps”.
And, no, repeating DS process, again and again, does not make it iterative. I could also add that DT includes user research and does far better at problem space discovery and understanding. But yes, DS does probably better at moving fast into materialization. Is it necessarily good though? …
So, saying that Design Sprint is Design Thinking is by their definitions erroneous.
Of course, we can discuss the details further if you want, but what seems “little details” are in fact not. In the meantime, I kindly invite you to read my two articles on Design Sprint 👇 and here I explain why our tools should serve our intent and not the contrary (as more and more designers are looking for problems to fit into a Design Sprint 🤷♂ 🤦♂).
A Critical Analysis Of The Design Sprint’s Argumentation
Thinking critically about what we know helps shape and improve what we’re doing & how we’re doing it.medium.com
[Brainshot] Is Design Sprint A Necessity?
Is one single tool more important than the goals it should help to achieve? Switching the center of discussion.medium.com
Anyway, thanks for sharing 👍