The magic of the Design Sprint
It’s day four of the five day Sprint*. You have spent days with people from different departments far away from your comfort zone. The week started with big questions and now is focussed on one crucial part of the service your company provides. Everyone connected to each other’s knowledge and sketched their own solutions. Based on your findings you have built a prototype of a service with a group of people who never do this type of stuff. But the prototype is just a couple of screens stiched together. There is only one path through it and a lot of functions that are on the screen don’t work. The layout is not up to par with company branding guidelines. At the start of the week you had such high ambitions. You were going to solve the biggest problem your company is facing right now. And after four days you only have a crappy prototype that looks like shit and doesn’t work like a real application should. And to make things worse, tomorrow five users are coming in to test your prototype. This is going to be embarrasing. You go home depressed.
The next morning you come in and the interview is set up in two rooms. One for conducting the interview with the user and one for the rest of the group to watch and make notes. The first interview starts. You watch the live video feed with sweaty palms and a knot in your stomach. This is where you fail and where all the hard work of this week will turn out to be an enourmous waist of time. But after a few minutes of interaction between the Interviewer, the user and the prototype, things start to change. You start to see how well the crappy prototype performs in solliciting real reactions. In no time you have super useful feedback to your design and your stack of notes is growing by the minute. This is great. All the questions about the usefullness of your design are getting answered. There are also things that don’t work so well, but you immediately get ideas on how to fix them and make the design better. A wave of reflief goes through you. The prototype works great. All has not been for naught. This is what it’s all about. The contact with the user gives you a sense of purpose. This is why you are doing all this: to help real people perform meaningfull tasks. The Facilitator drew a matrix on the whiteboard to paste all your notes on, but the area is way to small to accomodate all the notes, quotes and good ideas from all the Sprint participants. Everyone is super exited and you suppress the urge to applaud for the user who gave you so much valueable feedback.
You realize that all this work from this week was aimed at one thing: to learn. Thinking of the bigger picture, formulating the questions that needed answers, making things concrete, exploring options and working closely toghether all work towards the learning in the end. All the exercises created the context for the optimal learning experience on day five. It’s magical.
The right questions
For the best learning you need to know what questions are important. I would even say that this is the most important part of effective problem solving: focussing on the right questions. Once you found the right question, the rest is relatively easy. And all the work you do towards any super solutions for the wrong problem is a waiste of time and resources. Most people skip the questioning part and dive immediately into the solving. The Google Ventures Sprint method spends 20% of its time, one whole day of the five, on finding the right questions. By doing this, you not only focus your energy in the right direction, but the whole day of exercises to think about the questions also sets you up for the learning on day five. Because how are you going to learn if you don’t know what the questions are? Without the questions any prototyping and interviewing is useless. This also makes sure that all people in the Sprint are on the same page. When you collectively watch the user interview, the collective learning works best if everybody has the same questions in their minds and all the discussions between the different people from different departments.
Concrete answering
The Sprint method is more elaborate but it starts with questions and ends with them. What do we want to achieve? What could stop us from achieving this? What do other experts think on the subject? And it ends with the questions to the user. What do you think when you interact with this prototype? In between are questions about how to achieve the goal we formulated. The answering in between is done through prototyping and that adds to the efficiency. Answers have to be much more concrete than if you would not sketch and make prototypes. Much more precise. On top of that, not only do you engage the other half of your brain when you work visually, but you also create a platform to communicate with the other Sprint participants. Discussions become more concrete and focussed. That makes them a lot more efficient and takes away a lot of the abstraction and politics that cloud most discussions.
The power of limitation
Most people think that if you have more time, you can come up with better solutions to a problem. Most of the time this is not true. Limits can be a powerful ally that can help you to focus and work as efficient as possible. All the exercises in the Sprint are time-boxed. For most exercises this works well and the help of the Decider to make the tough decisions helps. But especially making the prototype in just one day is a time-box challenge. This really forces you to focus on the minimal you have to do to create the illusion. Most people think this minimal is quite big already. That you have to do a lot of work before you can put things in front of a user. At the end of day four most people feel they didn’t have enough time, that the prototype is to minimal to work. But the experience on day five teaches people that it was actually enough. That the minimal you have to do to test an idea, a hypothesis, can be very small indeed. The question is what the minimum is you have to do in order to learn. When you learn that this does not always have to be a lot and that anyone can make a prototype that allows them to learn valueable lessons, you become much more effective at problem solving. If you spend less time working on the prototype you put in front of users, you start learning quicker and you are on your way to create better solutions quicker.
Philosophy + design thinking + lean
On a high level this is what the Sprint method is built on: finding the right questions (philosophy/strategy), exploring the problem space by making things (Design Thinking) and being as effcicient as possible (Lean). And apart from the answers you find during the Sprint, the lessons you learn about a whole new tool- and mindset is also a valueable outcome for people. Concepts like Design Thinking and Lean can be abstract and hard to understand. But once you experience them, they start to take on meaning and you can start to understand the value. The last question of the Sprint is maybe the most important: what’s next? What are we going to do with the things we learned? If you don’t use the learnings and apply the principles you learned, the Sprint experience can be magical, but the whole Sprint becomes pretty useless.
*This is about the (design) Sprint as designed by Google Ventures, you can find more about the method here.
