I lead a team of designers who work on WordPress.com and other products. Last year, my team ran our first design sprint together in-person at a team meetup. It was a great way to kick off a new project and we became instant fans of the format.

But Automattic is a remote company. Most of the year we work from our homes around the world (only sometimes in our pajamas). We’re spread across countries, continents, and timezones. While we value and take advantage of face-to-face time, it only takes place a few weeks each year. A big part of our job is finding ways to be most effective in our remote environment.

To marathon, or to sprint? 🏃

For those unfamiliar with the design sprint format, the concept is a simple but powerful one: You spend five days together — starting with exploration of a problem and ending with user testing prototypes.

“Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, you’ll get clear data from a realistic prototype. The sprint gives you a superpower: You can fast-forward into the future to see your finished product and customer reactions, before making any expensive commitments.”

~ Google Ventures on Design Sprints

It’s rapid iteration at it’s best. The looming user tests at the end of the week help keep your team focused on quickly validating risky ideas. The research and problem exploration at the start of the week helps fuel the decisions that get you there.

Design sprints aren’t appropriate for every situation, but they’re a great tool when used for the right types of problems.

The challenge: A fully remote design sprint

I like to look at most things in both life and work as design problems. This perspective helps me reframe challenges as opportunities and provides a useful toolkit for tackling big problems.

In our remote environment, we were working with several design constraints:

• The team consisted of 8 people spread across the U.S., Europe, and Asia — putting the timezone spread at about 8 hours. We didn’t want to ask people to work crazy hours or ignore their kids for a week.
• We didn’t want to over-rely on video hangouts. We do most of our day-to-day work in Slack and wanted to take advantage of this form of communication. Async time was also important to help with the timezone spread.
• Many guests joining the sprint had other projects going on, so we needed to allow at least some time for this during their normal working hours.

Identifying these constraints helped us design a schedule that allowed everyone to contribute without working ridiculous hours or sitting in hangouts all day.

Tips for running remote design sprints

The remote design sprint worked well — even better than expected. We also found that some elements worked better remotely than in-person. Here are a few things that stood out:

Do your homework and bias towards over-preparing.
Good prep work made the week go a lot smoother. We spent time before the sprint collecting insights from user interviews, doing competitive reviews, looking at relevant data, and interviewing stakeholders. We summarized this information for the team to review before and during the sprint.

Include non-designers!
Yep — design sprints aren’t just for designers. A cross-functional group brings new and interesting perspectives to the table. It’s even easier to include others in the remote format, since they can attend sessions based on availability.

Have a shared (virtual) workspace.
We used a Mural board throughout the week. This provided a great space for working and gave us something to look back at when working async. In many cases, we found the Mural board was actually more effective than in-person tools. (You won’t even miss real post-it notes…mostly.)

Use face time wisely.
Have a clear agenda and stick to your schedule. Encourage “do not disturb” mode on phones and Slack during hangouts. Also, have the moderator use “round robin” style facilitation to make sure you are engaging everyone in the discussions.

Use moderated (remote) user testing.
Stick to video and screen sharing tools that require minimal setup for the participant. Since you are looking for validation beyond basic usability testing, avoid unmoderated tools like UserTesting.com for design sprints. (These tools have their place, but not here.) Also, start recruiting users before you start rather than trying to wrangle everything mid-week.

Iterate on the process as you go.
We iterated on the process throughout the sprint, tweaking elements as the week progressed. Don’t forget to debrief and do a quick retrospective, so you can improve the next time around.

Remote design sprints are both possible and effective, they just require a bit more planning and prep to run smoothly. Most of this advice is useful for any and all design work in a remote environment — sprint or no sprint. As with anything in design, just be ready to ideate, experiment, and iterate until you find the right process for your team.

Thinking about running a remote design sprint? Check out our custom Mural template.