I鈥檓 Dan Ramsden, a member of the design team for 主播大秀 iWonder. I鈥檝e recently worked on our new content format,and the at . During these projects we鈥檝e been experimenting with 鈥榙esign sprints鈥�, a fast and structured way of developing ideas.
Each 鈥榮print鈥� focuses on a specific design challenge. And because 鈥榮printing鈥� 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鈥檝e done lots of design sprints, so I wanted to share what I've learnt and how we鈥檝e developed the process.
Where we started
Teams around the 主播大秀 have been experimenting with design sprints for a while. But a fellow 主播大秀听iWonder designer, Ryan Hussey inspired our team to try sprints after he read about the approach on the Google Ventures blog . 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 鈥榳hat 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鈥檝e done more 鈥榙esign sprinting鈥� we鈥檝e found way to adapt the process for the way we work at the 主播大秀.
What we didn鈥檛 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鈥檙e welcome. We鈥檝e 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鈥檝e also embraced the idea of when sprinting. The idea of limiting yourself to a five-step process to develop an idea is already a big constraint. But because you鈥檙e 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 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 , 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 鈥楬ow might we鈥︹�� question. Good 鈥楬ow might we鈥︹�� questions focus the mind, but they aren鈥檛 too restrictive. Using our personas, we adopt a point of view, or identify the most important things our audiences need. Then we ask 鈥楬ow might we鈥︹�� questions which force us to imagine products or features that will meet these needs. When we were working on the we asked, 鈥淗ow might we make the homepage feel more personal鈥�, 鈥淗ow might we make the homepage feel more interactive鈥�, 鈥淗ow might we make the homepage feel more 鈥榣ive鈥欌��. 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鈥檚 鈥� (PDF).
Seeing the 鈥榖ig 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鈥檇 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鈥檝e 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 鈥榸oom 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 鈥榮ervice 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 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鈥檝e described how we regularly use personas and user research to shape and refine our ideas as they鈥檙e 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鈥檙e 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 鈥楬ow 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鈥檚 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鈥檙e 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 主播大秀 could meet a user need. The blueprint also helps us to identify 鈥榮eams鈥� 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鈥檛 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 主播大秀 trying out sprints and contributing to what we currently know about what works. We鈥檝e worked as a team to refine this process, and we鈥檙e continuing to evolve and iterate the tools and techniques for different teams inside the 主播大秀. Lots of people have been involved and I鈥檇 like to thank Ryan Hussey, Jacek Barcikowski, Rae Spencer and Josephine Lie in particular for their work on Sprints at the 主播大秀. Tom Bradley and David Gallagher have provided valuable creative direction. And we鈥檝e had help from outside the 主播大秀 from from Nottingham University and the Service design agency
I hope this post has been useful if you鈥檙e 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, 主播大秀 Future Media.