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 Remote Design Sprint 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.
You should use the Remote Design Sprint when you need to quickly find a design solution or direction for a large problem. Sometimes, these problems span multiple stages or groups.
When making a request to conduct a Remote Design Sprint, 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 Remote Design Sprint will get results faster for upcoming milestones.
You should keep the Remote Design Sprint 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.
Your team's availability and the priority of the problem needing to be solved will determine how compressed your Remote Design Sprint may be. Synchronous meetings can allow you to complete exercises more quickly. However, it is possible to complete many of them asynchronously.
Remote Design Sprints 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 Mural 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.
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 Mural 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 Remote Design Sprint 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.
Then add a new comment and CC each of the participants in the Remote Design Sprint Epic you created during your setup, inviting them to the Remote Design Sprint and requesting that they read through the Epic thoroughly. Also, let them know that you will be reaching out to them 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 they want to try and solve in relation to the RDS topic (See the Issue template notes for more details).
After notifying your RDS team within the Epic:
This should all be done at least 1 week before the Remote Design Sprint is scheduled to begin.
While it's possible to participate in all of the Remote Design Sprint activities completely asynchronously, synchronous collaboration can be very helpful throughout the RDS. If the time zones of the RDS participants allow, consider scheduling one synchronous meeting per each day of the sprint so everyone can ask questions, clarify their point of view, or brainstorm together. These sessions can be used to recap the day's activities, align on the vision taking shape, and prepare for the next day of the Remote Design Sprint.
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 Remote Design Sprint.
RDS participants are responsible for participating in the RDS activities as outlined by the Facilitator.
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:
List of past Remote Design Sprints:
