Jake showed up in slippers. His laid-back style mismatched the workshop’s minute-by-minute planned schedule each of us had on our desks. Everything was thoroughly pre-calculated and structured: there was no time to waste. The atmosphere felt nice and easy anyway.
The workshop began with an ice breaker slide that claimed “I hate ice breakers” and Jake used “her” or “she” every time he needed to put an example of somebody who occupied a position with power in a company. This set the tone for the rest of a super-compressed sprint day.
During the first few slides of his presentation, Jake exposed himself to the group and talked about his Encarta-failure and how Wikipedia had won them over. Let me sum up this for those of you who don’t know what happened. Basically, Encarta had to face its new competitor: Wikipedia. After evaluating what actions to take, Encarta’s team decided that, as design was their clearer strength against Wikipedia, they should redesign Encarta and give it a fresh look. This process took a whole year and once they launched their brand new version Wikipedia was already on the Internet way ahead of them. They had risked it all for one possible solution without testing other alternatives and they had failed completely.
After describing this experience he plunged in explaining in which ways this “traumatic” experience had pushed him to create the methodology that we now know as Design Sprint. He realized that solutions weren’t always as obvious as you think they are and could be hiding in your own team. Also, in this modern agile fast world we live in, in order to be competitive you need to be able to test a series of ideas in the shortest amount of time with the lowest possible risk. The key? Your team. Your experts are the one who’ll help you out in a Design Sprint. You need to listen to them and not get carried away by your own opinion or the ones that the strongest voices in your team have. You need to open up and map the problem in order to get solutions. Following this premise, he designed Design Sprint.
What is Design Sprint?
A five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. It consists in getting your team together in order to shortcut the endless-debate cycle and compress months of time into a single week. It is based on obtaining data to prove or refute an idea from a realistic prototype without making expensive commitments. Basically, obtaining data from prototypes can help any business save useless developing hours and test more ideas than risking everything for the one that just looks or sounds better. Design Sprint is a shortcut for data.
We believe it is interesting to point out that Design Sprint has generated fanaticism and we know what popularity does to concepts: no good. The term has been misused so much that its meaning is sometimes completely lost and lead designers to believe statements as “Design Sprint is Bullshit” (or Design Thinking?) when it’s not. People who are not familiarized with the method tend to understand it as a magic trick to fix any kind of problems affecting any kind of projects. But it is certainly not a method that seeks to simplify or minimize the design process nor design itself. You need to beware and not get lost on the many workshops, articles, studios and so on that are just using a trendy concept to make more money.
It is a methodology that does work in a wide variety of projects and can complement other processes or systems. It that can only be applied when there is a team of experts who know perfectly well the business they are working for and the specific problem they need to solve. Design Sprint is used in situations that need to be cleared up quickly by testing innovative ideas at a low risk.
The workshop was structured as a Sprint. We lived the (compressed) Design Sprint experience and acted out as if each table was part of a startup called “Magic Penny”. We couldn’t use cell phones or computers. There was no content switching. We needed to get offline in order to focus on the problems and ideas emerging in our meeting. We used sticky notes, sticker dots and markers to write down our ideas and only reached out for technology when we had a certain amount of minutes to look for references or in the end when we had to build prototypes.
The workshop was divided between Map, Sketch, Decide, Prototype and Test. Every table was a team and each of them had a decider and a facilitator. Jake shared his experience and gave us his advice for each Design Sprint day. At the end of the workshop day, there were sketches made by the 105 professionals that attended the meeting sticked on the walls. The room was full of ideas. Each team proposed different solutions to achieve the same long term goal. Jake wrapped it up with an interesting Q&A moment. It was quite enriching to experience Design Sprint by the hand of its own creator.
Jake mentioned the controversial difference between “perfect data” and “quick and dirty data”. The data that results from a Sprint belongs to the second category. He explained that this is because the objective of a Sprint is to design a solution, define a strategy and obtain data in the fastest possible way. Perfect data is valid but it takes a really long time to get. Design Sprint is used to test risky decisions without wasting time, money or clients and it is based on the knowledge of your own team of experts who are able to map the problem. This method allows multiple iterations, that is, repetitions of the Sprint in order to test different ideas. It is not just about getting rid of the problem in a week but about getting to a solution that the team thinks is the best.
This is the key difference between Design Sprint and Design Thinking. The latter costs more money and time and has as a result products that are developed off human data and Sprints are cheaper and require iteration to arrive at successful products but they are faster anyway. Design Thinking focuses on users since the very beginning of the process while Design Sprint maps problems with experts and doesn’t look for feedback directly from real users till the end of the week. Neither of the methods are always the best solution. Sprints are not usually helpful to validate a whole business while Design Thinking isn’t usually useful if you need to test a business’s website for example. Sprints are helpful to get to know if the problem’s solution is market fit. On the other hand, design thinking analyzes the insights of a certain problem and investigates the users’ needs from the very beginning of the process.
There is a great contrast and incompatibility between the need for analyzing a problem from each and every possible perspective and the need for being efficient in a market that demands immediate risk-free solutions. It’s not as simple as the marketing buzz puts it. When trend fans adopt a new term without really understanding it or questioning it and just preach the idea of solving a startup with a design sprint, the concept gets totally messed-up and loses credibility.
Design Sprint does not seek to rush through the whole investigation of a problem and is not useful in order to validate an entire business. Design Sprint is all about effectiveness and efficiency. You need to create a context where making mistakes is not as expensive or as risky as the real world, look for a week to focus completely on a certain project without being bothered by other meetings and organize the team structure by assigning clear roles and getting the correct experts to map the problem. It isn’t a magic trick. It’s an iterative process that can take more than just a week, maybe even a month till you try out every possible solution, but seeks to optimize time and resources.
Story Boarding 2.0.The Sprint Book by Jake KnappTesting video: