Design sprints – what I’ve learned at the BBC

As a user experience architect at the BBC I get involved in lots of different types of design projects. This year our team has been experimenting with a way of developing ideas using a method called ‘design sprints’. Inspired by Google Ventures (and described here), we’ve been exploring how we can use this approach to develop ideas, test them, fail fast and learn lots. I’m going to share what I’ve learned from employing the method on three different types of project.

What’s a design sprint

I’m going to write more about a particular method of applying design sprints in another post. But as some context, design sprinting is a five-day process of rapidly developing and testing ideas. Each day has a distinct focus and character – the week (although if you can span a weekend this is sometimes preferable) goes like this:

Day one – Understand: define the problem space and gain a better understanding (putting day one on a Friday gives your ‘understanding’ the chance to fester, often making day two easier)

Day two – Diverge: Create ideas that address a specific challenge you’ve identified.

Day three – Converge: Focus on a particular idea. Develop it.

Day four – Prototype: Make a prototype that will allow you to test the idea with your target audience.

Day five – Test: Test. Take notes. Carry forward your insights into subsequent sprints.

That’s the theory. But I thought it was probably better to talk about the process within the context of some projects.

Project one – a homepage

Design sprints allow you to rapidly diverge and converge – make ideas, decide which are best and work out how to make them. They’re designed to create lots of ideas and shape a discussion around which ones should be prototyped and tested. They’re democratic. They’re therefore good for projects with a broad set of stakeholders. Sprinting, although gruelling, can be an inclusive design process. Your stakeholders don’t need to be involved in the actual ‘designing’, but they can be included throughout the process.

For this project we were working on ideas for a homepage for a new product. We had a pretty blank slate – but the shape of the slate was defined by some broad design principles. We used these principles to assess and vote on ideas throughout the process – they were our criteria against which we measured success.

We had a number of consecutive sprints, and focused on a different ‘How might we…’ question for each sprint. The sprint process is brilliant at generating lots of ideas to address one of these specific questions. We asked, “How might we make the homepage feel more personal”, “How might we make the homepage feel more interactive”, “How might we make the homepage feel more ‘live’”. I like the sprint process, I think it does exactly what it sets out to – introduce a process for teams to focus on a specific challenge. But when multiple sprints run one after the other it can be difficult to get the levels of divergence and convergence right.

Each sprint is pretty much made up of the classic double diamond. Days of understanding and empathising with users, then ideation and refinement are followed by a production mindset focused on getting the concepts tested. With consecutive sprints there’s a temptation to consider how we could improve or develop ideas from the last sprint – which is the wrong sort of question. We found that design sprints are very good generating ideas around a specific challenge, but that other method are more suited to thinking of products as a whole.

Project two – a new data and content proposition

For this project we produced a clearer plan at the start of the project for how the sprints would relate to each other. We still focused on a different challenge for each sprint. But we introduced a final ‘ecosystem’ sprint – which pulled ideas together and enabled us to tell a coherent story of the sprints to stakeholders. This felt like a better approach. We had the constraints that make the sprint process work, but were confident that there was time at the end of the project to consider the bigger picture. We also built a break into the sprints. This pause in the middle of the project gave us another chance to reflect and regroup.

Design sprints force you to make decisions and get your ideas in front of an actual user as quickly as possible. You only have five days, one for building a prototype. For some sprints we pushed ourselves to create highly polished prototypes, complete with plenty of content and visual design. But as we added more detail and fidelity to the prototypes, we found that it was harder to test our ideas. Additional detail distracted the user from the ideas we were testing – we’d introduced too many distractions.

At the other extreme we created extremely low fidelity wireframes to test our ideas. There’s a stage in the design sprints (day 3) when you develop the ideas into a (usually 3-stage) storyboard. This allows stakeholders and the project team to vote on the ideas to develop. We used this format to create storyboard-based prototypes that could be shared with users. It allowed us to put lots of ideas in front of the audience. But the negatives of this approach probably outweighed the positives.

Voting and limiting the team to a smaller range of ideas is a strength of the process. It forces you to focus on what matters. You only have a day to make a prototype – so you need to be disciplined enough to choose the ideas for which testing will be most valuable. Dropping the fidelity of the prototype to allow us to ‘make’ more was a false economy, as the insights we gain from the ideas was be diluted. Your prototype should be able to simulate the experience the idea is designed to generate – a storyboard isn’t an adequate simulation.

Over these two projects we refined the way we use the design sprint process and learnt a lot. We also generated plenty of ideas that after further design and refinement are making their way into finished products. Since then we’ve started to combine design sprints with some methods and thinking from Service Design. This is further helping us to get the right balance between the narrow focus of each sprint and an awareness of the big picture. I think we’ve learnt lots about how to make design sprints work for us, so I’ll be sharing insights and tips at the end of that post – who knows, thanks to the nature of the web that post might even be published as you read this.