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 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 your RDS will take, the steps, methodology, and exercises are still the same:
Once the above is done you'll need to decide how to break up your RDS 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 more standard, compressed RDS over 4 days then you can use the Mural Template as a guide as to how to break up each day's exercises. Otherwise, you'll need to get creative and balance your team's availability with the needs of each session's exercises and how they work together.
Next, you'll need to onboard your RDS 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" in the RDS and explain that the Decider is responsible for making the final decisions, 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 RDS participants in the Remote Design Sprint Epic you created in the first step, 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 for 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:
GitLab Each RDS day's outcomes and materials will be documented in a separate issue under the Remote Design Sprint epic.
List of past Remote Design Sprints: