A few weeks ago, Jonathan Courtney published “User research is overrated”, advocating in favour of the design sprint as a replacement for heavy upfront user research. The article got quite a bit of pickup and reaction (rightly and unsurprisingly, given the directness of the challenge to those who’ve spent years developing the approaches that have made research the robust discipline it is today).

Summing up that response, Erika Hall* wrote “Design sprints are snake-oil” which, despite the headline, is a pretty balanced and measured argument about the limits of the design sprint as an approach.

FIGHT!

I’m calling this one a draw.

Clearly it’s possible to spend too much time researching and not enough time making things for people to respond to.

Clearly it’s also possible to find challenges that are too big for a week long sprint (or, sometimes, any approach whatsoever). You won’t have to go far to find similar arguments about brainstorms, workshops and Hack Days.

But I also think this fight is happening on the wrong turf.

Sprints are an obvious thing to try for a product team/organisation looking for a breakthrough as they tackle a difficult challenge. But in most respects, they do what the team should be doing anyway – understanding users, creating things for them to respond to, making them better based on feedback.

Where sprints are REALLY interesting is when they’re applied to different types of challenge – strategic thinking, reimagining existing products, services and organisations, to planning marketing activity and campaign development.

They’re REALLY interesting when applied in different environments – in organisations who aren’t set up to work in collaborative, agile, iterative ways, but who understand the potential benefits and want to explore a new way of working.

They’re REALLY interesting when used to spark something new, to get everyone sharing their experiences and ideas, to use the wisdom of being set within an organisation to understand the limits and opportunities it offers, to get alignment on a possible solution and to work together to see if it really, actually, works.

Where sprints are REALLY interesting, is when they help organisations reduce the risk of trying something new, and don’t pre-judge what the outcome will be.

Which brings me to this tweet by Andy Budd.

His company, Clearleft, are a great digital agency and have been for a long time. But if you hire them you do so knowing what you’re getting – a very well crafted website or app and some thoughtful ideas for changing your organisation’s workflow to create content for it (maybe I’m wrong on this, it seems like it’s a perception that their recent rebrand sets out to try and change).

As a client, you’re committing to a large project that likely originates with a brief and a multi-agency pitch, has a sizeable fixed budget and a set of stakeholders who are expecting to see an outcome at a set date in the future.

Given all that, you have to be very sure that’s the right thing before you commit.

Use sprints to reduce the risk of committing to the wrong thing. Use them to think for yourselves, to understand some of the needs and challenges of your users and how to best use your organisation’s resources to meet them. Then call in the consultants and agencies once you’re happy enough with where you want to go (we can help with that, needs be).

With the battle over and the pugilists bloodied and bruised, what have we learned?

  1. Fighting is bad.
  2. Yes, sprints have their limits (limits that we at The Shop try to remain honest about) but equally, done right, they’re a quick, cheap, accurate and REALLY interesting way of moving forward.
  3. There are lots of ways of doing things.
  4. There are surprisingly few old Batman gifs.

——————–

*Erika wrote a wonderful book that really helps with understanding the purpose and limits of research, techniques to use and important questions to ask. It’s required reading. Buy it.