Previously I’ve written about design sprints and the lessons I learned from using them over two projects. This post is about the third time I’ve used design sprints, a five-day process of rapid idea generation and testing. For this project we combined the design sprints and service design tools to arrive at something that I think is pretty powerful.
Human-centred product development
One of the trends I’m tipping for 2014 is a greater emphasis on multidisciplinary teams – and recognising the power of design thinking to result in better performance no matter what you do. Design sprints are an intense experience, they’re sort of like the espresso of design methodologies. And of course, not everyone likes espresso – it’s intense. Similarly, the creative energy required to contribute to design sprinting can be intimidating. We wanted to make the design sprint process as accessible as possible. We also see real benefit in bringing more specialisms into the sprint – that variety in expertise should help in both the generation of ideas and when assessing them. So this project was an attempt to create a method of ‘design sprinting’ that could be done by anyone.
Just like the last post, this isn’t going to be a manual to doing design sprints – for that, this is a good place to start. What I’m going to describe is how this differed from that published method and what we’ve done at the BBC in the past.
At the BBC we have a really well-defined product development process. Product managers initiate projects and shepherd them through the conclusion. UX&D (the user experience and design team) are available to help shape and deliver the products that this product team envisage. Design sprints have most often been used once an idea for a product or service has already been fairly well defined – through business analysis. But we wanted more design thinking (and hopefully some designers) to be involved in the idea generation stage – as well as the shaping and building that comes later. We thought that the flexible rigidity of the design sprint process would work well. We could have constraints and creativity.
Human-centred design
I’m going to write in detail about the things that make this process so effective, it’s the techniques we’ve borrowed from service design. I’ve written about the tension we’ve sometimes felt between individual sprints and the longer term goal of the design project. Service design allows you to more easily think in terms of ecosystems – not only the ecology of a product overall, but also to describe and project that product into the everyday context of the audience and their needs. I’m going to talk about three ways we did this – methods for ensuring that product development takes the best of what human-centred design has to offer.
Who are you and what do you want?
Audience need is always at the centre of everything we do. But the frenetic pace of the sprints puts designers under pressure, and when under pressure we’re more likely to resort of heuristics to answer tricky questions and decisions. Often these heuristics can be design principles or just plain gut instinct. In this project we managed to arrive at a design sprint methodology built on user insights and needs to deliver the heuristics. If we’re ever struggling, personas and the user is the resource we rely on to supply the answer or direction.
We developed a few tools to make sure that we started and finished the process with the user. As well as a going into the design sprints with insights gained over a month of research, in which we carried out co-design and un-focus groups, we returned and refreshed our insights as the sprints progressed. After clarifying our understanding of our pre-existing product personas, we used these throughout the ideation process. We began each sprint by telling stories about our personas within the context of a central ‘How might we question.’
Previous research at the BBC had provided us with some universal needs related to our audience. We could take these needs and project them into the context of our product. It was these needs that shaped the stories that we told. Although we didn’t put conscious effort into it, on reflection we could go back to each story and identify the needs and behaviours that we’d identified in the research stage of the project – which is always reassuring.
We told the stories of three types of interaction or need – ‘Pages’ were single events, ‘Chapters’ were connected ‘pages’ – they might be multiple sessions or connected products and services, ‘Books’ were experiences that closely aligned to the identity of the user – they were passions that initiated some level of creativity as well as consumption.
I’ve written about how I think stories can help designers to identify gaps or implausible connections between the elements of designed experience. In retelling the stories (and using trajectories) we got a sense of the seams in the experience – the points where the continuity or progress of the experience were in doubt. This focus on connections and continuity was also helped thanks to our adoption of some more service design thinking.
Lifecycle and service blueprints
Service design was great at pulling our focus firmly on user need. Through storytelling and a focus on the audience it breeds empathy – which is probably a designer’s greatest tool. But the forensic focus on the audience was complemented with the ability to foster a macro view of the work we were doing.
I’ve described how we used insights and user needs throughout the project. One way we did this was to create a lifecycle to describe user needs. These took the universal needs that we’d identified and developed using our own research and used them to describe key moments or chapters in a user’s engagement with our product. For each moment we could describe what the user might be thinking, feeling or doing, so that we could begin to consider the role of the BBC.
The lifecycle is the context for the user – it’s their business as usual. We were then able to project our service into that context. Our service blueprint can describe the role of the BBC at the various chapters or moments in that evolution of user need. It allows you to design for the context and the need. It also allows you to identify the seams between the ideas you’re creating. Each story might contain a number of ideas you can prototype and test. By unpacking the idea, using the service blueprint to identify where it fits into the context of user need and their relationship with the BBC, you can not only interrogate how plausible the idea is, but also refine the idea and design by strengthening the connection.
The service blueprint therefore allows you to interrogate each idea, at the same time as developing, prototyping and testing them. It encourages you to not only focus on the idea, but also it’s place in your service and the needs of the user. You can also begin to get a picture of the ecosystem that different combinations of ideas would create, helping you to judge the feasibility as well as the measure desirability you get from user testing.
Testing
Testing is central to the design sprint process. Each sprint literally begins and ends with the user. Insights from one week are used to inform the understanding for subsequent sprints, because the final day of the sprint puts the prototypes we develop in the hands of the user. For this round of sprints we used low fidelity, but highly interactive prototypes.
Lots of formal testing in UX takes place in usability labs, but we didn’t feel that was appropriate for this round of sprints. We used the same rigour we do when testing in the lab – constructing carefully planned test plans, recruiting well and making the simulated experience as closely resemble the actual idea as possible. But because designers were facilitating the testing we were able to adapt the prototypes as the testing progressed.
If a user didn’t use Twitter, but our idea was focused on interactions via social media, we were able to adapt to the prototype accordingly. User testing is qualitative research, so there’s some pressure to get insights from every single participant you recruit. By designing the prototypes and testing sessions to be flexible and adaptive, within constraints and parameters, we were able to maximise the insights we got from the sessions.
More insights
Combining service design and design sprints has lots of advantages. Service design forces you to think in terms of context – both user needs and a service as a whole. It helps you to connect things, and to better judge the feasibility and plausibility of the experiences you design. It focuses you on gaining insights, so that at the end of the sprint project you don’t just emerge with lots of ideas, many of which you’ve prototyped and tested, but also gives you a chance to document and develop your understanding of the audience. You get two sets of insights. One set relates to the individual ideas, which if combined can give you a set of heuristics to judge future ideas against. And you get the chance to describe your understanding of the user needs and context, and through the insights gained in user testing refine this to make future ideation more closely match the needs of the audience.
Leave a Reply