Raz Burciu
Raz is a product designer with over six years of experience. His approach is result-oriented with a strong emphasis on user-centered design.
It’s difficult enough to run a multi-day Design Sprint with everyone in the same room. Doing it remotely is even trickier. These tips help designers overcome the challenges of running a remote Sprint.
It’s difficult enough to run a multi-day Design Sprint with everyone in the same room. Doing it remotely is even trickier. These tips help designers overcome the challenges of running a remote Sprint.
Raz is a product designer with over six years of experience. His approach is result-oriented with a strong emphasis on user-centered design.
Among product teams, a Design Sprint is one of the many popular design methodologies that vie for their attention. A “Sprint”—in designer jargon—is a time-constrained, five-phase process that uses design thinking to reduce risk when designing a new product. As a product design approach, it’s gaining ground among designers, product managers, and others working in the realm of problem-solving and product innovation. Why?
It works.
A Design Sprint’s goal is to focus on a specific problem, generate multiple solutions, build prototypes, and get rapid feedback from users. It can help companies make better strategic decisions and innovate more quickly.
A Sprint is run with a group of people and takes place over several days with many moving parts. It’s not for the faint-hearted, but if everything goes to plan, it can prove highly rewarding. With everyone in the same location, a Design Sprint is challenging to run, and when teams shift to working remotely, it can become even more demanding.
Note: Familiarity is assumed with the four-day version of the Design Sprint. If not, please read The Design Sprint 2.0: What is it and what does it look like?
Ever since its inception at Google Ventures and the release of Sprint, the book by Jake Knapp, many companies and agencies have picked up Design Sprints as a process and made it part of their design methodology. Google, Airbnb, Uber, and LEGO are just a few big players that have integrated Design Sprints into their product development workflow.
This was my response the first time I read “Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days.” Wow!
Anyone who has spent years in product design knows that the same critical questions keep coming up during the product design process:
The Sprint was my answer, and it felt like a game-changer.
Except for one aspect, everything was running smoothly in my design practice: 90% of my clients were remote, spanning the globe from San Francisco to Melbourne, Australia. As a Europe-based product designer, I lacked a process to work with distributed teams and leverage the magic of Design Sprints.
The logical thing to do was to find a client and a suitable design challenge, schedule a remote Design Sprint, go by the book, and hope for the best.
It was a disaster.
I didn’t know how to prepare, people were disengaged, and there were issues with collaboration and communication.
I was thrilled by the idea of running Design Sprints, and I enjoyed remote work. It was part of my DNA. I had to find a way to combine the two.
I looked at potential solutions, experimented a lot, and inevitably made mistakes. Eventually, I found the right blend of tools and techniques to make remote Design Sprints work. Here are my key takeaways.
The biggest challenge when running remote Sprints is the Sprint structure itself.
In a regular, in-person Sprint, there is a group of people collaborating and going through exercises based on the following schedule:
Monday and Tuesday are for workshops. The team goes through various exercises for a whole day, filling up whiteboards and amassing sticky notes. The prototyping team comes on Wednesday, and then user tests are run to validate ideas on Thursday.
Monday and Tuesday are the most intense days and require the most effort to organize and facilitate the Sprint. Team members must clear and sync calendars and stay together for a fairly long time, potentially leading to fatigue.
While the traditional Design Sprint framework works great for in-person sessions, a few adjustments are needed to fit remote, distributed teams. After many iterations (and truthfully, a few mistakes), a winning solution was developed.
The updated, remote version of the Design Sprint features a combination of synchronous and asynchronous sessions, which allow for better flexibility.
Here’s our remote Design Sprint schedule:
Days 1 and 2 are workshop days including the full team; sessions are broken into parts, alternating between online and offline. Day 3 is for the remote prototyping team to prototype the solutions the team came up with, and Day 4 is for user testing.
(For a detailed outline of Sprint exercises, timing, and instructions, check out our Miro template below.)
Note that we didn’t label the days Monday, Tuesday, etc. This was done deliberately because when doing a remote Sprint, the schedule depends on the team’s availability, and a Monday start may not be possible.
There are three elements that will make a remote Sprint run smoothly:
The best way to destroy a Design Sprint before it starts is to not be prepared enough, especially when facilitating a remote session. While some may consider pre-Sprint work counterintuitive because it’s designed to empower free-flowing ideation and prototyping, it still needs to run under controlled circumstances; therefore, meticulous preparation is key.
Define the Problem
Once the Design Sprint is planned, becoming conversant with the problem to be solved is essential. Key stakeholders need to be consulted, and it needs to be clear what outcome each team member will be responsible for on a given challenge. This exercise will help choose the right people for the Sprint as well as prepare the session more effectively.
Build the Design Sprint Team
Building the right team is vital and will assure the success of the Design Sprint. A team of five to seven people is ideal.
The Sprint’s goal is to get the right people to focus on a specific problem and generate solutions. The above team is an ideal mix; the roles can be adjusted depending on needs.
Schedule the Sprint
It’s best to schedule participants within a nine-hour window across timezones. It’s also essential to let people know when they’ll be needed and for how long. Doodle is an excellent tool for this.
Pro tip: Use World Time Buddy to review timezones and check overlaps.
Here are some examples of kickoff time combinations we use frequently:
But what if your team is further apart, beyond the 9-hour window? If a few people are in San Francisco and the rest are in Mumbai, two separate sessions would be required, and the results compiled. There will be a time, however, when an important decision is to be made, so someone will have to make a small sacrifice to be on the call at a less than optimal hour.
Create a Design Sprint Brief
Once the team is set, create a brief using this template. It’s the core document intended to align all participants on what to expect from the upcoming Design Sprint. It includes an outline of the challenge, the schedule, the time frame, and a checklist of things to do.
Frame the Problem
Problem-framing is a crucial component of Design Sprint preparation. It involves doing enough research around the problem to be solved. This means talking to key people, looking at analytics—and depending on the problem type—conducting audits or interviews to find out as much as possible about the problem. This process will help set the stage and get everyone aligned before the Design Sprint starts.
Set Up Preliminary Calls with the Sprint Team
It’s essential to give everyone an overview of what’s going to happen during a Design Sprint. The process is intense, and it’s best to make sure people are on the same page and are aware of what will happen. They need to understand the challenge and what is expected of them. It might sound obvious, but it’s also a good idea to make sure the team knows how to operate all the remote tools and tech that will be used.
Lucky for us, many excellent remote tools and technologies are already in place for communication and collaboration. Here are my favorite tools:
We created a complete Remote Design Sprint Template (signup with Miro is required) to help run a seamless Sprint. Here are a few elements from the template:
Independent Work Areas for Each Participant
Creating individual workspaces for each team member increases overall efficiency. It lets people stay focused on their tasks and gives a clear view of their progress, allowing the facilitator to quickly see if anyone is having trouble.
Clear Explanations and Instructions
Instead of repeatedly asking how to do the exercises, each participant is given clear steps and examples associated with their work area. In this way, distracting conversations are minimized, especially midway through the silent tasks.
Built-in Tools That Make Life Easier
Miro was chosen for various reasons. It’s a solution that provides all the tools and widgets to kickstart a Sprint, such as a timer, area voting, and a presentation mode.
Here are a few useful tips to help facilitate running remote Design Sprints:
We have a series of videos on how to run effective remote Design Sprints:
A Design Sprint process includes: rigorous preparation, the right tools, and proper facilitation. Define the problem, build the team, choose the tools, schedule the Sprint, create a brief, confirm the team has a clear overview and is familiar with the necessary tools. Manage expectations and communicate clearly.
The Design Sprint methodology is a four-day process based on the premise of design thinking to solve critical issues using design, prototyping, and testing to reduce risk when designing a new digital product.
Both the typical Design Sprint and a remote Design Sprint are four-day processes for answering critical business questions and solving product design problems. They aim to come up with design solutions through design, prototyping, and testing ideas with users.
Jake Knapp spent 10 years at Google and Google Ventures, where he created the Design Sprint process. He’s written two books, Sprint and Make Time, and has coached teams at places like Slack, LEGO, IDEO, and NASA on design strategy and time management.
The traditional Design Sprint process is a five-day/phase process: understand, ideate, decide, prototype, test, and aim to solve complex problems and reduce risk when designing a new product. A remote Design Sprint is shortened to a four-day sprint.
Located in Cluj-Napoca, Cluj County, Romania
Member since March 30, 2016
Raz is a product designer with over six years of experience. His approach is result-oriented with a strong emphasis on user-centered design.
World-class articles, delivered weekly.
World-class articles, delivered weekly.
Join the Toptal® community.