Remote Design Sprint

Purpose

The purpose of a Remote Design Sprint (RDS) is to quickly create a shared understanding of a complex problem and solutions to move forward while collaborating in a remote environment.

It has the same benefits as non-remote Design Sprints while incorporating techniques of synchronous and asynchronous activities.

The RDS process is based on Google’s Design Sprint methodology, and adjusted using AJ&Smart’s Remote Design Sprint 2.0 in accordance with Jake Knapp, the creator of the original Design Sprint.

When to opt for a Remote Design Sprint

You should use the RDS when you need to quickly find a design solution or direction for a large problem. Sometimes, these problems span multiple stages or groups.

How to pitch a Remote Design Sprint

When making a request to conduct a RDS, work closely with your Product Design Manager to gather information needed to help prioritize the effort with Product Management. Be clear about the scope, duration, and level of effort needed from RDS participants and include how the RDS will get results faster for upcoming milestones.

Who should participate in a Remote Design Sprint

You should keep the RDS team to around 5-7 people. More than that becomes difficult for the facilitator to manage and less than that can limit the diversity of backgrounds and knowledge needed to solve the problem. RDS participants should be a mix of counterparts from each participating team, such as UX (Product Designers, Researchers, Tech Writers), Development, Product Management, Sales, Customer Support. The more diverse the better, but be sure they’re relevant to the challenges being worked on and that they have the time to contribute effectively.

Remote Design Sprint methodology

Your team’s availability and the priority of the problem needing to be solved will determine how compressed your RDS may be. Synchronous meetings can allow you to complete exercises more quickly. However, it is possible to complete many of them asynchronously.

RDSs work best with a mix of asynchronous and synchronous sessions. This gives your team ample time to plan, participate, and complete any asynchronous homework prior to synchronous workshop sessions while balancing other daily tasks. Review the RDS Issue Template for suggestions on which exercises work better synchronously or asynchronously when considering your RDS timing.

We recommend keeping your RDS to two weeks or less. Any more than that and you may suffer from loss of momentum. Regardless of the actual duration, the steps, methodology, and exercises are essentially the same. However, you may find that some of the exercises are unnecessary to complete as part of your RDS because you already have the content or data sorted out. In cases like this, you should feel comfortable removing those exercises from the Figjam template you copied during your setup outlined below. Note: Before you remove an exercise, be sure to read through the details and instructions to ensure that you truly do not need it.

Each day of the RDS may take more than 24 hours to allow everyone, across time zones, the same time to complete asynchronous activities (especially if there are large gaps between the earliest and latest timezones). This is okay. If participants have a 12+ hour gap or more, it is best to plan each day of the Sprint to take 48 hours so everyone has a full work day.

Setup

1. Create an Epic using this template which will be the SSOT for your RDS’s goals and process.
   1. Be sure to read through it completely and thoroughly as it outlines the details of each exercise.
   2. Gather all of the supporting research data you have, linking any Insights to this RDS Epic.
   3. Create issues for each day of the Sprint using the following templates and link them to the main epic.
   4. Optionally - create a planning issue and link it to the epic. This can be used to help plan the problem, Sprint team, time zones and more.
2. Work with your Product Manager to form your team of RDS participants (5-7 RDS participants with diverse backgrounds and knowledge of the problem space is recommended).
3. Create a new folder in Google Drive that can be shared with your RDS participants. This will act as a repository for any assets created during the asynchronous homework exercises.
4. Create a duplicate of the Figjam Remote Design Sprint template that will be used as the primary working area.
5. Create a special Slack channel that is specific to this RDS

Once the above is done, you’ll need to decide how to break up your sessions. This is dependent on how long you plan your RDS to last (4 days, spread over 2 weeks, or somewhere in between?). If you’re able to do the standard RDS over 4 days then you can use the Figjam template as a guide. Otherwise, you’ll need to get creative and balance your team’s availability with the needs of each session’s included exercises and how they work together.

Next, you’ll need to onboard your participants. Start by walking your Product Manager through what a RDS is if you haven’t already. Inform them that they will play the role of the “Decider” and explain that the Decider is responsible for making the final decisions on which challenges or concept(s) should progress to the next step, etc. This should be done separately in a sync call or over a Slack private discussion to ensure they fully understand their role and to answer any questions they may have prior to notifying the rest of the team.

Once this is complete, add a new comment and CC each of the participants in the RDS Epic you created during your setup, inviting them to the RDS and requesting that they read through the Epic thoroughly. Also, let them know that you will be reaching out soon either via a survey or through synchronous discussions so you can get an idea of what their pain points/challenges are around the RDS topic. In the Design Sprint world, this is known as The Expert Interview where you as the Facilitator want to discover and understand the challenges the team wants to try and solve about the RDS topic (See the Issue template notes for more details).

After notifying your RDS team within the Epic:

• Share the Google Drive folder with them
• Add them to the Slack channel you’ve created
• Provide a link to the RDS’s Figjam board.

This should all be done at least 1 week before the RDS is scheduled to begin.

Balancing asynchronous and synchronous collaboration

While it’s possible to participate in all of the RDS activities completely asynchronously, synchronous collaboration is very helpful throughout the RDS. Use a timezone tool to better understand what time zones you are working with and they may or may not overlap. When reaching out to sprint participants who fall out of the facilitator’s working hours, discuss with them how they prefer to participate… async as possible, or perhaps they’re open for working slightly different hours during the sprint week.

Each day of the RDS may take more than 24 hours to allow everyone, across time zones, the same time to complete asynchronous activities (especially if there are large gaps between the earliest and latest timezones). This is okay. If participants have a 12+ hour gap or more, it is best to plan each day of the Sprint to take 48 hours so everyone has a full work day.

General guidelines for facilitators

The Facilitator is responsible for the overall organization of the RDS, planning, and communication. They have by far the largest amount of responsibility in a RDS.

• They set the rules and pace of the workshop and ensure everyone understands what is required during each exercise.
• During sync sessions, the Facilitator is responsible for explaining each exercise and engaging with the RDS participants.
• They should also select someone to be a co-facilitator to assist with logistics, such as your Product Design Manager. The co-facilitator can assist during sync sessions keeping everyone on task or answering questions in chat as the Facilitator is facilitating. They can assist in answering questions if the Facilitator is in a different time zone.
• A faccilitator should be aware of how time zones affect asynchronous activities, and ensure all communication is given before the start of the earliest timezone. This allows everyone in the Sprint to have the same amount of time to complete activities.

General guidelines for RDS participants

RDS participants are responsible for participating in the RDS activities as outlined by the Facilitator.

• It’s recommended to attend the sync sessions. During sync sessions, follow the general guidelines for effective all-remote meetings.
• If the sync sessions are out of the participant’s working hours, it’s important to participate asynchronously, for example by sharing a video recording about the RDS deliverable for the day or any questions the RDS participant might have.
• All asynchronous tasks must be completed before or on the due dates. If there is a problem achieving any of the above this must be communicated to the Facilitator or co-facilitator as quickly as possible so adjustments or assistance can be provided.
• Honor the Facilitator’s directions. They’re the guide for the entire process.
• The Decider has the final, ultimate decision at the end of each activity.

Tools

Here is the list of tools for RDS preparation, collaboration, and documentation. Prior to the RDS make sure you have access to all of the following:

• GitLab
  • Each RDS day’s outcomes and materials will be documented in a separate issue under the RDS epic.
• Figjam
  • RDS participants can join as anonymous but there is a need to be able to identify input against names, so creating an account beforehand is recommended.
  • Figjam will be used for most of the RDS collaboration. Some of the things done in Figjam:
    • Create artifacts like affinity diagrams from RDS participants’ input
    • Use post-its to comment on each other’s points and to add notes
    • Vote on ideas and solutions
    • Create the first draft of the prototype.
  • The Figjam link to the collaboration project will be provided in the issue before the start of the RDS.
• Video and/or screen recording tool (Loom, QuickTime, Zoom, etc.).
  • As part of the pre-RDS homework, RDS participants will be asked to record a short Lightning Walkthrough video. RDS participants can use any tool they feel comfortable with as long as it can capture their screen, mouse pointer, and audio.
  • The faccilitator will also provide walkthroughs of each asynchronous activity, which participants will need to watch.
• A4/Letter-sized paper (preferably white blank), Sharpies/Pens (please don’t use a pencil because it doesn’t create enough contrast for photos).
  • Parts of the RDS will involve some (async) ideation via sketching, RDS participants will need a writing utensil (Sharpies are preferred because they force you to draw at a lower fidelity because small details aren’t necessary at this point) and some paper. This is the most fun part of the RDS where RDS participants get into a design thinking mindset and can appeal to their creative selves. Don’t worry, it’s not about artistry, it’s about ideas and collaboration.
• Camera (phone or other) or scanner
  • RDS participants will need to upload sketches as images for the facilitator to prepare the material before the next sync meeting. RDS participants can take a photo with their phone or use a scanner if available.
• Post-it notes (Optional)
  • If you enjoy taking notes using post-it notes make sure to have some of them available as well. The upside is that they will make you feel more like you are in a workshop and will help the ideas flow. The downside is that you will have to digitalize the ones you want to share with the team in Figjam.

Past Remote Design Sprints

List of past RDSs:

• Auto DevOps Design Sprint (Figjam board)
• [Configure Stage - Design Sprint (Kubernetes management focus)] (Figjam board)
• Growth — User’s dashboard design sprint (Figjam board)

View page source - Edit this page - please contribute.