Design Sprints at the BBC

BBC Knowledge and Learning have an incredible amount of resources for people that want to educate themselves and develop new skills. They wanted to find a way of engaging with their users in a more dynamic and sustained way — helping people to unlock their potential over a longer time. 

Livework worked with them on a series of Design sprints to help open up a world of possible approaches to their challenge.

Underneath you can read in BBC′s own words about the experience they had working with my colleagues  in our London office.

I’m Dan Ramsden, a member of the design team for BBC iWonder. I’ve recently worked on our new content format, ‘Guides’ and the homepage at bbc.co.uk/iWonder. During these projects we’ve been experimenting with ‘design sprints’, a fast and structured way of developing ideas.

Each ‘sprint’ focuses on a specific design challenge. And because ‘sprinting’ is so quick, we explore a range of ideas in a relatively short space of time. That's the theory. But like any bit of design thinking, the real insight came from trying it out and testing it in practice. Over the last year we’ve done lots of design sprints, so I wanted to share what I've learnt and how we’ve developed the process.

Where we started

Teams around the BBC have been experimenting with design sprints for a while. But a fellow BBC iWonder designer, Ryan Hussey inspired our team to try sprints after he read about the approach on the Google Ventures blog ‘The Product Design Sprint – A five-day recipe for startups’. We followed their template pretty closely when we began. We spread the stages over five days. Each day focused on a different set of techniques and aims. Our week went like this:

Each day focuses on specific type of thinking and pushes your ideas forward

Day 1 - Understand: We define the problem and get a better understanding. We start by asking lots of questions. The most important is ‘what do we want to find out over the five days’? It might seem back to front, but starting a sprint on a Friday gives us the whole day and then the weekend to reflect on the challenge and mull it over.

Day 2 - Diverge: You need lots of energy for the second step. We focus on creating as many ideas as possible that address the challenge or problem we identified during day one.

Everyone on the team gets a chance to contribute ideas and vote on which are developed

Day 3 - Converge: Whereas day two is about variety, we now start to focus on fewer ideas to take forward. We choose the best ideas to test and develop it.

Day 4 - Prototype: We make a prototype that will let us test the idea with the target audience.

We test with our prototypes

Day 5 - Test: Testing is where we learn the most about the idea and how we can improve it. We test with the audience that will eventually use the product, and invite as many of the team along as possible to take notes and gain insights that we can carry forward into subsequent sprints.

That was how we started. But as we’ve done more ‘design sprinting’ we’ve found way to adapt the process for the way we work at the BBC.

What we didn’t change

Everyone is invited

Design sprints offer a democratic way of developing ideas. It might be gruelling and intense, but sprinting can be an inclusive process. Different experts can bring their perspective to shape the way the ideas evolve – if you can use a sticky note and a pen, you’re welcome. We’ve always tried to sprint with a range of skills and disciplines. As well as designers, information architects and researchers from the design team we include editorial colleagues, product managers, engineers and testers. Everyone has a role to play and has an opportunity for their voice to be heard.

There are limits!

We’ve also embraced the idea of creative constraint when sprinting. The idea of limiting yourself to a five-step process to develop an idea is already a big constraint. But because you’re working so fast, if you wander off course you can quickly find yourself a long way from your intended destination. Establishing boundaries in which the sprint team have agreed to focus is really important. A set of design principles is one thing to refer back to as we create and evaluate ideas. The Government Digital Services Design Principles are a great example.

Who is this for?

Personas are an important tool to help set direction and guide us. Before we start sprinting, the team dedicate time to understanding the audience need. We create personas and use them throughout the process - during the week to help generate and assess ideas, and to help recruit real people to test our prototypes at the end of the sprint. For more details about personas you might like to read Scott’s post, which begins with how personas informed the design development around live coverage of events.

We create personas to describe different audience groups based on behaviours and needs

Personas are also useful for creating another tool which helps keep us focused and provides inspiration – the ‘How might we…’ question. Good ‘How might we…’ questions focus the mind, but they aren’t too restrictive. Using our personas, we adopt a point of view, or identify the most important things our audiences need. Then we ask ‘How might we…’ questions which force us to imagine products or features that will meet these needs. When we were working on the iWonder homepage 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’”. Each sprint could then focus on specific questions and kept us focussed on genuine audience needs. For more details about using this technique take a look at Standford University d.school’s ‘How might we’ method card (PDF).

Seeing the ‘big picture’

Design sprints are great at getting you to focus on smaller, specific challenges. But we found it difficult to tie sprints together. During projects that involved multiple sprints we’d found that taking a break every three sprints helped recharge our batteries and gave us a chance to reflect on our ideas, and spot opportunities to combine them. We’ve even tried adding a specific sprint at the end of a project to tie ideas together. But on certain projects it felt like there was still something missing. We wanted a more reliable process for combining ideas within and between sprints. We wanted to be able to ‘zoom out’ mid-sprint and consider the big picture so we could invent new services, rather than just some new features.

 Taking a step back to review the bigger picture

We liked the focus that sprints gave us, but also wanted a way to track and design the overall experiences we were creating. The solution came when we started to build ‘service design’ thinking into our sprint process. A service design approach helped us consider specific challenges in the context of the whole service or product. It also highlights the context and needs that a user might bring to your product. It helps you to think in terms of ecosystems – not only the ecology of a product overall, but also to describe and imagine that product in the everyday context of the audience and their needs.

Telling stories

Audience need is always at the centre of everything we do. I’ve described how we regularly use personas and user research to shape and refine our ideas as they’re developed. But the frenetic pace of a sprint puts designers under pressure, and in that situation we can find our gut instinct or some other rule of thumb takes over. Now, if we’re ever struggling to make a decision, the first place we look for guidance is the personas.

We begin each sprint by telling stories about our personas, always within the context of a central ‘How might we’ question. These stories help us to imagine better products, and specifically products that meet more user needs. We never start with a solution and then have to look for a problem to solve with it. Service design sprints force us to work the right way round. Stories keep our focus firmly on user need.

Telling ourselves these stories breeds empathy. It also enables us to inject personality into our personas. Sometimes a persona that’s built on solid research can accurately describe needs and behaviours, but lack the texture of people in the real world. Using the personas as the characters in our stories enables us to focus on authentic needs and behaviours and breathes more life into the ideas and creative process. It acknowledges that great design is both an art and a science.

 Working together to write and draw stories about our personas

A forensic focus on the audience is complemented by the ability to adopt a macro view of what we’re making. Creating a Lifecycle and Service blueprint gives us this additional perspective. A Lifecycle breaks up user needs and desires into stages. For each stage in the Lifecycle we describe what the user might be thinking, feeling or doing. The Lifecycle describes user context – their typical day-to-day life. When we understand this, we can start to project our service into that context. We layer a Service blueprint onto the persona Lifecycles to describe where the BBC could meet a user need. The blueprint also helps us to identify ‘seams’ or moments of friction between the different ideas or features in our product.

 A lifecycle broken into stages so that we can design solutions that meet specific needs

Each story we create for a sprint might prompt a number of ideas that we can prototype and test. By unpacking an idea, using the service blueprint to identify where it fits into the context of user need, we can interrogate how plausible the idea is within a story, and also strengthen the connections between it and the other elements of the service.

The service blueprint allows us to interrogate each idea at the same time as developing, prototyping and testing it. It lets us focus on the idea, and encourages us to consider its place in the wider service and the needs of the user. We can also begin to get a picture of the ecosystem that different combinations of ideas would create, helping us to judge the feasibility as well as the desirability that we learn about from user testing.

Pieces of string describe the pathways and connections in the service blueprint

Human-centred product development

Combining service design and design sprints has lots of advantages. Service design forces us to think in terms of context – both user needs and a service as a whole. It helps us to connect things, and to better judge the feasibility and plausibility of the experiences we design. It focuses on gaining insights, so that at the end of the sprint project we don’t just emerge with lots of ideas that have been prototyped and tested, but are also mapped, documented and have contributed to our understanding of the audience.

There have been lots of teams across the BBC trying out sprints and contributing to what we currently know about what works. We’ve worked as a team to refine this process, and we’re continuing to evolve and iterate the tools and techniques for different teams inside the BBC. Lots of people have been involved and I’d like to thank Ryan Hussey, Jacek Barcikowski, Rae Spencer and Josephine Lie in particular for their work on Sprints at the BBC. Tom Bradley and David Gallagher have provided valuable creative direction. And we’ve had help from outside the BBC from Steve Benford from Nottingham University and the Service design agency Livework.

I hope this post has been useful if you’re thinking about design sprinting on your projects. Please leave a comment. It would be great to know how it works for you.

Dan Ramsden is Creative Director, User Experience Architecture, BBC Future Media