Tooling up for the Design Sprint

Everything you need to know before running your first design sprint

So you want to run a design sprint? Wise move!

We’ve put this article together so you can benefit from our experience and improve the quality of your sprints. The best way to get the most from your five-day sprint (or four-day!) is to be as prepared as possible. That way, once your sprint team are in the room on day one, they’re ready to go.

Before we dive in, let’s start with a brief overview of what a design sprint means to us here at Pack.


1. What is a Design Sprint?

The design sprint methodology was originally created by Jake Knapp, author of the Sprint Book and Make Time.

A design sprint is essentially an intensive but exciting collaborative process for solving problems in just five days. Ideas are explored and validated by working through a number of activities before testing out a finished prototype with real users.

It’s debatably one of the fastest and most effective ways to validate business strategies or product ideas and it helps to get real answers to some of those key challenges, all within a short period of time.

Want to know more? Find out what’s involved on our sprint page!


The different types of design sprint

Although there are some great resources out there to help get you started with running your first design sprint, it can still feel like quite a daunting experience, leaving you asking yourself the question, “Have I covered everything?”

 

With the introduction of the Design Sprint 2.0 by AJ&Smart, which reduces the overall process from five days to just four, this can also help create a sense of uncertainty about whether the approach you have chosen is the right one.


So which version of the design sprint should you choose?

Well, in all honesty, it really depends on the organisation you’re working with and the experience you have with running sprints. If you have never run a design sprint before and have a flexible client who doesn’t mind booking out the full week, it may be wise to stick with the original version.

There’s a couple of reasons why we’d recommend this:

Reason one: It will allow you and your team more time to work through the problems and get a feel for each of the activities.

 

Reason two: You’ll have more time to sketch out solutions and work up your prototype ready for your day of testing with real users.

 

Here at Pack, we personally prefer the slightly shorter four-day version. The reason being, you only need to get the key people in the room for two days out of the four which, for an organisation of any size, is not only more appealing but more manageable.

 

However, whichever version of the design sprint is your favourite, they both work a lot better when you’ve done some key groundwork and research beforehand.

 

Preparation is so important and yet so tempting to miss out. Don’t skip the planning!


Planning is king

The pre-planning required to ensure a successful sprint isn’t really mentioned in the Sprint Book, nor is it explicitly included within the 2.0 version either but trust us, you’ll be thankful you read this article because pre-planning not only keeps things running smoothly but also ensures your sprint is relevant and focussed from the off!

Here are the 4 essentials to bear in mind:

 

  1. Design sprints can’t exist without a clear problem.

 

  1. Doing a little research up front is important.

 

  1. Creating a map of your user journeys, prior to your sprint is really helpful.

 

  1. Having the right people in your sprint is vital.

 

Let’s break these factors down and explore them further!


1. Ensure there’s actually a problem that can be solved

Although this may sound like an obvious one, it’s important to ensure your client has a clear problem they need to solve. You can usually ascertain this by asking two simple questions:

 

  1. Does everyone in the organisation who is directly impacted by the problem understand it well enough?

 

  1. Is it a problem worth solving? If the response is ‘No’, to either of these, you may need to think about whether this is a sprint worth doing.

 

If the problem isn’t understood by the necessary people then any solution is more likely to fail when implemented (and that’s a wasted design sprint). Equally, if the resources needed to solve the problem outweigh the benefits offered by the solution, that’s not good business either.

 

Without a clear challenge in mind, things often fall apart and people’s time is wasted unnecessarily; all due to a lack of basic preparation.

 

On the other hand, by having a clear problem to solve going into the sprint, you’ll get the most out of the key activities involved and be able to keep timings in check.


2. Do some research upfront

The design sprint process is all about hitting a problem head-on, without the need for any research. After all, research is unnecessary, takes weeks to complete and is just another way to make some extra money right?

 

Wrong.

 

The truth is, doing a little research up front, can actually ensure you don’t enter a sprint completely blind. Research can avoid a situation in which every idea a client was hoping to work through gets systematically dismantled on day one, because you didn’t know enough in advance to warn them about it before entering the room.

 

In most instances, you’ll find the client will have already done their research and will be happy to share that with you ahead of the sprint. Then it’s just a case of organising what you’ve been given and extracting the relevant data you need. If, however they haven’t, then it’s a good opportunity for you to step in and do some yourself.

 

Knowledge is power!

 

For ideas about what that research should look like, check out our ‘Just Enough Research’ article here.

Two days will most likely be enough to cover what you’ll need. This way you can confidently begin your sprint knowing in advance there is a problem worth solving and you are prepared to tackle it.

 

In addition to this, by doing a little research up front, you’ll also be in a much better position coming into the sprint to provide clarity to the wider team.

 

You’ll not only have a solid idea of the problem at hand but you’ll know who the target audience is and also how the business aligns itself with them.


3. Start your map before you sprint

In both versions of the sprint, we are told to sketch out the journey map on day one.

 

However, as the guys and gals over at New Haircut highlight, to try and sketch out a map using a blank canvas can sometimes be a difficult challenge for some teams, especially the quieter members.

 

There can be long, drawn-out conversations around who the users are and which of them are primary and secondary. Conversations like this tend to sap time and much needed energy.

 

More importantly, once you’ve identified them, you need to look at how the business aligns with those specific user journeys. It’s easy to miss this as it isn’t pointed out in the original Sprint Book.

So how do you solve these issues and why are they important?

Creating a map helps to:

 

  • Build empathy

 

  • Provide a common “big picture”

 

  • Break down silos

 

  • Bring focus

 

  • Reveal opportunities

To start creating yours, you’ll need to invite two to three team members to a 2-hour virtual mapping session.

 

Mapping team members should include a Product Manager, the actual user or somebody who knows their needs well, and finally the Decider.

 

The session should start by first reiterating the challenge. You’ll then want to discuss who the key user groups are and focus on one to create the proto-persona for. This way you’ll have an outline of their behaviours, problems and goals and be able to refer back to them during the sprint.

Once they’re completed, you’ll move on to the map!

 

Your map will consist of two rows, one for the user journey section, which is where your proto-persona will sit, and the second is for your organisational (business) journey.

 

Just as it mentions in the Sprint Book, you’ll then start to visualise the current state of the user journey based on your client’s product. Working left to right, you’ll discuss the necessary touch points along the way.

 

Once completed, you then focus on the business needs and discuss how they will align and interact along the user journey. Although the user journey is the key focus here, it’s also important to draw connections between the two.

 

This is where the organisation’s activities, strengths, weaknesses, and opportunities come into play. Once completed, you’ll have a great starting point to talk through during your sprint and pick up any corrections or tweaks.


Assembling the right team

The Sprint team

 

You’ll need to ensure the people in the room with you not only fully understand the problem at hand but also have first-hand experience with it (or at the very least, a small section of it).

 

Testing with users

 

Another key point to mention is the recruiting of candidates for your day of user testing. Don’t leave it to the last minute!

 

This is something we felt was a little overlooked in the Sprint Book. Trying to recruit the right group of users with only a few days’ notice is almost impossible, so make sure you get a head start and organise them well ahead of your sprint starting.


Wrapping up

The team at Pack have been running workshops and design sprints for a long time.

Although we always thought we knew how to get the best out of our clients, we discovered along the way that getting the pre-planning stage right was key to a successful sprint!

By recognising this need and adding an additional ‘pre-step’ to our process with the planning phase, we found it consistently improved the sprints we ran and helped our clients achieve better outcomes.

We hope this can also help improve yours!

Happy sprinting people.

For more information about design sprints with Pack, please see our sprint page here.