Design Sprints are fast-moving product creation processes whose speed and agility is as flawed as it is innovative.
The Design Sprint is one of many methods and approaches designed to fast-track product development or service design. It evolved out of work at Google and is designed to speed up the idea development and exploration process. As the founders state:
Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, you’ll get clear data from a realistic prototype.
The basic premise is that ‘sprints’ are set up over the course of a five-day workweek and repeated for as many weeks as necessary until the generation of a workable, launch-friendly prototype is ready. It’s straightforward, it’s fast-moving, it comes from the tech sector (that know how to generate many products, quickly) and it’s simple enough to fit into an easy-to-access book. All good, right?
Right Solution, Wrong Problem
Service designer Kevin Richard has written a thoughtful critique of the Design Sprint that is well-worth the read. Rather than repeat his arguments, let me just integrate his with my own and say that one of the biggest issues with the Design Sprint are the flawed assumptions built from speed.
Silicon Valley and the tech sector has a love of speed and disruption to a level that is almost cartoon-like (think: “Move fast and break things” from the early days of Facebook). But as innovation and tech consultant Greg Satell has written, that mantra doesn’t work any more.
Software and hardware development are largely engineering problems with a human face. When approached as such we find that the human element — their needs, culture, and preferences — are secondary to the functioning of the product toward a particular goal. It’s partly for this reason that the tech sector has been so willing to embrace and even fetishize the idea of failure. When your product or service has a specific, pre-determined goal that is not tied to the user, you set up a clear line between performance and outcome: thus, you can ‘fail’.
Human lives are not like that. Our goals in life are mostly dynamic, poorly defined, and responsive to the situation. They aren’t manufactured because humans are complex. We are influenced by our biology, psychology, and social life in ways that are rational, irrational, emotional and tied to status and prestige (a social metric) as much as functional accomplishment. On top of that, each of us is influenced by a different mix of these things that is susceptible to change over time.
This is one of the reasons why Design Sprints are poorly suited to many of the design challenges facing human services and systems.
Built for Speed, Not Humans
Another issue with the Design Sprint — and Agile and similar rapid ‘innovation’ models of design — is that they are built for speed, not humans. Technical challenges are ones that can be prototyped, tested, modeled and understood within limits reasonably well in compressed situations. If errors emerge even after launch, they can be repaired on-the-fly.
These do not work well when we are looking to design for human complexity. As COVID-19 and the related sequalae of it’s effects have laid as bare as anything: the interconnections between different human systems — economic, social, health, environmental, political and more — are nearly impossible to compartmentalize and address independently.
Mark Zuckerberg from Facebook recently decided that the platform would ban Holocaust denial postings and choose to direct searches for such material to sources that had some credible evidence. His rationale was his thinking on the matter had evolved. Keep in mind that this ‘evolution’ has come after Facebook has been implicated as a facilitator of anti-Semitic screeds and promoter (through ad-sales) of ‘white genocide’ hate groups for years.
That is not moving fast, but it certainly is about breaking things.
Zuckerberg’s evolution in thinking is human speed at its worst and illustrates the complexity of human institutions, settings, values, and behaviour that requires a level of consideration well beyond the 5-day sprint or the models of research that they embody. Just as we’ve seen with election interference, anti-Jewish or Muslim hate speech, or the amplification of fake news, much of what’s happened through social media could have been anticipated had they done the research in advance. But just we’ve seen with Facebook, Design Sprints bring in users at the end.
As Kevin Richard points out, this creates ‘solutions’ that are almost designed to fail:
we can easily see the bias here: you give people a solution that has been devised from assumptions. By doing so, you create a precedent, meaning that your solution becomes the reference, therefore framing any further discussion with them. This puts your solution at risk, by potentially hiding major flaws in your assumptions and/or misalignments with users’ needs and context. If you seek validation only, you just created the perfect conditions to get what you want 👉 see confirmation bias, observer-expectancy effect, and the law of the instrument.
Rapid innovation has never been more necessary. The compounded, complex challenges facing us are enormous and pressing. They require nimble approaches to thinking, design, and action. They also require a level of human-centred engagement and consideration that necessitate models of design that might incorporate the spirit of the sprint, but are focused on the marathon of human life.
This involves methods and approaches that recognize urgency, involves human-centred research, and incorporates sensemaking and reflection into the very body of the design. Humans exist in human systems, we need design considerations that recognize that.
Otherwise, we’ll sprint to the wrong finish line.
If this is a problem you’re facing — good human service and systems design and research, sensemaking, and responsible development — contact me and let’s talk. There is an art and science to doing this and doing it well.