I spoke at Design Thinking London last week, on the topic of design sprints. When Carmen first asked me to speak, I wasn’t sure if I wanted to talk. If there is something the world wasn’t short of, it's content about design sprints; how tos, success stories, what to do and what not to do, yadda yadda yadda.

So I decided to get personal. I chose to reflect on my journey with design sprints; not war stories from the frontline, but personally as a designer and business owner - what had I learned from discovering design sprints, getting swept up and then falling out of love with them.

This post contains the key points and slides from this presentation.

Why am I breaking up with design sprints?

‍

Before I talk about why I am breaking up with design sprints, it's probably best to talk about how we got here in the first place. I mapped a very loose history of design sprints as I know them, along with my journey with them.

I must admit, I fell in love with the idea of design sprints, and frankly it was easy to sell to our clients. And it worked.

We have run design sprints with Channel 4, Gap, Pearson, News UK, HarperCollins and Snap Inc. (to mention a few). They were an exciting way of codifying the design process, making it appealing to clients and stakeholders i.e. solve big problems in 5 days (as the subtitle on Jake Knapp's book proclaims).

We were not alone in this thinking; lots of companies have built a business selling design sprints.

$$ Design sprints are a billion dollar business $$

So here we are today, five years into our design sprint journey, we have run 20+ design sprints for 6 clients in 3 countries across publishing, education, media, retail and financial services.

And finally...

I think it's time to break up.

When I started on my design sprint journey, I always used the recipe and ingredient metaphor. Design sprints were the recipe, I could take the raw ingredients, follow the steps, put it all together and voilà, we would create something delicious.

The more times I followed the recipe, more and more I would be able to experiment, alter, iterate, add my own flavour until I became the Master Chef.

I had bought into this, but what I found was that instead of getting more and more delicious creations, I was actually getting:

Over 5 years of using design sprints, we have:

• Consistently not achieved the level of creative output that Reason demands
• Consistently not delivered the lasting impact that we set out to deliver.

I wanted to know why we were not getting the results we wanted from design sprints when so many people espouse their virtues? I decided to do some research to figure out why we were struggling.

I locked myself in a room, looked through all the old photos, retros, sketches and outcomes of all our previous design sprints.

Some pretty clear themes started to emerge... but that was just me and as we all know; what good is a test group of one?

So then I went out and spoke to experienced designers with varied backgrounds from agencies, startups, big corporates and individual consultants.

After speaking to numerous people, I was comforted to learn that it wasn't just me that was feeling this way. And in fact the same topics were coming up over and over again. I was able to distill this down to three key themes and subsequent realisations as to why I had fallen out of love with design sprints.

01 Timing

Design sprints place a massive emphasis on a single point in time. And with good reason; their claim is "solve big problems and validate ideas in 5 days".

People believe this, I believed this! We are led to assume we apply the process and in five days, we will have the answer.

For example:

“Start by taking a step back from the problem to discover, diverge and explore the full ecosystem, get to know the customers and then start to converge on a focusing question or design brief, which will guide the rest of the sprint.“

from Design Sprints, So Hot Right Now!, Bryan Hoedemaeckers

This is straight from the sprint manifesto. We are talking about some pretty big thinking here, and this all needs to be done in day one.

Designs sprints are marketed, sold, packaged and consumed as a 5-day process to fix complex problems when in fact they are not. They are small speck on a horizon line that encompasses design research through customer development through product delivery and ongoing iteration. The five days spent doing the sprint can be the result of months of preparation work.

02 The local maximum

The local maximum, reaching the glass ceiling, whatever you want to call it, happens when you set limits on what you can do. In a design sprint, the process itself can do this.

• Monday: getting people up to speed on a ‘complex problem’
• Tuesday afternoon: spent creating ideas
• Chosen and developed the solution on Wednesday
• Prototyped it on Thursday

What happens next is that some pretty big decisions are being made on based on what 3 people decided on Friday.

Have we really been able to explore the solution yet? Have we really given justice to the art of research?

Nick Bowmast puts it well here, when asking 'should we have speed cameras in design sprints?'

Yes, the process is optimised for speed. But is it optimised for results? We may have laid the tracks, set the direction and (in my opinion) applied blinkers, all for the sake of acheiving a five-day design sprint.

Because we followed the process, confirmation bias kicks in; we hear what we want to hear, pat each other on the back at end of the day on Friday: all good.

03 It's got to work

...now this I think is the important one. We have packaged something up, sold it to the executive team as the silver bullet that will solve their complex problems in a week: we have convinced them to give up their expensive time and be involved.

It really, really, really has to work.

Sure, testing was lukewarm but that's ok, that strong dose of confirmation bias kicks in again and we begin to hear what we want to hear. It is at this point I started asking myself, have I turned into this:

Our clients weren’t buying validated outcomes or human-centred designs, they were buying design sprints. They were buying the promise of ‘solving complex problems in five days’. They were buying what I had sold them. I had lost sight of what Reason promised to do: deliver lasting impact.

What I learned

Design sprints distracted me from the bigger challenge. I was substituting activities for thinking. I was taking the easy way out. I had started identifying my expertise with running design sprints rather than the intended outcome to deliver lasting change and value for our clients.

So before diving headlong into recommending design sprints, I have re-focussed our efforts. This means making sure we are focussed on questions and outcomes before we think about method.

• Are we focussed on the behaviours and practices of the customers?
• Does the team have permission to fail and to experiment?
• Is there a programme of ongoing customer development?
• Are we creating good design, not just good design sprints?

So, it wasn’t them, it was me. In the future design sprints and I might get back together, but it won’t be a monogamous relationship: we definitely need to see other people.

In closing

• I do believe design sprints can help solve hard problems.
• I also believe that design sprints can appeal to people who are looking for a silver bullet, or looking for an answer to design but don't want to do the hard work.
• No matter what your problem is, I suggest starting from a set of goals, rather than a specific method, no matter how appealing it sounds.

I am grateful that the Jake Knapp and the GV team for creating design sprints, and introducing us to a novel method. Having been on the journey, I prefer to rely on design as a practice and sprints as a process.

You can view the original slides from the presentation below

‍