The selling point of performing design sprints in your projects is somewhat self-evident: create a user-validated prototype in a very short amount of time.
This “Learn fast, fail fast” methodology, which was developed by Mr. Jake Knapp while at Google, is used or has been used by – well Google – and other top-notch companies across a number of industries (yes that’s right, design sprints do not belong solely to our guys up at Silicon Valley!).
Definition of design sprints
Quoting Wikipedia: “A design sprint is a time-constrained, five-phase process that uses design thinking with the aim of reducing the risk when bringing a new product, service or a feature to the market.”
Now, having provided the definition above, it is important to distinguish between design thinking and design sprints. While they appear to have the same roots (both are human-centric) they are not the same thing. Read this Medium article for more: Design thinking vs Design sprints, what’s the difference.
If you are not new to UX you might have heard about design sprints before as they have been around for about 9 years. Design sprints were, in essence, the evolution of the Lean UX and the Agile Development theories. They came to solve the serious issue that MVPs were leaving behind which was messy/not ready products that end-users were turning their back on. Thus, there was a transition from the MVPs to MDPs (minimum desirable products). Read this article for more.
Before the sprint 2 people must be appointed as a) decider and b) facilitator. The decider is usually someone with authority (e.g. CEO or stockholders) while a facilitator is someone with experience on sprints. The sprint team is recommended to be between 5-7 people but there seems to be a huge debate on whether design sprints are ideal for smaller teams or even extremely big teams.
Let’s get to the process
The process consists of 5 steps that each represents the 5 days of the week (Monday, Tuesday, Wednesday, Thursday, Friday).
Of course, it’s not necessary to start on Monday and finish on Friday. You could start on Tuesday and finish on next Monday (just don’t have many days in between the sprint days as you might kill the momentum). So let’s start sprinting!
The 5 steps are the following:
Step 1. Understand (1st day – Monday)
First things first. Understand why you gathered up. After the introduction try to make everything -problems, goals, user needs, framework, strategy, etc. clear to everyone in the room. You don’t have the opportunity and the time to have members in the group confused. For even better performance try having everyone informed before the sprint so that they can think about it.
Since the first day sets the tone for the rest of the sprint it comes as no surprise that it is the most critical day of the “week”. Drop the wrong problem on the table and even the best solution to it will be absolutely irrelevant. Now to avoid fatigue between members it is generally recommended to cut the day into 2 halves (morning, afternoon).
After the introduction and everything, consider beginning the sprint with these questions in mind:
What is your long term goal?
Where do you want to be in 1-2-6 months from now?
What if things won’t work the way you want to?
Write everything down.
Next, you will have to map out the process between your current state and your final goals. Try to keep it simple at this point, as you don’t want to have more than 8-10 steps in the flowchart.
Watch this video How to draw the map (day 1) to get further information about this substep.
Get the experts in the game: Before anything, you need to validate your map’s elements to make sure that you are on the right track. Of course, you will want to have improvements in your current map so try to act like a reporter and push things a little bit.
At this point, everyone in the room will have to have a “how might we ..” mindset and keep their questions on their papers.
When it is time, ask everyone to show their questions so that the best “target” will be selected (e.g. by voting). Note that, it is greatly suggested to look for any instability in your group dynamics. Even though the final decision will be taken by -well the decider, it is a common phenomenon to go astray.
Congratulations, 1st step is done.
Step 2. Sketch (2nd day – Tuesday)
Time to roll your sleeves! While Monday was all about finding problems, Tuesday will be about finding solutions. Now you might question where these solutions might come from.
Google recommends 2 ways: a) lightning demos and b) sketching. Again the day is suggested to be cut in 2 halves each half representing one way. What is more, you have to start thinking of the test that your customers will have to take on Friday regarding your target.
Morning (lightning demos).
Quoting Pablo Picasso “Good artists copy. Great artists steal.” That’s right. You got to go out there (not physically) and see what the competition is already doing on solving the “target”. Insert all these solutions under lightning demos each representing a company’s solution. Keep notes of everything!
For sketching 4 steps are recommended for each member working on private:
1. Take notes (20 min).
2. Come up with rough ideas and sift through them to find the best (20 min).
3. Create 8 variations of your best ideas (8 min).
4. Find the best sketch and create a storyboard with 3 panels. Make sure it is easy to read and comprehend (30-90 min).
Congratulations, 2nd step is done.
Step 3. Decide (3rd day – Wednesday)
Time for decisions! By now, your team should have had a pool of -hopefully great- sketches developed. This day is again recommended to be cut into 2 halves: a) decision on the sketch and b) decision on the prototype.
To decide on the sketch you need to recruit voting (strictly anonymous!). Have all the solutions gathered on the board and have your team vote on the best one. If there are more than 1 winning solutions you will need to design on whether you will make more than 1 prototype (not suggested if your team is small).
To decide on the prototype you need to have the team’s favorite solution (s) mapped out in great detail! To make this work consider the process like a puzzle where you only have the end goal and the first interaction pieces. The suggested number of the pieces you need for the successful completion of the puzzle is 10-15.
Congratulations, 3rd step is done.
Step 4. Prototype (4th day – Thursday)
This day is the reason your team gathered up in the first place. The prototype will be the first depiction of the solution and it has to be perfectly done but not perfect. To successfully make a working prototype you will have to delegate the tasks needed for the creation of the prototype. For prototypes think of using tools like Google slides, keynote, InVision, Adobe XD, Figma or even Useberry.
Congratulations, 4th step is done.
Step 5. Test (5th day – Friday)
Normally this step is a real pain for any team as it is relatively difficult and requires good knowledge of decoding customers’ interactions with your prototype. This is why we created Useberry, a tool that gives you rich analytics on your prototype and makes user testing a piece of cake without requiring hardware or anything else.
After the completion of this step, you will either drop the idea or you will move forward on making it a real product/service.
Congratulations, you have made it to the end of the sprint!!!
General rules for a successful sprint
Agree on things early on the process
This includes problems, questions, objectives – actually everything – that you need to set whole the thing up. It also includes the approach that everyone in the team is going to take in the sprint.
Sketching or stretching
Nobody’s chasing you. Chill out. Generally, in the ideation step, you need a lot of “juice”. What if you stop it too early and miss the next big thing? Try not to be so strict with the timer in this step and allow some time for self-reflection on the ideas.
Leave your ego outside
Competition is great. It is maybe the reason that your ideation process will be successful. However, keep in mind that competition might ruin your sprint especially when there is not a strict regulator.
While you have acquired some good knowledge of sprints you can always educate yourself further.
Our first recommendation is the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days written by Jake Knapp.
There are also some good programs on design sprints:
And even a Design sprint school 😀
Finally, you can join Google’s community for design sprints by going here.