What Is a Remote Design Sprint?

Murmur Labs recently adopted weekly remote design sprints as a way of working.

I like them so much, that I'd like to keep doing them indefinitely, regardless of where I work or what I'm working on.

In this post, I'm going to explain what a Remote Design Sprint is

A remote design sprint creates clarity around a goal, clarity around the times I need to be together with my peers (and what I need to do when I'm alone) and leads to asking "what can I build in a day?" instead of "how long will it take me to build an idea?".

Overall, remote design sprints are a great way to maintain velocity and focus, while also reducing the likelihood of burnout for teams that work across multiple timezones.

What is a Design Sprint?

If you're unfamiliar with what a design sprint is, a design sprint is a five-day process to answer critical business questions through exploring the question, design, prototyping and testing the idea with customers or potential customers.

Design Sprint Summary

• Five-day process
• Find an attainable but challenging goal
• design, prototype and test an idea with customers

What A Design Sprint Is Not...

A design sprint is not the same as a agile sprint, in that it focuses on exploring the business viability of an idea, built and tested in a week rather than time boxing work to be done.

What is a Remote Design Sprint?

Unlike an in-person design sprint, a remote design sprint is designed for remote, distributed teams.

Constraints of Remote Work

Remote teams have different constraints than in person teams do:

• Different timezones
• Lots of screen time
• Video instead of rooms

As a result of the constraints for remote teams being different, at Murmur Labs we had to do some leg work to figure out how to do design sprints without getting burnt out.

How Remote Design Sprint Differs

We modified the normal design sprint in the following ways:

• We have intentional, brief together time when we are on screens and async time for when we can go off on our own
• We have shared online hours
• We use digital tools for collaboration instead of physical tools

The most important lesson we learned is don't treat a remote design sprint the way you would treat a design sprint in person.

If you attempt to spend the amount of time together in a remote design sprint the way you would in person, you'll burn out fast, suffer from eye strain because of extended screen focus time and likely feel discouraged because you won't have any energy left on Thursday.

Benefits of Remote Design Sprint

A remote design sprint done well can be incredibly satisfying. The team often sees these benefits:

• A significant piece of work is completed by the end of the week every time
• We know the goal for the week, giving us clarity of purpose
• Each person can show up together, do their own work alone and have time to do what they'd normally do
• Our energy is higher by the end of the week than a typical week
• We want to do more at the end of the week instead of feeling overworked
• As a result, we feel less burnt out

Remote Design Sprint Overview

A remote design sprint still has the same objectives and constraints as an in person design sprint:

• Five-day process
• Find an attainable but challenging goal
• design, prototype and test an idea with customers

Where the remote design sprint deviates from in person, is that it's broken up into time blocks every day.

A remote design sprint is broken up not just into days, but into time blocks, with sync/together blocks and async/alone blocks.

Time Blocks

A time block is a period of time dedicated to doing the work.

Unlike typical remote work, where an individual commits to a week's worth of work, the work is done together in sequence.

Unlike a typical design sprint, people aren't together in person or even the same timezone, so the work in sequence can't be done from "the start of the day" to "the end of the day". It has to be done in a way that works for remote teams that span timezones.

Time blocks are critical for a remote design sprint, instead of trying to do all the work together at once every day, each block sets up the next block by refining the work.

As an example, if you are on Monday morning's async block, where the goal is to ask questions and define the user map on your own, you can't do any of the work beyond that block because the follow up sync block determines the next async block's work.

Together Blocks

A together block is any time that the team is together in a video call.

Sync blocks need to happen in the time your team has overlap.

Doing work synchronously helps build team rapport but it also allows you to have real conversations in the facilitated sections of the synchronous work that can't happen effectively asynchronously.

If your team doesn't have overlap, you're going to run into issues with people not being able to be present.

Async Blocks

An async block is any time that a team member can be working alone at their own pace as long as the pace sets everyone else up for success in the next block.

Async blocks are critical to maintaining energy and scheduling them well is critical to movement.

If your team is in multiple time zones, it's important to attempt to give every timezone as much of the same async time as possible.

As an example, for a team that has Eastern and Pacific team members, after your first sync block on Monday, you want the Pacific team members to have some time in the afternoon to do the same work that the Eastern team members will have.

In order for a remote design sprint to work, everyone needs to be able to be involved in a way that feels comfortable with their working hours.

How The Remote Design Sprint Week Will Go

This is a high level overview of what to expect a remote design sprint week to look like. It includes setup and what you need to have done by the end of the day to know that you can move forward to the next day.

Setup (previous Friday)

Setup is the most important part of a remote design sprint going well.

Setup is the responsibility of the remote design sprint facilitator and includes:

• determining and creating the time blocks for Monday, Tuesday and Wednesday for together time
• setting up the shared remote design sprint channel in them team's communication tool (we use Slack)
• creating the Notion remote design sprint document and the FigJam

Monday

Monday is all about setting yourself up for success for the week.

By the end of Monday, the team has picked:

• the remote design sprint goal
• a "how might we..." question to answer
• the target user
• a target moment
• decided what you'll build
• picked the facilitator for next sprint
• picked the interviewer for this sprint

Tuesday

Tuesday is all about coming up with some solutions for the "how might we..." question framed for the target user based on the target moment.

By the end of Tuesday, the team has:

• submitted lightning demos
• reviewed lightning demos
• made sketches for rough ideas
• riffed on the rough ideas
• started reaching out to a target audience

Wednesday

Wednesday is the day you pull everything you've done so far into a storyboard.

By the end of Wednesday, the team has:

• individually made a 3-panel storyboard
• picked panels from the storyboard for the final storyboard
• individually made a 15-panel storyboard
• made a final 15-panel storyboard
• confirmed the 15-panel storyboard is clear
• assigned roles for Thursday

Thursday

Thursday is build day. Whether you've decided to do a website mockup, an app prototype, or a feature prototype, it's time to make it!

By the end of Thursday, the team should have made the thing you decided to build.

The build should reflect clarity of:

• the goal
• the "how might we..." question
• the target audience
• the target moment
• the desired build artifact

Friday

By the end of Friday, the interviewer should be on one of these two paths:

• you've interviewed target audience
• you've started lining up interviews for next week

It's important to remember that because you're a remote team you can do remote interviews at any time as long as you've decided when to call your sprint "complete" as a group.

The team should be:

• participating a sprint retro
• resting up for next sprint

The current facilitator and next week's facilitator are:

• completing the setup for next week's sprint.

Wrapping Up

A remote design sprint done right can be one of the most satisfying weeks of work, so much so that you may find you want to make it a way of working rather than a practice you do infrequently.

Need help?

If you need any help figuring out if a remote design sprint is right for you, feel free to setup a 20 minute meeting to see if it's a good fit!