The Ethics Of Design Sprint

An endeavor you are passively subscribing to.

The question is not whether it is morally acceptable to win the race. The question is ‘should we run the race in the first place?’

Hi everyone, Kevin here.

Not so long ago, I shared some thoughts about the necessity of Design Sprint. The reason is that so many are keen to “tweak” or adapt the method to their context. As I explained here, that’s totally expected because of the relationship between our tools and the context we are evolving in. And the more the context is ambiguous and complex, the stronger is this relationship: both are interrelated to our ability to act.

[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

Beyond this reality, designers’ keenness to favor the Design Sprint (DS) by almost systematically conflating it with other approaches, like say, the Design Thinking (DT), is not only proof of a form of lack of maturity, but also a good demonstration of a recurring issue in the design field: a philosophy of “acceleration” for the sake of “delivering fast”.

Surface Similarities: An Equivocation Fallacy.

Firstly, understanding the main differences between DS and DT is important to tackle our modern challenges. In short, the Design Sprint is to Design Thinking what a production line (or classic manufacturing) is to Agile development –and you’ll see how this comparison is not trivial.

Both the Design Sprint and the production line imply linearity, reductionism, optimization whereas the Design Thinking and Agile are both frameworks and philosophies. It’s about levels of abstraction.

Because of several intrinsic differences, the space for mapping, thinking, understanding (sensemaking), and acting they allow are very different. This determines your ability to:

Navigate complexity and deepen your understanding of the problem space;
Create time and space for long-lasting shared understanding (i.e. at company scale);
Open-up opportunities for diversified strategies (instead of single-point solution) –strategies are not necessarily digital products;
Favor self-organization, emergent, and platform-like thinking/behavior;
Ensure environment responsiveness/adaptiveness (non-linearity) –instead of linear and rigid;
Etc.

So, even though on the surface, it’s easy to conflate Design Thinking with Design Sprint (and a production line with Agile) because of apparent similarities, that’s as far as it goes.

This equivocation fallacy is prevalent in the tech world, because –it has to be admitted– it is way more convenient and comfortable to see problems as a one-way-to-solution while (genuinely) believing you simply “apply” Design Thinking “principles”.

If designers feel uncomfortable “using” the Design Thinking approach, that’s ironically probably because of its very nature: the process much more adapts to its reality (navigate uncertainty) –whereas the Design Sprint forces reality to fit the process (controlled environment).

Here, the analogy to Design Sprint “recipe” fits pretty well with this observation, as I covered in another article:

“Let’s extend a bit further the recipe analogy by looking at the ‘chef/cooking’ domain to see its limitations. If you ever worked with a chef, you should know that:- A chef’s kitchen is an extremely controlled environment, not an uncharted territory. In fact, it has been designed for that very purpose.
- It’s all about mastering the process. When you have dozens or hundreds of clients waiting in the restaurant, it’s no time for doubts, questions, change in plans, or improvisation.
- In a chef’s kitchen, there is no place for uncertainty or exploration. Everything has been devised and tested beforehand.
- It’s about delivering outputs at the right rhythm and in a qualitative manner.”

As you can find in the article, this reasoning implies we already know the expected result. This is a production line –just look at the fast-food industry as an extreme.

The 4 Pancakes Of Great Design
How to design in large and complex organizations.medium.com

Design Sprint’s parent philosophies: Solutionism and Productivism.

Secondly, this “acceleration” of the design process relates to the same phenomenon visible in almost every industry related to tech (but not only). The Design Sprint crystalizes this issue pretty well.

“Teams must generate ideas; Designers must deliver prototypes quickly; teams must learn fast and iterate;”

Here are the underlying imperatives (as principles) promoted by the Design Sprint. “Ideas” are not much judged on the basis of how they originated (are they properly informed), but more on how successfully they pass the so-called “reality check” –assuming the way you test properly reflects your “reality”.

Interestingly, these imperatives remind us of the Lean Startup “build→measure→learn” cycle, from which the Design Sprint clearly originates. This engineering approach to business (and design) is solution-begging, meaning that it often assumes that every problem must be answered by a defined & finite solution –hence solutionism. This is the “there is an app for that” effect.

Eric Ries himself claimed that the Lean Startup was heavily inspired, as its name suggests, by the Lean Manufacturing developed by Toyota –even though the comparison is criticized for its inconsistencies. However, we can clearly find tendencies towards reductionism, optimization, redundancy removal, efficiency, and streamlined linearity.

Toyota’s Lean Manufacturing is, in many ways, a concrete example of productivistic ideals of the manufacturing era, still ongoing today. The very same tendencies that have put most countries at risk in the face of the pandemic. Why? Because the world isn’t linear, and our societal challenges are complex –i.e. redundancies have their place in such context.

To simplify, the supposed “goodness” of this philosophy comes from the optimization of the production lines, impacting the production capacity and quality while reducing costs. Here, “good” means “more goods at the same price, but with reduced costs”.

Intuitively, this quality, this “goodness”, is transferred to any means toward this achievement. Mimetically any sub-part of the promise seems to inherit its quality: removing redundancies helped to achieve [the goal] therefore it is good, regardless of other consequences.

This is flawed in many ways, let alone logically, despite being intuitive and attractive.

So, the Design Sprint inherited from these philosophies as well as transposed qualities. The Lean Startup showed successes in scaling some startups fast by streamlining (software) production, reducing costs of materializing ideas in a rapid manner –whatever the idea.

“Evolution is analogous to learning cycles, indeed. But dropping a cat from a cliff, iteratively, in the hope it spontaneously develop wings –as some companies do– is not how evolution works.”

The ethics of Design Sprint is not really different: “good” means “deliver fast” from the inherited premise that it will “produce more while reducing costs”. Here, cheaper to develop ideas allow early “reality-check” –whatever this means. Any means toward this goal is assumed to be as good as the conclusion. Without being necessarily aware of it, this may certainly become an imperative moral duty for many designers.

As explained here, moral duties are deontological arguments. We do this or that because it is intrinsically good, whatever the consequences. But, could it be that what is good by Design Sprint standards aren’t for the environment we are solving problems for?

The answer is not so trivial, and it can surely approximate a good YES, it CAN and it IS. By too easily heading first at solutions before properly understanding the underlying systems, we are creating tomorrow’s problems while remaining ignorant of the systemic interactions that created the problem we were trying to “solve” in the first place.

Ethics For Designers: Important Ethical & Moral Notions
Understanding the differences between metaethics, normative ethics, deontology, and consequentialism.medium.com

“The question is not ‘can we hit, faster, more nails with our hammer?’; the question is ‘do we need a hammer in the first place?’.”

The “is-ought” problem.

Okay, so almost everything I just presented to you constitutes a moral problem: moral values, such as good and bad, are derived from descriptive qualities that have been turned into prescriptive statements.

For instance:We observe “x”;
A majority of people do “x”;
Therefore we should do “x”.

On the matter, David Hume tells us that one cannot easily derive prescriptive statements (what we ought to do) from observations of “what is” –also called positive statements– unless one is able to present arguments for what one ought to do besides the fact that this is how things are today. In other words, this is not because something is a certain way that we ought to do it this way.

Nuancing My Criticism

First, please, note that I do not aim to position this critique from a “this” vs “that” perspective. Indeed, I’m necessarily biased towards my understanding of what IS and what SHOULD, however, this piece is more an attempt for me to make sense & articulate my perspective, and spark discussion.

Secondly, in a more nuanced way, I will add that “Design Thinking” — for which it certainly seems I advocate for — is guilty of the same issues. Or, at least in most definitions and application of it. As I wrote here, there is not one single “Design Thinking”.

The Multiples Design Thinking
There is no such thing as one single true “design thinking”, and what complexity has to do with it.medium.com

Thirdly, we can observe that linearity and non-linearity are not to be opposed but are, instead, both the ends of the same continuum and, therefore, are both necessary.

Mapping the tension between two interdependent sides of the same problem.

My critique here goes against the tentatives to equivocate two notions (and what they imply) as if they were the same. This does not mean one is better, when in fact, it depends on the context.

Conclusion

Again, I’m not saying the Design Sprint is bad or that you should not use it. But, as I often say, we should know the problems and limits of our tools. The problem is that many use it in plain ignorance and that’s precisely my point here.

Design Sprint is solution-begging and heavily framed for tech solutionism. The answer (almost) lies in the question, like a beautiful example of circular reasoning. But, to be fair, I am not saying that you can not “produce” something else with it, even though it is almost always implied as such. Neither am I implying that Design Thinking is exempt from any problems, misuses, or ethical issues.

Linear approaches taken into a larger systemic approach do make sense.

However, I do say that we must deeply think –not just talk, share, sell– about the “How” we do design, else who will?

And please, mind that criticizing a trendy tool is indeed a good (excuse?) opportunity to reflect on certain interesting patterns, aspects, and issues of the field.

Finally, the “is-ought” problem is an invitation to build strong(er) arguments for the moral imperative implied by the Design Sprint. What are yours?

What makes it “good” in your context? Are there any plausible or observable consequences of such behavior? Is the frame of reference necessarily “us” (we designers, makers, innovators, etc.) or is it the context we are working in?

BTW, if you want to read a good criticism of Design Thinking, I invite you to read this post by GK VanPatter from Humantific on LinkedIn.

Truth or Fiction?
Hello again Humantific readers. Happy to be alive and posting here while we are all in the Covid storm.www.linkedin.com

Thanks for reading!
What are your thoughts about this?