A design sprint is a process for answering pertinent business or product questions through design, prototyping, and testing.
At least, that's the textbook definition. The longer answer is: a design sprint is a five-day process, created by Google Ventures, to help you solve a problem with your current or imminent product. If you have an app that needs a new feature based on user feedback, you have a client who wants to find out if their idea is worth pursuing, or you are trying to figure out the best way to roll out a new feature in your web platform, these are all things a design sprint can help you answer.
A design sprint packs weeks, even months of work into one week by cutting out a large portion of the traditional launch route. You make most of the decision for your MVP up front, quickly make a prototype -- which can be very low-fi -- and get some preliminary answers.
The basic set-up from Google Ventures is split into five days. Here’s a brief synopsis. You can read more in depth here. All the design sprints we’ve done for clients have yielded positive results.
Day 1 - Unpack
On the first day of the sprint, your team will "unpack" everything they know with the goal of getting everyone familiar with what the client is trying to do, whether it's to solve a problem in an existing product or make something new.
Day 2 - Sketch
Everyone will sketch out ideas individually, then refine some of them, and create a heatmap by placing all proposed ideas on a wall and using dot stickers to mark interest.
Day 3 - Decide
You'll take your heatmap and decide what seems most feasible within your own constraints for building. Then you’ll storyboard your decision.
Day 4 - Prototype
This is the most productive day. No meetings, just work. You’ll make a functional prototype that you can test with real users and get some feedback.
Day 5 - Test
You’ll show your prototype to real customers in one-on-one interviews, gather feedback, see what ideas did and didn't work, what your prospective customers like, what confused them, and any other takeaways.
- A note on Days 4 and 5: We have our own system for prototyping and testing that takes longer and is more iterative as we work towards an MVP, so we usually end the design sprint on day 3, and do the last two days as a process. You can follow the guidelines for the sprint or you can change them if that would suit you. There's no wrong answer here!
Implementing the Sprint
With our latest client, we went through the first three days of the design sprint and then went on to make prototypes and test at our own pace.
This day had a steep learning curve for us because our client came from a technical field where none of us had experience. We spent the day asking questions, absorbing teachings and general concepts of the technology, and understanding the problems our client was facing. It was a day of trying to get all of us into a mindset of being a user and experiencing their problem, and that led us to a list of pain points which we would solve in this sprint and a simple flow for our users.
We spent the day sketching ideas and trying to come up with ideas for our pain points in the simple and loosely-followed flow we set up the day before. We tried a few design exercises to get our creative juices flowing, and then tried tackling our pain points with concrete designs. Then we put up all our designs on the wall, did some silent voting to create a heatmap and discussed. It's interesting to see what each person gravitates towards; from here, we had a clearer understanding of the solutions we seemed to like.
We spent the day discussing and thinking through what solutions we felt would be the most feasible. We then set up a list of assumptions about our designs and users and how we would test those assumptions. Towards the end of the day, we created a more detailed user flow, which set the stage for our prototyping and testing phase.
With assumptions, testing methods, designs and a user flow in hand, we had a concrete way to move forward.
After a few successful design sprints, we've started to gather some feedback on the process. There a few points that have stuck out to me:
People really like the "physical" aspect of the sprint; writing on paper with pen, using markers and post-it notes and stickers. This really got people to focus on the problem; it got them off the computer, with email, Facebook and Slack as a distraction.
The voting aspect of the sprint is also well received: Most people liked the silent critique and then the visual representation of votes (dot stickers) to make a heatmap of interest.
We found that the sprint lead to better results, or results that were clearer, when the sprint was used on smaller aspects of a problem versus using it for an entire app. It seems there are too many assumptions to test for and too many directions available to explore; the more narrow the problem, the better our outcome.
I recommend the design sprint to any company with a hard product or client problem to solve. It’s a rather large time commitment, but its in-depth approach seems to lead to either higher quality results, faster validations, or both.