Today we’re going to talk about a certain very effective process that, if done right, you can use to great advantage – a design sprint.

The article is split into two parts – first you’re going to get to know everything about the standard on-site design sprint and how to run it.

Then we’re going to take a look at running a remote design sprint as there are quite a few challenges that can ruin the whole process if not addressed.

3,2,1 let’s sprint!

What is a design sprint?

A design sprint is a four- or five-day process with the goal of answering a certain question or problem, prototyping the solution, then testing it with users before going into serious development.

It’s a shortcut that allows you to gain crucial insights without building and launching.

You start with something vague, and finish with real feedback and something extremely tangible in the space of just a few days.

The design sprint was developed at Google and Google Ventures, after which it was popularized by Jake Knapp’s 2016 book Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days. The author describes the process as:

“The ‘greatest hits’ of business strategy, innovation, behavioural science, and more — packaged into a step-by-step process that any team can use.”

Why should you use a design sprint?

Although the initial premise almost sounds like a get-rich-quick scheme, design sprints do work. Big players like Google, Airbnb, Uber, and Lego all use design sprints as part of their toolbox for validating ideas.

Take a look at this scheme:

This is why you run a design sprint. In just a few days, it will help you and your team to:

Understand the problem you are facing and help you to pick the most important area to focus on.

Ideate and sketch out possible solutions.

Decide which solutions are feasible and turn them into hypotheses.

Prototype and bring your solution to life.

Test it with your users, get feedback, see if you’re on the right track, improve it or return to the drawing board.

A design sprint ensures that the solution you end up developing is user-centric and actually solves a real problem. That alone minimizes the chances of your new product or service being a total dud, which is pretty good news for your business’s cash flow.

Yep, design sprints have become popular for good reason. You might want to give them a go yourself and, in order to do that, you’ll need a team.

Pick your design sprint team

A design sprint is basically a condensed project, so you’ll need people who would normally work on such a task. Specific roles depend on your individual needs, but here’s a general overview of the people who should participate:

A decision maker. Someone with the power to call the shots and move the project along once the sprint is over – usually an executive of some sort. They should be involved in discussions even before the sprint begins to confirm the goal of the process.

A facilitator. This one might be you, if you’re organizing the sprint. The facilitator’s job is to track time, progress, keep things moving and stick to the schedule as closely as possible.

User researcher or customer service. Someone who has a deep understanding of your users and customers is invaluable for a design sprint.

Experts in the necessary fields. You’ll probably need a marketer, a designer, a developer, an engineer, and sometimes a financial expert if you have strict budget constraints.

Think about which roles you need to fill and choose the people who will be taking part in the preparation phase, which comes next.

Preparing for a design sprint

Some might see pre-sprint prep work as being counterintuitive. Shouldn’t a design sprint be this self-contained, super creative process? No, not really. Diving right into it with no prep done is a surefire way to run a very inefficient sprint, and nobody wants that.

By doing the prep work that I’ve suggested, you’ll enjoy two huge benefits:

Get to know the problem and the users

If you go by the book, understanding and defining the problem that you’re trying to solve is something that you’d do on day 1 of the sprint. However, in order to shorten the process, we’ll do it before the sprint.

First, familiarize yourself with the challenge at hand. Talk to key people to improve your understanding, look at data or analytics, and even conduct some interviews if necessary. Problem framing is key in setting the stage and getting everyone on the same page before you begin with the sprint.

Define a long-term goal that will serve as your beacon during the sprint. This will help you to define why you’re doing it and prepare you for the challenges that you’ll need to overcome along the way.

If your goal is to “boost user satisfaction and word-of-mouth marketing”, then one of the sprint questions should be “What will motivate our users enough to recommend us to their friends?”.

After you’ve got your goals and questions, gather relevant user data and conduct more research if needed. You should pinpoint crucial pain points and desires.

I suggest that you create an empathy map. It’s a visual way of understanding your customers and it will come in handy during the sprint. It’s great for identifying, prioritising and emphasizing certain points at the start of the process. Here’s my empathy map template and canvas to help you out.

Depending on the problem you are solving, you may also want to create a customer journey map to visualize your customer’s experience with your product and pinpoint specific areas that you want to target and improve.

Send out a design sprint brief

Defining the problem and understanding your user’s needs will help you to pick the right people for the solution. Once you’ve got your team, send them a design sprint brief.

The brief should include:

✅A short introduction to a design sprint and its benefits.

✅The task at hand, e.g. “We want to explore ideas for improving [insert your challenge] because [insert your reasons and findings]”.

✅The expectations, e.g. “When we finish the design sprint, we expect [insert expectations – solutions, prototypes, answers, user feedback, better understanding, etc.]”.

✅The schedule.

✅A checklist of things to do before the sprint. Don’t give them too many tasks – let them be related mostly to the tools you are going to use or to some essential reading.

✅Any final remarks.

Such a brief will align participants’ expectations and introduce them to the challenge ahead.

Now we’re ready to take a look at our day-to-day plan. But wait… I almost forgot some basic prep stuff! Make sure you:

• Book your team’s calendars for the days that you need them.
• Have enough whiteboards and dry-erase markers.
• Have plenty of post-it notes. Better to have too many than too few.
• Tell your team to leave their phones in a box or somewhere else out of reach during the tasks. You want them to stay as focused as possible.

Ok, now we’re ready!

A day-to-day plan for an on-site design sprint

Day 1: Ideate possible solutions

You’ve briefed your team before the sprint so they know what to expect. Now it’s time to present the problem that you’re facing, along with the long-term goal and the empathy map that you’ve created. You’ve done the groundwork before the sprint, so this should be fairly quick.

After this, use the How Might We method to transform problems into opportunities.

If your users are satisfied with your product but do not recommend it to their friends, you might ask: “How might we reward our users if they recommend our problem?” or “How might we make it easier for our users to recommend our product?”.

Once you’ve got your opportunities, use a voting system to prioritize them.

If you discover that there is more than one problem, now’s the time to decide which one is going to be targeted in this sprint. Who is the most important customer? What’s the most critical part of your user experience?

The outcome should be one target customer and one specific problem or aspect of user experience that you’re trying to solve or improve.

Now, take a break, have a coffee ☕ and get ready for a round of…

Lightning demos

Encourage everyone to research competitors and find examples of existing solutions to the problem that you’re facing.

Write down inspiring or interesting solutions and have each person give a lightning three-minute demo of their findings.

These examples are a perfect intro to …

The four-step sketches

This method is great for coming up with a solution while iterating each variation during the process. Schedule an hour and a half to two hours for this. It’s the last activity of the day!

Start with notes and ask each member to write down anything they can think of regarding the goal, opportunities and solutions that were presented earlier. Give them 20 minutes to gather this info.

Next, come up with initial solution ideas. Let everyone brainstorm and take into account the information that they’ve just written down. Another 20 minutes is enough.

Give everyone 8 minutes to pick their strongest solution and sketch 8 different variations of it. This part is called crazy 8s for a reason – it’s intense, but also fun.

In the last step, everyone should choose one of their solutions and create a more detailed end-to-end sketch. Use the next 30+ minutes for this stage.

After this exercise, you’ll have a number of fleshed-out solutions that are ready to be evaluated on day 2!

Day 2: Decision day

Start your day by strolling around the gallery of anonymous sketches created yesterday. Take a good look at each one and do it in silence.

Each member of your team is given three dot stickers, which they’ll use to mark the solutions or parts of solutions that they find interesting. This step is called the Heat Map.

You might even invite a real target user that has a problem that you’re trying to solve. That person should be familiar with your product or service, and able to understand the sketches after they read the design sprint brief. It can be interesting to see what they end up voting for. You can decide upfront how important their vote is.

Let each team member choose a solution that’s not theirs and quickly present and critique it. Use post-its to write down any important ideas that come up.

Now it’s time to vote! Usually, every member gets one dot sticker to put on the solution that they think is best. Let them briefly justify their decision. The decider often gets three votes and ends the voting process.

You’ve picked the solution that you’re going to work on, so it’s time for some drawing!

Create a storyboard

A storyboard is meant to capture the user flow of your solution in as few frames as possible, without leaving out anything crucial. It will guide your prototyping process.

You can do it as a team or individually, whereby each member designs a barebone storyboard and you vote on which one is best. If you know that your team will spend too much time discussing the storyboard, then the second solution might be a better choice.

That’s it for day 2!

You’ve got your frame-by-frame storyboard and are ready to move on to prototyping. You won’t need your whole team in the same room again, and anyone who won’t actively be working on a prototype can return to their day job. That’s a big win for the company!

Day 3: Create a prototype

This day is entirely devoted to creating your prototype. Put on your headphones, play some motivational music and get down to it.

Depending on the solution that you’ve come up with, divide your team into the following roles:

Creators – engineers, developers or designers responsible for creating the prototype.
Writer – product manager or marketer who is going to provide the text for your prototype.
Collector – someone that finds relevant images, icons and other content Creators might need.
Interviewer – a person that prepares the script for Day 4 user testing and interviews.

More often than not, it’s only the Creators who need to dedicate their whole day to prototyping, with the other members helping them as much as necessary.

Your goal is to create a prototype that appears realistic to users, but doesn’t require too much time being perfected. Creating mockups using a combination of Sketch, Keynote and Invision should do the trick.

At the end of the day, update the whole team and let them examine what they’ve created and achieved after only three days.

Day 4 will be devoted to the most valuable part of the sprint!

Day 4: User feedback

As I’ve mentioned in my product testing article, testing with five relevant users is usually enough to identify the vast majority of problems and obtain solid feedback.

Let the users go through the chosen tasks, make note of their progress and comments, then interview them. The article I’ve just mentioned contains some useful tips for different product testing methods.

Try to simulate a real world environment and don’t have the whole team standing in the room at the same time. It’s better to record the tests and let your team watch them later or in a separate room.

Analyze the feedback and emphasize the most important insights. Ideally, you’ll do that as a group. Look for patterns and themes, prioritise the findings and address them in the next iteration of your product.

Aaaaand that’s it! You’ve got your first prototype. You know what to work on next and you have a lot to show for four days of work!

But what if you can’t meet in person? Can you still run a design sprint? Sure you can!

Let’s focus on tackling the challenges of a remote design sprint!

How to run a remote design sprint

The basic principles are the same, so we won’t repeat them. Instead, we’ll concentrate on the key differences and challenges for which you have to be prepared. The main ones are:

• Time zone differences and team availability.
• Low engagement and focus in front of the computer screen.
• Tech-related issues.
• Ineffective collaboration due to lack of a sprint room.

Prepare for your remote design sprint

In the case of a remote sprint, you should absolutely do the prep work that we mentioned before. Familiarize yourself with the problem, research your target users, create an empathy map and send out a design sprint brief.

Next, schedule a short call with each participant. Go over the brief together, answer their questions and make sure that they understand the process and what’s expected of them. You should also ensure that they know how to use the tools that you’ll be using. I really recommend doing this – it pays off big time!

While you’re getting a team together, think about having a co-facilitator to focus on the people and levels of engagement within the group – someone who can reach out to anyone who’s not participating or is experiencing problems.

Julia Jackson from Wily explains why this is a good idea:

“All of our remote sprints include a facilitator and a minder. The minder is the point of contact via chat, phone, and text and checks workspaces to see if any team members need help. The minder also scans Zoom to check participants’ body language (nodding with agreement, furrowed brow, head down or turned away) to see who is engaged, tracking, or potentially lost. After we give instructions, we ask for a quick thumbs up or down before moving forward. If team members are confused, the minder jumps in and provides a new voice to explain and clarify the activity.”

You’ve already made two huge steps towards a successful remote sprint. Are you ready to take on the biggest challenge?

Time zones and scheduling

Figuring out a schedule that works for the whole team is crucial when running a remote sprint. You don’t want people working super late or super early; it’s not productive and it’ll make them hate design sprints altogether.

So, what do you do if your team is distributed across different time zones?

During your prep calls, ask people for the earliest and latest hour that they’d like to work. Use this to find your ‘together time’. World Time Buddy is perfect for that.

A remote sprint is usually doable if the time difference between all team members is no greater than nine hours or so. That means a session would start at 8 AM for the ‘earliest’ member and at 5 PM for the ‘latest’ member. Not ideal, but workable.

But what if your team is significantly distributed? Then you’ve got a problem. There are two options:

Run two separate sessions and compile all of the results in one place. When there’s a very important decision to make, someone needs to make a small sacrifice and stay up late or get up early.

Split your team and run ‘competing’ sprints to solve the same challenge. Let them share their progress and have a few overlap calls, but otherwise let them come up with their own solution. Having multiple options and more feedback can actually be beneficial.

The structure of a remote design sprint

Your ‘together time’ is set and the design sprint process has already been cut down to four days, which makes things easier.

However, four days in a row can be too much for some companies, especially lean businesses that can’t afford to dedicate their team to the sprint process for that long. If this is the case and the usual design sprint structure is a deal-breaker, extend the sprint to two to four weeks.

The structure remains the same, you just give the team some days off between sprint days for their regular work. You’ll still prototype and get user feedback faster than usual, the team will still become familiar with the design sprint process, and you’ll make it easier for executives to confirm your plan.

Once they see the benefits of the sprint, you can think about shortening it the next time you run one.

Now, let’s structure the tasks.

A remote version of the design sprint should consist of both synchronous online sessions and asynchronous offline work, which allows for better flexibility.

Day 1 – Everything up to Four-Step Sketches should be done together. Once everyone has presented their Lightning Demos, you can log off and create your solutions individually.

Day 2 – You should pick a solution together. After the session, everyone can create their own storyboard and vote for the best one before day 3. You can also create a storyboard together if you think that some team members will have problems creating their own.

Day 3 – The prototyping team should have an online kickoff session, but the structure of this day is really down to the Creators’ preferences and how much work can be achieved individually.

Day 4 – What you do on this day depends on whether you’re conducting user testing and interviews either in person or online.

This structure doesn’t require the whole team to be in front of a screen all the time, which is always a plus. It also allows for some flexibility.

Even if day 1 and day 2 begin as late as 5 pm for one of the team members, your online work should be finished by 7 or 8 PM. There is no need for that person to complete any offline tasks right after the session (as members in other time zones might choose to do); they can easily do them in the morning so that they don’t have to work super late.

On to the next challenge!

Choosing the right tools

Don’t worry, we won’t go into the nitty-gritty details of each tool. It’s impossible for me to say what the ideal tool would be for your specific team.

Just make sure that:

1. Everyone knows how to use all of the important tools.
2. Everyone actually has or can get all of the tools for the sprint.
3. No one really dislikes one of the tools for a certain reason. It might be a big turnoff for that particular participant, and you don’t want any grumpy team members.

The most important tool is your online whiteboard, which can actually offer an advantage over in-person sprints. It gives you an infinite amount of space and saves everything you do. The two most popular choices here are Miro and Mural. I’ve linked to their design sprint templates, so take a peek and see which one you prefer.

You’ll also need a collaborative and live prototyping tool like Figma. An all-in-one workspace, where you can keep your notes, tasks and everything else, will also come in handy – Notion is a good example.

The next big one is your choice of user testing tools. UserTesting and UserInterviews are solid options depending on what you need. You can also perform interviews via Zoom, Skype, Hangouts, etc. I suggest that you ask your users what software they’d prefer to use.

These are the not-so-obvious must-haves. Of course, you’ll also need something for your calls, scheduling, etc., but I’m pretty sure you already knew that. 😉

You’ve got everything you need for your remote design sprint. Now all that’s left are some pro tips!

Tips for running a seamless remote design sprint

Create different work areas

Each participant should have their own digital workspace. It helps people to stay focused and gives them the feeling that they are part of a special process, instead of just working in Word as usual.

Use your virtual whiteboard to create separate spaces for activities as well. This gives your team a visual roadmap and also serves as a progress bar as different areas fill up with ideas and solutions.

Provide examples

If there are sprint newbies on your team, they’ll probably love a few examples of what they should be doing. Link to some great four-step sketches and storyboards in their digital workspace, so that they can see what the outcome should look like.

Mandatory video sharing

It might seem a bit harsh, but if you want people to remain focused, you need to be strict about it. Otherwise, you’ll have people browsing the web in no time. It also enables your co-facilitator to see what’s going on and assist anyone who is looking confused.

Give people micro jobs

If you want the whole team to become more invested in the project, make each person responsible for a small piece of the experience. Ask someone to keep time, someone else to create a playlist, another person to handle conference links, and so on.

Select a single source of truth

Make it clear that a particular software or document is the place to turn to when someone is unsure about the process, instructions, progress, etc.

Create some call rules

Make an agreement that everyone should work from a quiet room or mute their microphones when participating in a group call, as well as decide on a simple way to signal when someone wants to interject. You can create other rules, but these two alone will significantly improve your call quality.

Huh, almost done. Let’s finish this article with some key takeaways!

? Recap: Why run a design sprint

It puts your users at the core.

You are designing a solution for them, so a solid understanding of their wants and needs is mandatory and their feedback is the most precious thing you’ll get from the process. You CAN’T run a sprint without it being user-centric, which is great.

It considers all perspectives.

A whole team of experts is gathered in one place, which makes it much harder to miss something important.

When you want efficiency, a sprint might be what you’re looking for. No long meetings or waiting on someone to make a decision. You’ll have tangible results in four days.

It lets you learn fast and fail fast.

The sprint forces you to make critical decisions and solve complex problems quickly. This will often save you months of design and development costs.

Running a design sprint is intense, fun and most of all very useful. If you haven’t tried it yet, please do and let me know how it goes. 😉

Do you need help with setting up the workshop? I can help. Comment below or send me an email.

? Oh hey,
I’m Romina.

Design strategy consultant. Founder of DesignStrategy.guide and NUEVA / design studio.

I am a Design Strategist who holds a Master of Business Administration. I have 15+ years of career experience in design work and consulting across both tech startups and several marquee tech unicorns such as Stellar.org, Outfit7, Databox, Xamarin, Chipolo, Singularity.NET, etc. I currently advise, coach and consult with companies on design strategy & management, visual design and user experience. My work has been published on Forbes, Hackernoon, Blockgeeks, Newsbtc, Bizjournals, and featured on Apple iTunes Store.

More about me  *  Let’s connect on Linkedin  *  Twitter

Comments

comments