The Design Sprint
Iāve been interested in the Google Design Sprint method over the last year.
Iāve conducted, successfully, some sprints in our studio, so far. Iām quite happy with the results even though a degree of personalization is required.
But, what is a Design Sprint?
The Google Design Sprint is a loosely based Agile method to design and validate quickly a business idea.
Itās a structured process with a tight deadline and a fixed and well-encoded time-frame.
Everything has to happen in a full working week, five full-time days.
The team should be composed of a maximum of 6-8 persons and it should be diverse and multidisciplinary because different skills are required in order to cover all the tasks the sprint requires.
According to its proponents, it is an efficient and affordable way to validate a product or service idea before going to invest big money on implementation.
Here a brief outline of the sprint week, one phase per day:
Understanding #
Itās the day where the team gets the brief and the context of the project in order to set the mind on the proper track.
Itās mostly based on talk and people interactions about content and purpose strategy.
One of the tools that can be used to foster design thinking is the HMW (acronym of How Might We) tool to encode every design opportunities into questions in order to ease the collecting and choice activity. A key person to lead the process is mandatory.
Ideas #
In this day itās all about sketching ideas with a precise schedule of activities, personal and team wise, with review and discussions. Itās the diverging day where all the crazy ideas can be put on the table.
Decision #
In this day all the good ideas outlined and discussed the day before need to be condensed into a single one which will be the main path to follow in the next phases.
Everyone votes each single good idea and a new project draft will be outlined by the whole team.
The new project idea has to be storyboarded within the end of the day.
Prototype #
Based on the detailed sketch of the final idea the team has to prototype it in some realistic form in order to be able to test it with real people.
The tools can be anything as long as they allow to achieve a working artifact useful to test and validate the relevant functions, planned for the next day.
Test #
The last day is dedicated to testing the prototype with real people.
This means you need to find people who are willing to give a bit of their time to you. This is why you need to give them something back as a gift.
The test is a mix of interviews and observation method and should follow this process:
- welcome and introduction to this activity
- a brief talk to break the ice asking something personal and easy to the user (your working day, your hobbies, etc)
- introduction to the project and the prototype and how you are going to assist him/her
- use the prototype by means of specific tasks outlined ahead
- little debrief, opinions and considerations, then a big thank you alongside the gift
Conclusion #
As in every strategy, thereās something good to take away and something that needs to be changed. The Design Sprint from Google is no exception.
The good part is the focus of the process, that need to be conducted without external distraction. Also, the idea to put together different people in order to create a diverse team is a very useful approach.
I wouldnāt be strict about the details (the crazy eight, the HMW, the voting system, etc) since it really depends on the project.
Based on my experience managing few sprints so far, the most important thing is about to book a focussed time frame with a diverse team. The schedule of the Design Sprint is a good starting point but you donāt have to adhere strictly. Itās much better to follow the path the team is drafting over time because if it happens it means itās required and itās good for the final outcome.