Sketch solutions on paper: generate a broad range of ideas, and narrow down to a select group; team members are given time and space to brainstorm solutions on their own: they can look to comparable problems for inspiration, take note, boost idea generation, share and vote, and narrow down to one well defined idea per person, creating their own detailed Solution Sketch;
By the time you complete our course you’ll have everything you need to successfully run your own Design Sprint, so we’d very much encourage you to do so! You’ll also have lifetime access to all the materials to reflect back on and use however you wish afterwords. We’d also encourage you to keep in touch with us and let us know if there’s something we can do to help you with your future Sprints!
But probably the most valuable benefit of design sprints is that they introduce stakeholders to the importance of validating ideas with real users. Google has orientated the whole week around building a prototype that users find easy to use. That is a valuable lesson for colleagues who can often be more focused on their own agenda, rather than that of the user.
Monday’s structured discussions create a path for the sprint week. In the morning, you’ll start at the end and agree to a long-term goal. Next, you’ll make a map of the challenge. In the afternoon, you’ll ask the experts at your company to share what they know. Finally, you’ll pick a target: an ambitious but manageable piece of the problem that you can solve in one week.
Once we have an understanding of the foundation we all need to run a successful design sprint, we kick off by working through the sprint’s Monday exercises — setting a proper long term goal based on our sprint challenge, determining our sprint questions, creating a map, interviewing experts, connecting our personas to the map, and selecting a target.
The First principle incorporated in regular science is the "Design Thinking Cycle", which is new to the method. The cycle starts with you, envisioning the lives, dreams and anxieties of your customers. Then you define the problem you want to solve. After that you try to figure out as many solutions to that problem as you can imagine. Then you choose the most likely solution to be successful, you make a prototype of that solution and test its acceptance with your customers. Only after you have found a successful solution, you will invest in executing your business.
We added a new exercise here that makes the storyboarding process at least 27 times easier (give or take). It’s called User Test Flow and it’s a form of Note & Vote exercise. Everyone designs the barebones of their own storyboard and then we vote on the one or two that we end up prototyping. Even though it’s an extra step, it speeds up the storyboarding process by a million miles and eliminates the “designing by committee” aspect of it. Here’s a video that explains it in detail (and there’s a Medium post on it, too). https://res.cloudinary.com/practicaldev/image/fetch/s--Kjt27KoI--/c_fill,f_auto,fl_progressive,h_50,q_auto,w_50/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/92605/70cd7f2f-e0f0-4603-922c-b1048cbd9a7e.jpg
This page is a DIY guide for running your own sprint. On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a high-fidelity prototype. And on Friday, you’ll test it with real live humans.
A design sprint reduces the risk of downstream mistakes and generates vision-led goals the team can use to measure its success. For the purposes of this book, we’ll focus on digital products, as our direct experience lies in that arena, though the design sprint has roots in gaming and architecture,¹and many industries have employed them successfully.