The Sprint Book outlines the process developed by Google Ventures to turn back-of-the-napkin idea into a testable prototype in one week. At Differential we often begin our relationships with clients with a Design Sprint. We've found it to be helpful when working with clients who want to quickly validate and gain feedback for a digital product. We discuss five lessons learned of how Design Sprints product owners looking to validate digital product ideas.
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 Design 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 Design 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
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 workshop, is one of our favorite activities. The best thing we have found about sketching? It oftentimes teases out insights that conversation alone cannot. 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.
Our Design Sprints are 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 and Decide on the same day). We have also had circumstances where one day (for example, Mapping), has taken more than one day, but in shorter time frames (3 hours one day, 3 hours the next).
- One time, it was not possible for us to get all of the key stakeholders in a room together for the mapping exercise. 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.
Testing takes place over the course of a Design 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 digital product project. Testing with internal employees is helpful in scenarios where the project may not yet have much support or steam, or if the Design Sprint's goal is to get budget approval.
These are a just a few of the lessons we've learned while following facilitating Design Sprints for our clients. If you think a Design Sprint may help your digital product initiative, contact us, we're here to help.