Image source: http://www.gv.com/sprint/img/sprint-diagram.png
If you ever worked with classic agile development, you have probably seen the concept of a sprint. Sprint is a set block of time, where a certain amount of tasks have to be completed and ready to be reviewed (or preferably: deployed on production).
Sprints have been introduced not only to shorten the development cycles, that can be compared to a classic waterfall approach, but also to make sure that everyone stays focused only on the work that needs to be done at the exact moment. While a bit short-sighted at times, sprints are a great way to finally finish the endless debates and actually start making things in order to see what happens.
That is exactly the reason why when Google Ventures design team introduced a concept of Design Sprint, we decided to give it a try.
What is a design sprint
The way Google Ventures team puts it is: “The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.”. They have been using design sprints to solve design and business issues with a lot of the companies they work with, from Blue Bottle Coffee (a coffee roastery and café in San Francisco) to startups they invest in. The requirements of a sprint are pretty simple: get a diverse group of people that have to tackle a certain problem, lock them in a room for five days with a structured plan of work and you’ll probably have a bunch of great solutions at the end of the week.
“The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.”
Before you start a sprint, make sure you are well prepared and have a user group to test with at the end of the week set up, that will definitely be required. If you don’t have user researchers on your team, you’ll have to improvise, however, pay attention to it, user testing is a very important step in the sprint.
The structure of those five days is as follows:
Day 1: Unpack
This is the moment when everyone on the team “unpacks” everything they know. Since knowledge in the team is usually asymmetrical: engineers, sales team, design team and so on, they all know their own limitations and goals, it’s important to get the field balanced for everyone and share all the information the people have. This is usually performed by taking notes and creating a coherent user story that spreads between all the teams involved in the sprint. Writing down all the necessary information is quite important at this stage, it assures everyone, that knowledge is not lost in the process.
Day 2: Sketch
The goal of the second day is to get all the possible solutions on paper. This part is usually the most challenging to non-designers, since not everyone feels as comfortable sketching out their solutions as designers do. If you’re moderating the sprint, make sure nobody’s productivity is disturbed by this step: in most cases it doesn’t matter if the sketches are boxes and arrows or beautiful paper models; as long as the solution is obvious and visible it can be easily referred to the rest of the team.
Day 3: Decide
Based on the solutions you got during day 2, at this moment you probably can already choose at least a couple of best solutions that you want to prototype and test with actual users. This day mostly boils down to getting all the solutions gathered by the team in the form of a draft, that will be used later on as a base prototype for user testing.
Day 4: Prototype
As the name says, this is the day when you’ll be creating a realistic-looking prototype for user testing. At this stage, the team of experts assembles to build the prototype in one day. Use the tools you are familiar with to make sure they don’t decrease your productivity and build a prototype that looks as real as possible.
Day 5: User testing
At this point, you get your users to test your prototype in a 1-to-1 environment. The important part though, is to recognize and record both successes and failures — after all, you’ve just managed to spot both in just five days, so good job everyone!
Design sprints are a great way to get out of endless debate cycle, pick a big target with your team and see which of the proposed solutions works for your users. It also encourages the sense of unity amongst your team, fixes some of the issues with asymmetrical knowledge within the members. If you’re stuck with a problem you don’t know how to solve, it might be the most effective way to find some answers. Give it a try.