Win a design sprint with Dynamo!
At the latest Sthlm Tech Meetup, we announced our competition: Win a design sprint with Dynamo!
How to enter:
Send your Pitch and the reason why you deserve to win a design sprint to firstname.lastname@example.org
Deadline: 29th of May!
The requirements to enter are:
1. You are fully committed
2. You have a team
3. You are preparing for the next big step
The winner will be announced at the Sthlm Tech meetup the 7th of June
But, what is a design sprint?
A product design sprint is a 5-step design process pioneered by Google Ventures and adopted en masse in the tech industry. It involves having a group of people work together to create product and feature ideas through ideation, consensus, prototyping, and user testing. It’s different from, for example, design by committee in the sense that its thorough process makes sure that everyone is trying to solve the same problem and has the same priorities. Since there needs to be a decision maker who can continuously move the process forward, the product owner has the final say after group votes and critique. The Design Sprint is generally a 5 day process, however it can be flexible to the user’s needs and/or limitations.
Design Sprint Checklist to Get Started:
- A white board
- 3 participants or more
- Product owner
- Anyone can participate
- Sticky notes, A4 paper, sharpies, dot stickers
- Research about the market, target audience, competition, trends, and the problem to solve
Day 1 – Understand
Gather and present as much information as possible to everyone involved. Then create a 1-liner or an elevator pitch of the problem the team is trying to solve. We suggest using simple and straightforward language, with the goal that anyone passing by should understand it just by reading it. This is not a marketing message, so keep buzzwords out!
Then it’s time to define the target audience: their lifestyle, their priorities, their preferences. Try to avoid defining just by age, gender or location. People are different. “Everyone” is not acceptable.
Start an assumption table. Whenever someone claims something that is not backed up by any evidence, make sure to write it down to keep track of it, and to be able to verify later on whether it is correct or not.
Day 2 – Diverge
The goal for day 2 is to generate ideas and concepts through a series of timed exercises such as Crazy-8, 3-panel storyboards, and word clouds. It is important to let your imagination loose and to know that no idea is a bad idea. Throw budget and feasibility out the window – there are no limitations!
Remember, this is not brainstorming, and each participant is expected to work alone during the individual exercises. Further, you are not allowed to judge other’s ideas at this point.
Day 3 – Converge
At this point, we are allowed to critique, as a group, the outcome of day 2 and distill it into one or a few user flows that seem to solve the problem best. It is important here to not take criticism personally and be honest. A great voting system is to use dot stickers to create “heat maps” of the votes.
Then go on to draw a giant storyboard that captures the user journey that you have decided on.
Day 4: Prototype & Test preparation
Now, use the assumption table to draft user tests that will help you validate or refute said assumptions. Prototype the user journey in an adequate fidelity level, depending on the complexity of the product or service. Sometimes pen and paper is all you need, and other times a clickable prototype is a better choice.
Not everyone needs to be involved in the prototype phase. Depending on how you’re implementing the prototype, it might just be one or two people working on it. Today is also the time to send invites to test users, explain what is going to happen, and book times for them to test your prototype the following day.
Day 5: Test
Test the prototype with the users. Focus on making them comfortable. Tell them that we are testing our ideas, not them. Listen! Take notes so you don’t forget anything important. Don’t ask leading questions. An example of a bad question is “Do you want to use this?” Instead, try to pose the question like “How do you think you can make use of this?”
Don’t explain how to use the prototype unless the user asks for an explanation. If they do, that’s a sign that more work needs to be done.
Why a Design Sprint?
It may seem that a design sprint is going to slow your team down by taking them away from their main work tasks to work on something that is not going into the product immediately. But in fact, doing a design sprint can actually save time. Since you test your assumptions and ideas quickly, you avoid the risk of spending months developing something just to find out that you built the wrong thing. By saving time, you are also saving money. And since the design spring will give you an early hint about the direction of your product, you can more quickly hone in on the idea that is actually wanted by your users and customers.
Additionally, working this closely makes the members of the team more comfortable with each other, and is a great ice breaker for a project.
Finally, by working with design sprints, you are learning a truly iterative process which can be applied at many different levels and scopes. These techniques can expand your thinking and help you discover, prototype, and test new solutions. With this tool in your arsenal, you may find yourself doing full design sprints for key elements of your project now and then, and even quick one-person design sprints over the course of a few hours. This is a habit that can really change your way of thinking about all sorts of problems.