This is a jargon-free guide on how to run a design sprint. I’ve facilitated hundreds of sprints this way with great success. It is a simplified variation of Google Ventures Design Sprint by Jake Knapp that you are probably already familiar with. I suggest reading the book and to get an in depth understanding of why this process is so effective.
What is a design sprint?
Design sprints are a Design Thinking process that help solve problems, using rapid prototyping. It’s essentially a workshop that’s run over the course of five days. It’s purpose is to test an idea as quickly and cheaply as possible. It’s a great way to tackle problems for digital products. When used as an on-going process in a team, it can become a very effective way of working. UX Designers commonly employ this process in agile teams.
The best thing about a design sprint is it gets your team to focus on a specific problem. Without distraction. Building and validating an idea would normally take months. A design sprint allows you to find an answer to that in just five days, with evidence to back it up.
The benefits of running a design sprint:
- Test ideas in a matter of days
- No development or coding required
- Get different team disciplines working together
- Put research at the heart of the problem
- Get stakeholder buy-in
For a more in-depth knowledge in design sprints and how to run them, read Jake Knapp’s book, “Sprint”. You don’t need to be a UX Designer to run a design sprint!
Day One: Understand The Problem
Day one is all about understanding as much about the problem as possible. If you don’t know anything about the problem you are trying to solve, it is difficult to know how to begin solving it.
A design sprint is only as good as the research you bring to it
Everyone should bring research and insights to day one of the design sprint. This might be in the form of desk research, user research insights or analytical data.
At this stage in the design sprint you should invite a subject matter expert. They can give specialist insights and answer questions you may have.
If you run a design sprint without good quality research around your problem area, you won’t be solving real problems. Effectively wasting your time.
Share the research with each other
Firstly, each participant in the design sprint will give brief talks on the research they have. Everyone else listens and writes down problems they identify on post-it notes. These problems should be framed as questions. These are called ‘How might we’ statements and help spark ideas on how to start tackling a problem.
For instance, a problem might be:
“Our heatmap data is showing us that people aren’t scrolling down the store page.”
However, this could be rewritten as:
“How might we encourage scrolling on the store page?”
Decide on what problem to tackle
Secondly, everyone’s post-it notes are stuck on a wall and grouped into themes. This is called “Affinity Sorting”. The group then collectively decide on which problem they feel has most value if solved. This is often done by ‘dot-voting’. Each person gets two votes and puts a dot against the problem they feel is most valuable to solve. You can vote twice on the same problem if you feel it’s important!
In conclusion, your group should now know which problem to begin tackling tomorrow.
Day Two – Diverge
Get your thoughts down on paper
Diverging means going wide or branching out. Today is about getting as many ideas out of your brain as possible. Firstly, spend the morning with everyone going over the notes from yesterday. This is a chance to soak up everything that is relevant to the problem at hand. The next task is to dump all your thoughts on a piece of paper, so get everyone creating a mind map. This should take no more than half an hour.
Come up with lots of ideas
The next step is to start an exercise called ‘Crazy Eights’. The idea is to draw or write down one idea every minute, for eight minutes. It’s easier than you think when you’ve spent a whole day priming your brain! Use your mind map to help you if you get stuck.
It’s important to remember that you don’t need drawing skills in a design sprint. If you can draw a box and a line; you are good to go!
After eight minutes, share your ideas amongst the group. Sharing and bouncing ideas off each other is important at this stage. It helps grow and shape ideas for the next exercise.
Add more detail to your favourite ideas
You can do Crazy-8s one more time if you wish, or you can move straight to the ‘T-bar’ exercise. The point of the T-Bar is to flesh out your favourite idea further. Taking inspiration from others’ ideas and feedback.
A T-Bar is your idea on a page. A title, description and a quick drawing. It should make sense to someone without having to explain it out loud.
Work up at least three T-Bar ideas if you can. Once complete, stick up the ideas on the wall, in any order. Briefly share and discuss each idea. It is now time to dot-vote again. You should take forward as many ideas as there are people in the room.
Storyboard your top idea to explain how it works
The last task of the day is for each person to work up one of the ideas into a three post-it storyboard. This task is designed to eek out more detail about the idea. By showing the idea in a sequence gets your brain thinking how it would really work.
Using post-it notes also helps consider your idea from a mobile-first perspective. It also forces you to keep your content short and to the point.
Under each post-it, describe what happens in the step with clear bullet points. Don’t forget to title your idea!
Get feedback on your idea
The next step is to stick them back up on the wall. Each individual takes it in turns to talk their idea in detail. Each listener writes feedback on a red, blue or green post-it. This feedback method is called Rose, Thorn, Bud (RTB). It is a great way to reflect on something constructively.
Rose is something you think works really well.
Thorn is something to watch out for or avoid.
Bud is an opportunity to explore something further.
Stick up your feedback post-its on the ideas. The owner of each idea should try and take this feedback on board and draft a second version of their idea.
Decide together on which idea to take forward
The last task of the day is to share back your final idea, and dot-vote again to whittle down to the winning idea. If there are two strong ideas, it’s okay to take both forward.
Set down the post-it notes and pens, the day is over. Your brain might be a bit fried so get a good night’s sleep!
Day Three – Converge
Today is all about fleshing out yesterday’s winning ideas into even more detail. Converging is a day where everyone comes together and works on one thing. By the end of today you should have enough detail to get your head down and build a prototype on day four.
At this point you may only have one idea you want to run with, or two. In which case, split into two teams or pile into one.
Write down your assumptions
Your idea, by the nature of not being tested with real people; is an assumption. It’s a good point in the design sprint to pause and consider your assumptions.
An assumption is something that you assume to be true, even without proof. It’s important to make sure you seek the truth for your assumptions. If you build something with without evidence, you could be building the wrong thing.
An example of an assumption might be “Our customer cares most about X when using our product”. How you test that might be in a user interview, asking “What do you care most about when using our product?”
The assumption will be proven or disproven from speaking to your users. An assumption with evidence is now an insight. With enough insight it becomes a fact. No one can argue with facts!
It is a good idea to collect these assumptions as you go.
Before you start fleshing out the idea, ask the group:
- What are our assumptions that we want to test?
- How do we test those assumptions?
- How do we know if our assumptions are valid?
Answering these will help you understand what you want to learn from your prototype.
Start sketching your storyboard
Now you have a focus of what you want to test, start by picking up a stack of post-it notes. You are going to create another storyboard but this time you aren’t limited to three post-its. Use as many as you need to describe the user flow of your idea. Keep in mind the assumptions you want to prove or disprove.
Question each other’s decisions
Ask, “why?” a lot. Ensuring you can articulate why you’ve made a decision is important. If you don’t know why you’ve designed something the way you have, it won’t have any intent.
“Why have you put that there instead of here?”
“Why do you think saying it that way is better than saying it this way?”
“Do we know if they know that acronym?”
“What if they want to do X? Have we thought of that?”
It’s good to have a healthy debate about what the flow should be. This will lead to a stronger prototype. It will ensure you have thought about every aspect of your storyboard.
Test your storyboard as you go
At this point it’s useful to put your storyboard into a rapid prototyping app like InVision or Marvel. Doing this allows you to test the flow and iron out any kinks. Keep iterating until you are happy your paper prototype.
Invite stakeholders to get a different perspective
Now is a great opportunity to invite stakeholders into the design sprint to get their feedback. The more diverse range of voices you can bring in the better. Perspectives from other disciplines will give you insights that will improve your idea. This could be from marketing, or legal, or anyone you might not immediately consider. Don’t forget to tell them to leave their laptops and mobile phones outside!
Encourage your experts and stakeholders to use the Rose, Thorn, Bud format. Implement the feedback as you see fit, and finalise your storyboard. You should now be in a good place for tomorrow and should be confident in what you’re going to create.
You’ve completed day three of the design sprint!
Day Four – Make the Prototype
Prototyping day is the easiest day. It’s time to get your headphones on, knuckle down and start building your prototype. This is where UI / UX designers come into their own.
What prototyping software should I use?
There are a lot of options when it comes to prototyping software. The simplest and quickest to use is InVision. For prototypes that need a bit more interactivity, I recommend proto.io. Both are free to use!
A prototype is like a movie set in a Western film
You are building a facade, it only has appear to look like it works. It’s important that the person using your prototype believes it is real. You can forgive any lacking features by saying it’s still a work in progress if they hit any snags.
The content is more important than visual design
Don’t use dummy content like Lorem Ipsum. Make sure you craft what words you use in your design. Above all, what your users are reading is important for communicating your idea. Who would’ve thought!
One last tip: make sure your prototype works on a real device.
Day Five – Test With Users
Plan ahead to get in front of your target user
It’s a good idea to plan ahead to make sure you have participants for the test day. You want to test your prototype on people that have the problem you are trying to solve, otherwise you could end up wasting your time. A car insurance app for someone who doesn’t drive won’t yield very useful insight!
Guerilla testing is fine
If you aren’t able to get a hold of your users or customers, there is another way. Go in pairs to coffee shops, and politely offer to buy someone a drink if they’re happy to test an idea you have. This is a cheaper and quicker way of testing your idea. But you won’t get insights from your target audience, unless it’s a coffee-related idea!
Test your prototype with six people
You only need to test with five to six people. This is a standard amount of people to test with. Beyond six or seven, you start to hear the same thing. A few minutes with a few people will highlight bugs and usability issues quite quickly. You’ll soon learn if your idea is working, or not.
How do you test your prototype?
A good way to start is asking questions to understand your user’s context. It has to be relevant to understanding if your idea will resonate with them.
- Are they currently facing the problem you are trying to solve?
- Is the product relevant to their situation?
- Is it an area they have an interest in?
Tell them you have been working on something, and politely ask if they’d like to try it out. Depending on what your prototype is, and the context of the user, it might be suitable to set them up with a situation. Give them the prototype on a real device and give them some context.
What kind of questions should you ask users?
If you have a familiar problem you are trying to solve, you might for say “you’re looking for a place to stay when visiting X”. You then give them the prototype and observe them.
If you are testing a brand new, left-field idea, and you want to see if they understand the concept from the prototype alone, simply ask “what do you think of this?”
If your prototype is very task based, ask them to complete it. “You’ve just bought a home and you need home insurance. Can you try out this website and see if you can buy it?”
Update the prototype as you go
Don’t be afraid to update your prototype if you find people are stumbling. This is important if you are testing an idea because you don’t want usability to get in the way of the core concept.
It’s especially important if you are testing an interface idea because by the end of the design sprint you’ll have something robust enough to start building!
How to record feedback from user testing
Note taking is an important but of user testing. However, try not to take notes in front of them. It is distracting and they’ll be thinking more about what you are writing, than the thing you are trying to test.
After each test, recap with your partner and write down the problems observed. Consider the opportunities you’ve seen and heard too.
When you’re all done, write up the groups findings and share what you learnt with the team.
What happens after a design sprint?
You will have either learnt you are on the right or wrong track. You should have enough insight to make a decision. To either pursue and iterate the idea, or pivot and change course.
Output from the design sprint should be a set of recommendations that inform the direction of the idea or product. These recommendations are a simple set of “do’s and don’ts”. You’ll be able to articulate why, because you of the insights you gained from testing with users.
If the idea failed – you learnt that in the cheapest way possible. If the idea was successful – you now have evidence to invest time and money into taking it further!
Your next steps could be to run another design sprint, or take your prototype into production. As long as you test often and don’t ignore big assumptions you have – you’ll be just fine.
