Anatomy of a Design Sprint
- 11 mins read
Published on Saturday 8th April 2017
If you work in digital, you might have heard about Design Sprints. This article is intended to provide a short introduction, packed with the key details to help you feel more confident about taking part or leading one for your own team.
After reading this article we would recommend reading the book 'Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days' by Jack Knapp, who created the framework at Google Ventures - it’s easy to read and is full of amazing anecdotes.
What is a Design sprint?
A design sprint is a process which blends design thinking and lean principles, and helps teams focus on creating solutions which quickly tackle big business and user journey problems. All this, while maximising insight and learning through customer involvement.
Design sprints can re-invigorate your team and inspire innovative thinking. They are best used to solve big problems, rather than completely new business ideas or small UX/UI improvements, there are better tools for this.
One thing that differentiates it from other innovation & prototyping methods is that it is all done in 5 days - everything is strictly time-boxed. and it includes user testing as part of the workflow in order to validate the ideas, rapidly.
Some user research/understanding about your audience is needed beforehand, but the idea is that you do not need months of UX research before starting your sprint.
It is important to note that whilst it shares a similar name, a design sprint is not closely related to an Agile sprint, only that the term ‘sprint’ is used to indicate a fixed number of days with a clear deliverable at the end.
What are we trying to achieve with Design Sprints?
- Quickly validate hypotheses and learn about your users' behaviours and preferences.
- Transform existing pain-points in the customer journey into opportunities.
- Educate your team and stakeholders on Design Thinking, helping them understand what goes into framing a problem, understanding users and designing a solution with a wider understanding of your product ecosystem.
Rules of the game and your dream team
- Leave an hour at the beginning and end of the day for everyone to get on with their ongoing work.
- No devices allowed, people have to pay attention and be 100% in the room
- Everything is time-boxed and you should move on as soon as the time is up
- The team will have a Facilitator who will run the sprint and sometimes help the team focus. The rest of the team is comprised of experts that have a strong understanding of the product and the problem. Finally, there is one decider, and only one. This is the person who will ultimately sign-off the idea, and has authority to sign off budgets if possible.
- Reviewing is done by everyone in the room, there will be no ‘selling’ of ideas - they need to stand for themselves. Often, participants might not even know who came up with what, this is to reduce the pressure on wanting to please the boss or having the charismatic person mesmerising everyone.
- Every major decision is agreed through voting, everyone gets a vote but ultimately the Decider makes the final decision.
Day 1 - Understand and Define. Start at the end to define outcomes and anticipate failure.
How Might We
The ‘How Might We’ technique of phrasing problems is borrowed from IDEO User-centric Field book (Design Thinking). Throughout the day, everyone will take notes, but instead of just taking notes we will turn risks into opportunities. So instead of writing “We can’t do x” write “How might we (HMW) help users achieve x”.
Sometimes if the team have been working on the product for a long time, they can't see the wood for the trees, so this phrasing might seem like a small detail but it’s actually really powerful - turning your thoughts to solution-thinking, instead of seeing everything as a blocker.
Setting a long-term Goal
This is all about understanding the problem and framing the vision. We don’t have time in a design sprint to define the value proposition, or benefits to the business, so prepare these in advance. The goal should be derived from your vision, and time-bound; where do you want to be in 6 months, or a year?
What would stop you from reaching this goal?
Now it’s time for a complete change of state of mind. Be as pessimistic as possible, and ask yourselves ‘at the end, if we were to fail, what would be the main reasons?’, then write those thoughts down. Now that we have a long list of potential risks, select your top three or four (grouping them if possible) and turn those risks into opportunities using the HMW technique. This will be your brief for the sprint.
Mapping the user journey
We’re going to define a high level customer journey to understand all the actors’ involvement in helping your main user achieve their goal.
Actors are the individuals involved in making the customer experience happen. To find out who those actors are, you will have to step back a little, looking at the customer experience in context and consider what needs to be true for delivering a smooth customer experience. With the help of the experts in the room, you will be able to understand those actors and their responsibilities, and how they help to get the user through that journey.
Practically, on the whiteboard, you will first write your user, and then list all the actors underneath. Then, writing all of the actions and steps involved in delivering the customer journey between the actors and the end goal. This is a way to highlight the pressure points and assess the largest risks and bottlenecks in your customer’s journey.
Vote, prioritise, link back to the journey
Now, collect all HMW notes and organise them into key themes. Everyone will vote on those notes and the decider (key stakeholder) will get the final vote on the problem statement to take forward. Based on this, the selected notes are attached to the user journey showing exactly where to concentrate our effort for the next 4 days.
What have we learned?
We know where we want to get to. We have questions that helped us assess risks. We've created a journey highlighting touch points and pain points. We have prioritised our next steps.
Day 2 and 3 - Ideation and Decisions. Building on existing solutions, sketching ideas and prioritising.
Lightning Demo & Market Research
Now we have a clear understanding of the problem, we can look at how others are approaching it - through research; looking at how people have already solved similar problems and building on it instead of reinventing the wheel.
Everyone will research existing solutions to your problem and share their findings. While presenting, we will highlight the good and the bad. At the end, voting on the best existing solutions will help to retain focus. Looking at other sectors is highly recommended as it will help you get to the root of the users' needs
Alone together, we will sketch & ideate
This is the fun part, using everything that has been done before, we will refocus all our thoughts and data into creating solutions. All ideas will need to be documented in a way that people can understand without having anyone pitching them. This is achieved by creating user journeys in the form of eight vignettes, a sequence of images which represent the key steps in your solution, plus a bigger detailed sketch of one of those steps if required.
Copy can help make people understand it, but keep it short, the idea is that if people cannot understand your ideas without you pitching, then the chance is that it’s either weak or badly thought through.
This brings us to the end of day 2. Go home, have a rest and enjoy the satisfaction that you’ve achieved a great deal.
Vote and Decide
New day, new challenges! Everyone’s ideas are on the wall. Everyone will quietly vote on their favourite aspects. Once done, the team discusses each solution, concentrating on those with the most votes. If needed, the author can input if everyone really missed the point, but the facilitator should keep an eye on the clock.
Once all of the ideas have been reviewed, highlight the top level themes and concepts and stick them around the solutions, this will help the the decider make the final decision about which concept to take forward.
What have we learned?
We’ve understood how others have succeeded (or failed). We have solutions that answer our questions and we have prioritised them.
Day 4 - Fake it until you make it. Create a prototype as a learning tool to test your solutions
A storyboard is a sketched user-flow of all the key screens/steps in your solution, much like the vignettes already created, but with more detail.
Before going into storyboarding you need to get your user journey right and have a clear understanding of what you want to measure. This will help you focus on which parts of your storyboard need detail and which don’t, as well as writing your user testing discussion guide.
It should be clear to the team what needs to be tested at this point, but if in doubt - go back to your mapped journey and your sprint questions and look at the pain points.
Prototyping isn’t a wireframe or high-definition build, but something in-between. There should be enough styling so it looks credible, but kept as simple as possible to avoid wasting time. We’re testing ideas here, not a final product.
Prototyping doesn’t always mean digital prototyping. Your prototype could be a conversation, an organisation chart, some code, a plan, etc… prototypes are tools for role-playing with users, so be relevant with your format.
Day 5 - It’s not you, it’s me. Let's focus on users
If you aren't already set up for user testing and don’t have easy access to your audience, it is recommended to prepare yourself from day 1; starting by recruiting, working out incentives and locations. During the week you will have to carve out some time for recruitment and selecting the right people.
User testing is all about being clear on what you want to validate, but also not having fixed expectations - allowing yourself to be challenged. It is critical to match your personas and target audience, testing with your colleagues or family won't cut it, you have to test with the right audience.
During the session it will be all about framing the context properly, listening and empathising. We’re not asking users for solutions but we want to understand how they interact and react to our product. Make sure you are letting the users behave as closely as possible to their natural response to the prototype.
What we’ve learned?
We know what works and doesn’t, we’ve built confidence and we’ve learned before we build.
In 5 days, you will have a clearer understanding of your users’ journey and bottlenecks, pain points and key opportunities. You will have collectively created solutions that are desirable, feasible and viable by involving all stakeholders. Finally, you will have validated the value of solving your problem with real users, enabling you and your team to begin your next steps with confidence.
We are testing assumptions here and this is not the end of your journey, this is just to give you enough confidence to invest time and money into solving a problem. Design sprints are no silver bullet and the journey to a successful product can be long and challenging. Hopefully, Design sprints will give you a boost but it won’t replace product strategy, user research and iterative process.