I first came across the Design Sprint when a colleague sent me an article about how the Phoenix Museum selected the process to reimagine their visitor’s guide. The Museum had just underwent a rebranding, and the staff wanted to find a way engage the visitors in a more informal way. The sprint was run because it brought more voices into the room (diverse staff), produced a working prototype quickly, and provided user feedback, all in one week. Working in a Museum myself, I wanted to know more about the Design Sprint.
The Design Sprint was developed by Jake Knapp, who was working for Google at the time. He wanted to figure out a way to make his time more productive and developed the Sprint. It was then tested on Chrome, Google Ventures and Gmail. Having success, the Design Sprint was moved to Google Ventures. Google Ventures invests about 300 million dollars a year to help startup companies develop products and test those products. To save money and make money, startups could use the Design Sprint to launch new products and ideas, and determine if on the right track with little risk involved. Knapp states in his book: “Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, you’ll get clear data from a realistic prototype. The sprint gives you a superpower: You can fast-forward into the future to see your finished product and customer reactions, before making any expensive commitments.”
The Design Sprint has been used with many companies such as Slack, Blue Bottle Coffee and Savioke. The Sprint typically takes five days and is run by Google Ventures, but is also adaptable for anyone to run at any company or organization. Knapp states: “Sprints offer a path to solve big problems, test new ideas, get more done, and do it faster.”
The first step is creating a team or group of people to start a sprint. This team should consist of no more than seven people. In a group there should be a “decider,” someone who makes the difficult decisions. It is recommended that this person be the CEO, Chief Designer, Manager, etc. The group will also need a facilitator. The Facilitator gives the group positive encouragement, keeps time and the group on track. The other five members should come from different departments within the company or organization, to offer a diverse perspective. Once the team is established, everyone must clear their calendar for five days and commit to the Design Sprint.
Assuming the Sprint is being conducted over a five days period your week will look like this:
Monday: Map out the problem and pick a place to start. At this stage, the team will be tempted to start solving the problem(s), but this must be avoided. It is essential that all parties come to the Sprint with an open mind.
Tuesday: Everyone will sketch solutions on paper and these ideas will “compete”. During this phase, teammates work independently to brainstorm. Knapp absolutely discourages the “group brainstorm” as it deters problem-solving, whereas “solo brainstorming” encourages answering big problems.
Wednesday: As a group, a decision will be made on how to solve the problem. This will come from the sketches that were illustrated the day before. During this phase, the group must be discouraged from thinking of new ideas. However, ideas from the sketches may be combined and unused ideas may be recycled for a later date or project.
Thursday: Create the prototype. For this step in the process the team should all be given jobs to create an effective prototype. The prototype does not have to be over designed but should be convincing to the User being tested on Friday.
Friday: User Testing. Knapp suggests interviewing users while they use the product. The rest of the team should watch on in another room and take notes. These notes should then be categorized at the end to see what trends emerge. Changes should be made based on user feedback.
Why Use the Design Sprint?
Much like the Cognitive Walkthrough and Heuristic Method, the Design Sprint could be considered a “discount method”. A sprint does not require much financial support, and can be done rather quickly. However, acquiring solutions to big problems does require staff to allocate a large amount of their work time to the process. This may place other important projects on the back burner. Thus like many user testing and evaluation methods there are pros and cons to the Design Sprint. Employing the Sprint would have to be at the discretion of the organization based on how many other important projects are currently being worked on.