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?
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?
The Design Sprint Methodology
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:
- 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 lot of money building it?
- How can we make more confident product decisions?
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.
The Challenges of Running Design Sprints Remotely
- Timezone differences and team availability. It’s hard to schedule and align distributed teams for long periods 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 working remotely, your team is one Alt-Tab away from Slack or Netflix.
- Tech-related issues. A poor internet connection, low-battery AirPods, and unreliable microphones can hijack your remote session.
- Ineffective collaboration. In a Sprint room, you have a whiteboard as your single workspace. Remotely, things can get messy more quickly than you can say “sticky note.”
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 Key to Running Successful Remote Design Sprints: Break It Up!
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.
A Simple, Three-step Process for Running and Facilitating an Effective Remote Design Sprint
There are three elements that will make a remote Sprint run smoothly:
- Rigorous preparation
- The right choice of tools
- Proper facilitation
Step 1: Prepare for the Remote Design Sprint
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:
- 6 PM Berlin/9 AM San Francisco
- 3 PM Perth/9 AM Berlin
- 5 PM San Francisco/8 AM Perth
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.
Step 2: The Tools
Lucky for us, many excellent remote tools and technologies are already in place for communication and collaboration. Here are my favorite tools:
- Zoom: Connect, chat, share screens, and record sessions seamlessly.
- Notion: Keep everything in one place, from notes and tasks to prototypes.
- Figma: Prototype and collaborate across timezones online.
- UserTesting: Get rapid feedback on prototypes.
- Doodle: Schedule meetings.
- Miro: Build and develop ideas with a collaborative whiteboarding platform.
- Asana: Easily manage team projects and tasks.
Step 3: Running Seamless Remote Design Sprints Using Our Miro Template
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.
Advanced Remote Design Sprint Facilitation Tips
Here are a few useful tips to help facilitate running remote Design Sprints:
- A quiet call environment. Nothing is worse than a whirring espresso machine in the background while trying to run a Sprint. Work in a quiet meeting room.
- Live video is mandatory. It’s a good idea to be strict with this because as a facilitator, it will come in handy. It’s easy to spot if someone is disengaged if you can see everyone on a live video feed. For example, light is bouncing off of their face when tab-switching or looking confused, providing an opportunity for the facilitator to help them.
- Managing expectations. Managing the team’s expectations is crucial, especially if running a remote Design Sprint for the first time. After all, the team’s calendar is blocked for a few days, and they need to see an ROI. Team members must be aware of the desired outcome, which is a validated (or invalidated) prototype for the challenge at hand. In a Design Sprint, the team is not building an entire product. It’s about 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 a lot of time. It’s a good idea to set up a project in a tool like Asana or Notion where updates can be provided and all relevant materials can be uploaded, so the entire team is connected and understands where to find everything. Feel free to use other tools like Basecamp or Trello.
- Dealing with conflict. Situations may arise when troublemakers and skeptics who are questioning the Sprint’s effectiveness will need to be managed. The Sprint has its peculiarities that are unlike a regular workday. Being able to clearly set expectations before and during the Sprint will save headaches down the line.
How to Kickstart the Next Remote Design Sprint
- Once the Sprint is on its way, get up to speed with the challenge and talk to key people on the team.
- Build the dream Design Sprint team (see above).
- Schedule the sessions and confirm the team’s commitment.
- Use this template to create a Design Sprint Brief.
- Set up a project in a favorite project management tool.
- Prepare the virtual “Sprint room” by using our exclusive Remote Design Sprint Template on Miro.
- Run the Sprint.
We have a series of videos on how to run effective remote Design Sprints:
- How To Run a Remote Design Sprint: Part #1 - The Process
- How To Run a Remote Design Sprint: Part #2 - Tools
- How To Run a Remote Design Sprint: Part #3 - Preparation
- How To Run a Remote Design Sprint: Part #4 - Facilitation
• • •
Further reading on the Toptal Design Blog:
Understanding the basics
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.