Design sprints in themselves are not new, developed by Google Ventures in 2010 as a way for them to quickly developing ideas internally; but the processes they incorporate date back much further, and are actually fairly common principles found in any project process – the discovery of a problem, the creation of a solution and the testing of that solution when built. Indeed, a design sprint is broken down into five key stages, which handily (and not accidentally) cover a working week:

1. Discovery and identification of ‘the problem’
2. Initial ideas around solutions to ‘the problem’
3. The decision around the solution, and the creation of assets that will help you deliver it (sitemaps, journeys etc)
4. The building of something to test
5. The process of testing the solution

Where a design sprint differs from a more traditional process is that, where you might run the above stages across the development of an entire project, a design sprint will seek to break down the project into multiple smaller problems, each of which can realistically be solved over the course of a week.

By then combining multiple design sprints, you end up with a combined set of solved problems that form the basis of, and can often replace, your more traditional written specification – ready for build, all questions already answered.

So how is this different from, say, Agile sprint-based delivery?

At first glance, it’s fundamentally the same, in that you’re picking a chunk of work to do in a period of time, focusing on shippable / testable product, and reviewing it…but once you get into it, the approaches are very different.

The biggest difference by far is who is in involved – design sprints are extremely labour intensive, as representatives from the entire project team, including the client (if there is one) should be involved throughout the entire sprint.

You might think that senior stakeholders are only really involved at the beginning, to help identify the problems and requirements, and at the end, to help test the result…but it’s actually vital that they remain part of the process throughout so they can understand the journey your sprint has taken, otherwise you open yourselves up for late-stage intervention from stakeholders who have not seen why certain ideas have won out over others.

Agile sprints are also generally based on predefined user stories, with more emphasis on the definition of those stories for the complete project before you commence development; design sprints put more focus on keeping the user stories as high level as possible and letting the sprint itself identify exactly what needs to be done.

Why should I use design sprints?

Put simply, they help you focus your project into the real objectives and problems it has, and define tested solutions to those problems, quickly.

Why should I avoid using design sprints?

They require an enormous commitment of time from all involved, including your client. If you need to run multiple design sprints, and in a typical web project you almost certainly will, this can be prohibitively expensive in terms of time and cost; but without that commitment, there’s arguably no point in running them at all.

Can I use design sprints without the client being involved?

It’s worth remembering that design sprints are just another process, and the best processes are ones that can be adapted to suit your specific needs. You could, for example, run multiple design sprints internally, and then combine the outcome of those sprints on a bi-weekly or monthly basis to a deliverable for your client, who would be managed through a more traditional Agile-style process.

In such circumstances, the client is effectively just reviewing work at the end of a multi-week ‘sprint’, and you’ve used design sprints internally to make sure you’re constantly picking the right solutions to problems.

Does this work for web projects?

All too often, a delivery team will try to use a single delivery process for their entire project, and this rarely ends well. What works brilliantly for certain things will naturally crumble in other areas, and design sprints are no different.

They are a great way of answering questions quickly, but it’s worth remembering that they don’t do anything special on their own – their brilliance comes in the focus you get when you get everyone in a room for an entire week to effectively war-room a problem into a tested answer, and it’s this focus, rather than any specific process magic, that helps them be successful.

It’s entirely possible – and extremely likely in web projects – that you’ll run multiple design sprints before you get to the end of your prototyping. That’s fine – each sprint can actually inform the next, and it’s great way to ensure you get a fully tested solution to your project problems.

Just remember that design sprints are not for technical building. Of anything. Use them to define your product, then use something else for your development. Agile, waterfall, whatever works.

If you want to read more about how we can help your next project through a design sprint or to, click over on the right (or below if you’re on mobile).

Back to the blog listing