A Design Sprint is a method developed by Google Ventures. Normally, the process takes 5 days. For the Garage2020-Amsterdam, we did a shorter one-day version based on this methodology.
The three teams from the second round in Amsterdam have done already a lot of research and interviews and it is time to start the idea generation phase and start building prototypes to put their ideas to the test.
Lars from Unless and Gabriela support the design process and have experience running one day sprints for multiple teams. They believe in this process because it forces quick decision making, it is a good way to test and validate early concepts with users, and it generates consensus within the teams.
The goal of the day is to introduce the concept of a sprint to the teams so they can keep on using these tools to further develop their concepts.
We want to share the steps we took and what you need to run your own short version of a Design Sprint with teams that have a clear problem definition but no idea generation yet.
09:00 – 09:15 -Introduction and Coffee
09:30 – 10:00 – Persona exercise (30 minutes)
10:00 – 10:20 – The 5 Why’s (20 minutes)
10:20 – 12:00 – Idea Generation (1.5 hrs)
12:00 – 12:30 – Pitch Ideas
13:50 – 14:10 – First Tweet
14:10 – 14:30 – Main User Story
14:30 – 15:00 Storyboard
15:00 – 16:00 Paper prototyping
16:00 – 16:45 Testing
16:45 – 17:00 Reflect on learnings
- Beamer for presentation (& presentation)
- Google timmer to keep track of time
- A roll of paper or flip boards
- Stickers to vote
- A bell
- A big room with a lot of wall space
- Someone to facilitate the process
- Enthusiastic teams
The teams prepared beforehand and chose a picture of the persona that will be the center of this design sprint. Even when a product may have several users we asked to choose only one, the main one. This way they can focus the design sprint in just one aspect of the product and it stays manageable.
This person will be the personification of their target-group. Every decision they take concerning design and concept should be for the benefit of this person.
Examples: Name, gender, age, profession, income, address, marital state, spouse, hobbies, motto, fears, dreams, last tweet
You can find a personas template made by Garage2020 here.
To help identify the root of their problem, we ask the teams to write down the user’s (persona’s) main problem. Then try to find a reason for that problem by asking ‘why’? Go deeper & repeat this 5 times to get to the core of the issue.
This exercise will help the teams to get in context for the next step which is Idea Generation.
For idea generation Lars looked up several techniques that would fit per team, since each team has a different problem type and needs.
The first step for all teams was to write down all the ideas they already have on the top of their heads. Making room for new ones, writing one idea per post it.
Then each team followed different ideation techniques, and once the board was full of post-its (around 50 ideas), they clustered per themes and made possible combinations.
Then we gave 4 votes per team member to decide on the best ideas and 2 ideas were selected.
What would your first tweet be to convince your persona to get to use your product?
Why a tweet? Tweets are short, to the point. This forces them to think of the value proposition. The tweet should be written from the user’s perspective and not from the product perspective.
10 minutes per team
The teams pitched shortly their persona, 5 why’s and then the two ideas to the whole group. The ideas were discussed and then the whole group voted for the best one.
They describe each step the user will take when navigating the main journey for the product.
This may seem like a simple exercise, but as you can read in this post, there are a lot of logical steps that we forget to take into account. Therefore, it is good to work with post its and leave plenty of step in between steps to be able to fill in any gaps.
Make a storyboard that shows how your persona will be interacting with your solution.
The idea is to sketch a quick comic book, showing not only screens but also when and where your persona will be using your app.
Tip: Use post-its for the panels, if you make a mistake; grab a new post-it.
Time to build a prototype!
A paper prototype is a technique that allows you to create and test user interfaces quickly and cheaply.
The teams use the storyboard as a guide for their prototype screens with pen and paper. Prototyping with paper forces you to think of tangible solutions and brings to light aspects that were not yet considered.
Tip, Skip log ins and Sign Ups. Some elements of the UI are the same in some screens, so you can trace them, or cut out pieces and place on top.
15 minutes per tester
For testing each team member needs to get a role:
- The robot: changing the (paper) screens as the user click through
- The facilitator: explaining, guiding and asking questions
- The writer: documenting observations and learnings
The teams have made great progress in just one day and the ideas developed and the learnings from testing will be taken into the loop again to the next Design Sprint Day in two weeks.
More fotos can be seen here.