The Sprint Book: Simply put, a book outlining the process developed by Google Ventures to turn a half-baked idea into a testable prototype in one week. Differential has been utilizing this book as a guide for about a year now, and we have found it to be helpful when working with clients who want to quickly validate and gain feedback for a digital product idea.

Recently, my coworkers Sean, Salem and I gave a presentation on the The Sprint Book to our local peers. It included some open dialogue about the lessons we have learned while following the design sprint process. I wanted to circle back on these conversations and share some of the takeaways with you.

Build Rapport

Two of the key players in a design sprint are the Decider and the Facilitator. The Decider (normally on the client side) is the person who ultimately has the final say throughout the sprint, therefore it is extremely important that they are present throughout the vast majority of the work being done. The Facilitator (normally on the vendor side) is the person who manages, mediates, and keeps the sprint running smoothly. One of the most important things we have learned in our experience with design sprints is that the Decider and the Facilitator must have some rapport built before the sprint begins. This “pre-work” of getting to know one another prior to delving in will ultimately lead to:

• a better partnership between client and vendor
• a friendly, team-oriented environment in which to work
• greater productivity and output

Set Expectations

Being one of the two key players, the Facilitator has a lot of responsibilities. One of the most important among them? Being able to set the tone and expectations for each day's activities. Sprinters may feel any range of emotions at the end of the day - from confused and unproductive to inspired and excited. It is key that the Facilitator is able to successfully set up the day so that the Sprinters can anticipate these feelings and know that they are totally normal. In doing this, the team is kept on track and focused on the main objective.

Sketch It Out

Sketching, which takes place on day 2 of the sprint, is one of our favorite activities. The best thing we have found about sketching? It oftentimes teases out insights that conversation alone can not. The situation is common: you're in a room of people discussing the features and functionality of a digital product. Everyone has ideas, yet no one is meshing. Some people have valuable ideas that they are struggling to put into words. You leave the meeting feeling like nothing got done. Sketching helps to eradicate this issue by allowing people to visualize and share their ideas. Suddenly, one Sprinter is incorporating another Sprinter's ideas into their next round of sketches. The Sprinters who struggled to verbalize their ideas have visualized them. There are valuable conversations happening and fun being had. You're forging forward together as a group.

Improvise!

The Sprint Book is laid out in a way that is easy to follow, with clear steps to take and tasks to accomplish. But, as with most things, the sprint is very unlikely to go 100% according to plan. Don't be afraid to improvise. Here are some examples of how we have improvised in the past:

• The Sprint Book guides you through the sketching process in 4 steps: Notes (gather notes from Monday's mapping), Ideas (private ideating/sketching), Crazy 8s (8 sketches in 8 minutes), and Solution Sketching (more refined sketching in longer time frames). Most of the time, we improvise by jumping right into Solution Sketching and dedicate a fair amount of time to it.
• On a few occasions, we have combined days (for example, sketch [day 2] and decide [day 3] on the same day). We have also had circumstances where one day (for example, mapping [day 1]), has taken more than one day, but in shorter time frames (3 hours one day, 3 hours the next). You don't necessarily have to stick to the 5 day straight format.
• One time, it was not possible for us to get all of the key stakeholders in a room together for mapping (day 1). In this case, our team interviewed and extracted knowledge from each stakeholder separately and combined the findings to create project maps. While this improvisation is not a perfect state of affairs, it worked out and the sprint was successful.

Look Inside

Testing takes place on day 5 of the sprint. This is when your team tests the prototype you created with real users in order to learn from their insights and to validate ideas. Testing can be daunting, especially when it comes to finding testers. While finding testers that are completely unfamiliar with your project is optimal (i.e. outside of the client company), testing internally is sometimes your best bet. This tends to work best when working with clients whose digital product development is taking place within the confines of a larger company. This way, you can easily gather a small group of people (5 is ideal) within the company who would likely have only limited awareness of the project. Testing with internal employees is helpful in scenarios where the project may not yet have much support or steam, or if the sprint's goal is to get budget approval.

These are a just a few of the lessons we have learned while following the design sprint process. If you utilize The Sprint Book's process, we'd love to hear about your experience putting it into practice. If you have not read The Sprint Book yet, it is available in print, digital and audio format here.