In his book, The Lean Startup, Eric Ries advocates considering the development of a product as a “grand experiment that aims to answer a question”. With that question being “should the product be built?”. The idea is that, once you know the problem you are trying to solve, then you create a minimum viable product (MVP) that you can run a test on and learn to see whether it is worth carrying on with further development of the product or take a pivot and change direction.
I recently came across a technique that has very similar principles to those described by Ries. It is called the The Design Sprint. Developed by Google Ventures, the aim is to answer questions similar to the one above. The sprint entails all the steps of designing, prototyping and testing with customers, however it’s all done within five days. The rationale behind the Design Sprint is that you don’t have to create a fully working product, and that you can get validated learnings from your customers, but in a fraction of the time by testing using a prototype. As Google Ventures put it “the sprint gives teams a shortcut to learning without building and launching”.
The first day is known as ‘unpacking’. Here everyone in the team, business people, marketing people, sales people, user experience people and engineers all discuss and share knowledge about the problem area. This gives everyone the opportunity to understand the problem as fully as possible. At the end of the day the team should expect to have come up with a high level user story or hypothesis which they are going to test.
Day two is all about sketching and generating ideas about solutions that may provide answers to the hypothesis. Each person works alone to create these sketches. A variety of techniques are used including mind-mapping and storyboarding.
On the third the team comes to consensus on the elements of peoples ideas that would be best to take forward for the prototype. This could include further rounds of sketching. But by the end of the day the team should have a high level design from which to create a prototype.
Day four is where the team creates the prototype. Ideally the team has all the capability within it in order to build the prototype. The fidelity of the prototype can vary and is dependent on what the team is trying to test. It’s not always necessary to have a clickable prototype; a paper prototype may be sufficient.
The user testing happens on the final day. This usually consists of one-on-one interviews regarding the prototype. This should give the team the information to answer their hypothesis and allow them to learn about their idea.
I’ve only been involved in one Design Sprint so far, so it’s hard to say whether the learnings that were gained during those five days are as valuable as those that might have been gained through an approach where working software was used for testing. But, what I can say is that it was a great approach for generating a lot of ideas and then getting feedback from the customers very rapidly. It did give the team some information on whether to continue to try and validate further the original idea or not, and they were able to do this all within five days.
I’m looking forward to being involved in my next Design Sprint and interested in seeing what learnings it brings.
If you’ve used the Design Sprint or similar technique before then we would love to hear about your experiences.
Image Credit: Zebulon666
awesome post