Anatomy of a Design Sprint

1. Quickly validate hypotheses and learn about your users' behaviours and preferences.
2. Transform existing pain-points in the customer journey into opportunities.
3. 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

1. Leave an hour at the beginning and end of the day for everyone to get on with their ongoing work.
2. No devices allowed, people have to pay attention and be 100% in the room
3. Everything is time-boxed and you should move on as soon as the time is up
4. 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.
5. 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.
6. Every major decision is agreed through voting, everyone gets a vote but ultimately the Decider makes the final decision.

How Might We

The ‘How Might We’ technique of phrasing problems is borrowed from IDEO's user-centric 'Field Guide' 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.

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.

Storyboard

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.

Prototype

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.

User testing

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 summary

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.