Design Sprints are a 5-day process for align team members and key stakeholders behind solving a problem, then rapidly prototyping and testing a potential solution.
When potential clients, colleagues, and acquaintances inquire about Voltage Control and learn that I’m running Innovation Workshops many are curious about the mechanics of an innovation workshop and Design Sprints. Who is involved? What do you do? How do they work? When is a good time to do them? Let’s start by discussing Design Sprints….
One of my favorite workshop frameworks is the Google Ventures (GV) Design Sprint. Jake Knapp began to conceive the Design Sprint process while working at Google designing Google Hangouts. Jake left Google to join the GV Design Team and began to refine the process while facilitating Sprints for GV portfolio companies. After running hundreds of Sprints, Jake released a book providing concrete examples and step by step guide for each exercise.
Design Sprints are a 5-day process for align team members and key stakeholders behind solving a problem, then rapidly prototyping and testing a potential solution. Each day has well defined exercises selected to focus the team on a specific outcome. Testing ideas quickly in 5 days prevents you from getting emotionally attached to your ideas. This is critical, because, as David Aycan points out, even when we know testing and validating is important, “It’s hard to acknowledge the faults in your baby when you’ve been invested for weeks or months.” — Fast Company
Monday the team will gather to unpack information and build context for the Design Sprint. The day starts by setting a goal and then getting pessimistic to question why you won’t meet your goal. You’ll draw a map of your problem space and then interview internal or external experts to learn more and confirm assumptions in the map you drew earlier. At the end of the day, you will select a target on that map which will become the focus for the rest of your Sprint.
Tuesday starts with lighting demos of analogous inspiration. These are apps, websites, and products that are solving similar to adjacent problems. Next you will participate in a series of exercises for sketching solutions focused on your Sprint goal, questions, and target. These sketches don’t require illustration skills and are simply a way for you to share your idea(s) for solving the problem. While sketching we work alone together. We are in the same room, but each participant individually creates their own sketch.
We start Wednesday by posting all the sketches on the wall in an art gallery format. After reviewing and discussing each sketch as a group we conduct a straw poll voting process. The straw poll generates a heatmap that helps to guide the decider as she places the three binding votes.
Once the 3 binding votes are placed, we begin to think about how to prototype the sketch(es) with votes. First, we must decide if there are conflicting ideas which will require multiple prototypes. Then we will start to storyboard each prototype. Developing a concrete storyboard for each prototype ensures that everyone is aligned on the workflow and experience that we will test. This avoids last minute changes while prototyping and will allow your designers to stay heads down while prototyping.
Now it’s time to prototype. The prototype is a simple visual facade constructed of multiple images stitched together using Invision, Marvel, or similar graphical prototyping tool. The fidelity of the prototype must be high enough for a tester to think it is a real product interface.
Non-designers will perform tasks necessary to make sure that the designers can move quickly and get as much done as possible. This includes collecting assets, writing copy, etc. Once the screens for your interface are done, you’ll stitch them together using your preferred prototyping tool. At this point you’ll walk through the flow enough times to feel comfortable knowing what links work and how to guide your testers through the interview smoothly.
Friday we test the prototype with 5 users. This can be done in person or remotely. The interviewer conducts the interviews one-on-one with each tester while the rest of the Design Sprint team observes from another room. The interview is conducted in a way to make the tester feel at ease and help them navigate the prototype. The interviewer avoids leading questions or biasing the tester in any way.
During each interview, the sprint team captures quotes and observations from each tester. At the end of the day, we will have lots of notes to review and only the last tester will be fresh in our mind. We always have a quick recap at the end of the day, but save any real observations until we’ve had time to reflect on all our notes.
Sometime the following week, ideally on Monday while things are still fresh, the Sprint team should gather to synthesize their learnings. Rather than a free-for-all brainstorming session, I recommend that the team take turns sharing their learnings. This approach works best when the team prepares beforehand and brings their learnings to the meeting ready to present. Once each team member has shared their observations, the team can discuss how they want to respond and internalize the insights.
Typically a Design Sprint will not generate a prototype that is immediately ready for development. Instead, you may prove that your target solution won’t work and you’ll need to substantially change the prototype or prototype another solution entirely. Alternatively, you may simply need to make some incremental changes to address flaws in your prototype. Either of these can be addressed iteratively, by adjusting the prototype and testing until your level confidence justifies the expense of building and marketing the solution.
Design Sprints provide a framework that aligns and focuses the team, allowing them to move fast and achieve real results. I confidently say this is the cheapest, easiest and fastest way to innovate. I’ve run software projects for years and many of those years we’ve done so in an iterative, Agile, and lean manner. The Design Sprint process allows us to follow similar tactics in a much less resource intensive manner, leading to more rapid learnings.
If you are in or near Austin, come visit us at the Austin Design Sprint meetup. Each month we have a guest speaker share their experience participating in a Design Sprint . If you would like to be a future speaker please email me.