The Ultimate Guide to Remote Design Sprints

Design Sprints are hard enough with everyone in one room — here’s how to run a Sprint with your distributed team

Just Mad
Modus
11 min readJan 16, 2020

--

Images courtesy of the author

Note: We assume you’re familiar with the four-day version of the Design Sprint. If not, go ahead and check out this article. We’ll wait!

Remind me, why Design Sprints?

Let’s get a quick refresher on why Design Sprints are so hot and gaining massive interest among product managers, designers, and anyone else working in the realm of problem-solving and innovation.

Short answer: They work.

Ever since its inception within Google Ventures and the release of Sprint, the book by Jake Knapp, many companies and agencies have picked up the process and made it part of their utility belt. Google, Airbnb, Uber, and Lego are just a few big players that have integrated Design Sprints into their workflow to ideate, prototype, and validate ideas fast.

Full honesty, the first time I read Sprint back in 2017 I was like:

Original photo by Quentin Dr on Unsplash

It was the answer to some really important questions that were plaguing me and my consulting clients at Just Mad:

  • How can we get from an idea to a validated prototype faster?
  • How can we make sure we’re designing the right thing before spending a ton of money building it?
  • How can we make more confident product decisions?

The Sprint felt like a game changer.

Everything was almost perfect, apart from one tiny aspect: 90% of our clients were remote, spanning from San Francisco to Melbourne. As a Europe-based consultancy, we needed to find a way to work with distributed teams to leverage the magic of Design Sprints.

So we did the only logical thing we could think of: find a suitable client and challenge, schedule a Sprint, follow the book to run it, and hope for the best.

The outcome? A disaster.

We didn’t know how to prepare, people were disengaged, and we had tons of issues collaborating and communicating.

Original photo by chuttersnap on Unsplash

The challenges of running Design Sprints remotely

  • Timezone differences and team availability. It’s hard to schedule and align distributed teams for long periods of time, as the Sprint requires intense work sessions.
  • Low engagement. In a regular Sprint, your team is working together in the same physical space, and keeping them focused and on point is easy. When going remote, your team is one alt-tab away from Slack or Netflix.
  • Tech-related issues. A sloppy internet connection, low-battery AirPods, and unreliable microphones can hijack your remote session.
  • Ineffective collaboration. In a Sprint room, you have the whiteboard as your single workspace. Remotely, things can get messy quicker than you can say “sticky note.”

We were thrilled by the idea of running Design Sprints, but we also loved remote work, as it was part of our company’s DNA. We knew we had to find a way to make them blend seamlessly together, like a well-rehearsed tango.

Naturally, we started looking for potential solutions, experimenting a lot, and inevitably making mistakes to find the right blend of tools and techniques to make remote Design Sprints feasible.

And we did.

The key to running successful remote Design Sprints: Break it up!

Your biggest challenge when it comes to running remote Sprints is definitely the Sprint structure itself.

In a regular, in-person Sprint you’d have a bunch of people collaborating and doing exercises together based on the following schedule.

Monday and Tuesday are both workshop days, where your team will go through various exercises for a whole workday, filling up whiteboards and drowning in sticky notes. Your prototyping team will take over on Wednesday, and then you’ll be running user tests to validate your ideas on Thursday.

I would like to focus our attention on Monday and Tuesday since they are the most intense and require the most work to organize and facilitate. All team members need to clear and align calendars and stay together for a fairly long period of time, which can lead to fatigue.

While this format works great for in-person sessions, some adjustments needed to be made to fit distributed teams. After many iterations (and truthfully, a few mistakes) we found the winning solution.

The updated, remote version of the Design Sprint features a combination of synchronous and asynchronous sessions, which allow for better flexibility.

This is what our remote Sprint looks like:

Days 1 and 2 are workshop days with the full team, but notice how the sessions are broken into chunks and we alternate between online and offline sessions. Day 3 is taken over by your remote prototyping team and Day 4 is used for user testing, whether you chose to do that in person or online.

(For the detailed structure of the exercises, timing, and instructions, check our Miro template linked below.)

Notice how we didn’t use Monday, Tuesday, etc., to label the days. This is deliberate, as when going remote you might schedule the days depending on the team’s availability and might not be able to start on Monday. Plus, we need to account for timezones that can place people on different days.

The simple, 3-step recipe to running and facilitating smooth remote Design Sprints

After successfully restructuring the process, we identified the three elements that will make your next remote Sprint run smoothly:

  • Correct preparation
  • The right choice of tools
  • Proper facilitation

Step 1: Preparing for your remote Design Sprint

The best way to destroy a Design Sprint before even starting is by neglecting the preparation phase, especially when you’re facilitating a remote session. We know that the Sprint is meant to accelerate ideation, prototyping, and testing, and while some might consider pre-Sprint work counterintuitive, based on our own experience, doing prep work is crucial.

Contextualize yourself with the problem

Once you know the Design Sprint is going to happen, it’s important to familiarize yourself with the problem at hand. Talk to key stakeholders and find out who is responsible for what on the team, and what effect they have in regards to the challenge. This will help you choose the right people for the Sprint and better prepare the session.

Building your Sprint team

The whole point of the Design Sprint is to get the right people to focus on the same problem together and generate solutions. Building the right Sprint team is paramount and will assure the success of your Design Sprint. You’re looking to get a team of five to seven people including yourself. The roles you’re looking for:

This would be an ideal mix for the Sprint team, but of course, you can adjust the roles depending on your needs and problem context.

Scheduling the calls

Aligning schedules is crucial with distributed teams. You don’t want to have people waking up at 5 a.m. or staying up until 11 p.m. We try to fit participants in a nine-hour window as displayed below. Also, it’s important to let people know when you’ll need them, and for how long. We use Doodle to schedule our sessions.

Pro tip: Use World Time Buddy for easy timezone overview.

Here are some examples of kick-off time combinations we use a lot:

  • 3 p.m. Berlin / 9 a.m. San Francisco
  • 3 p.m. Perth / 8 a.m. Berlin
  • 4 p.m. San Francisco / 8 a.m. Perth

But Raz, hold up! My team is super distributed… what then? Well, if a few people are in San Francisco and the rest are in Mumbai, you would have to hold two separate sessions and compile all the results in one place. But when there is an important decision to make, someone will have to make a small sacrifice to be on the call at an odd hour.

Create a Design Sprint brief

Once you have your dream team, create a brief using this template. It’s the core document that is meant to align all participants on what to expect from the upcoming Design Sprint. It includes an outline of the challenge, the schedule, and the timeframe, as well as a checklist of things to do.

Problem framing

Research is often seen as a daunting and tiresome process that has no immediate benefit. Problem framing is a crucial component of your Design Sprint preparation. It implies doing just enough research around the problem you are trying to solve. Talk to key people, look at data or analytics, and depending on your problem type, conduct audits or interviews to find out as much as you can about the problem. This will help you set the stage and get everyone aligned before the Design Sprint commences.

Preparatory calls with your Sprint team

From my personal experience, it’s a really good idea to give everyone an overview of what’s going to happen in a Design Sprint. The process is intense, and you need to make sure people are on the same page and are aware of what will happen. Make sure they understand the challenge and what is expected of them. Also, it might sound obvious, but make sure people know how to operate the communication and collaboration tools you’ll be using.

Step 2: The tools

Luckily, the technology was already there, and we just had to pick and choose our favorite combination of tools:

  • Zoom. Connect, chat, share screens, and record sessions seamlessly.
  • Notion. Keep everything in one place, from notes and tasks to prototypes.
  • Figma. Collaborative and live prototyping across timezones.
  • UserTesting. Test your prototypes quickly without the hassle.
  • Doodle. Scheduling meetings made super easy.
  • Miro. The online canvas for modern-day pioneers. Home to our very own, exclusive Remote Design Sprint Template.
  • Asana. This is our choice. There’s no shortage of project management tools out there, so pick the one that fits you and your team best.

Step 3: Running seamless remote Design Sprints using our Miro template

We partnered with Miro, the best online collaboration tool out there, and created a complete Remote Design Sprint Template, ready to go. Here are just a few elements from our template:

Independent work areas for each participant

We found that creating individual digital workspaces for each of our team members increased overall efficiency. It lets people stay focused on their tasks and gives us a clear view of progress, allowing us to quickly see if anyone is having trouble.

Clear explanations and instructions

Instead of repeatedly asking us how to do the exercises, each participant has clear steps and examples associated with their work areas. This way we prevent distracting conversations midway through our silent tasks.

Built-in tools that make your life easier

We chose Miro for various reasons. First of all, they’re really awesome people. Second, they have a solution that gives you all the tools and widgets to kick-start your next Sprint, like a timer, area voting, and presentation mode.

Grab the Miro template here!

Advanced facilitation tips

Now, dozens of remote Design Sprints later, we perfected our method and want to share all of our learnings with you.

  • Proper call environment. Nothing is worse than an espresso machine grinding in the background while you’re trying to facilitate a Sprint. We know working from your favorite coffee shop is cozy, but how about a nice, quiet meeting room?
  • Video sharing is mandatory. Be very strict with this, as it will come in handy for you as a facilitator. It’s easy to see if someone is disengaged, with light bouncing off of their face when tab-switching, or confused, giving you the chance to help them.
  • Managing expectations. Especially if it’s your first time running a remote Design Sprint, you need to understand that managing your team’s expectations is crucial. After all, you’ll be blocking their calendar for a few days and they need to understand why. It’s important that people who will take part in the Sprint are aware of the outcome, which is a validated (or invalidated) prototype for the challenge at hand. In a Design Sprint, we’re not building an entire product, we’re validating a direction and gaining the confidence to move forward.
  • Staying organized. Having a single source of truth for all the Design Sprint resources will save you tons of time. Set up a project where you’ll be giving updates and uploading all relevant materials so that the entire team is connected and understand where to find everything. We recommend Asana or Notion, but feel free to use other tools like Basecamp or Trello.
  • Dealing with conflict. As much as I love the Design Sprint, sometimes you might find yourself in a position where you have to deal with troublemakers and skeptics who question its effectiveness. The Sprint has its own particularities and implies a certain way of doing things that don’t resemble a regular workday. Being able to clearly set expectations before and during the Sprint will save you the headache.

Closing remarks and resources

So there you have it. All the best advice we’ve learned over the past two years of running and teaching remote Design Sprints, all in one place. We truly hope this article can be the reference guide for your upcoming remote Design Sprints. We’re also happy to connect via LinkedIn (Raz and Ana) and answer any questions or hear your awesome Design Sprint stories.

You can also check out our Remote Design Sprint talk here.

As a recap, here’s what you’ll need to kick-start your next remote Sprint:

  • Once you confirm the Sprint is happening, get up to speed with the challenge and talk to key people in the team
  • Build your dream Sprint team
  • Schedule the sessions and confirm the team’s commitment
  • Use our template to create a Design Sprint Brief
  • Set up a project in your favorite project management tool
  • Prepare the virtual “Sprint room” by using our exclusive Remote Design Sprint Template on Miro
  • Run the Sprint as the awesome facilitator that you are
  • Make sure you approach this with lots of inspiration and great vibes
  • Celebrate 🎉 you just had a Remote Design Sprint

Happy Sprinting!

--

--

Modus
Modus

Published in Modus

A former Medium publication about UX/UI design. Currently inactive and not taking submissions.

Just Mad
Just Mad

Written by Just Mad

We’re a business-driven design consultancy. We use workshops to unleash innovation & growth potential. Remotely & on-site. Hi!

Responses (1)