# The Remote Design Sprint Facilitator's Kitchen Sink

> The ultimate guide to facilitating a remote design sprint for your remote team.

Source: https://curiouslychase.com/posts/the-remote-design-sprint-facilitators-kitchen-sink/

This post is a _faciltator's guide_ to a remote design sprint.

Make sure that you've read these posts so that you can orient yourself as a **practitioner of remote design sprint**:

- [What Is a Remote Design Sprint?](https://curiouslychase.com/posts/what-is-a-remote-design-sprint/)
 - [Should my team hold remote design sprints?](https://curiouslychase.com/posts/should-my-team-hold-remote-design-sprints/)

# The Remote Design Sprint Week
The [remote design sprint](https://curiouslychase.com/posts/what-is-a-remote-design-sprint/) happens over the course of 5 days. 

The best way to be setup for success is to 1) pick a facilitator and 2) have the facilitator setup a few things to make the start of Monday seamless.

## Pre-Sprint Work
First, you need to pick a facilitator. 

> [!TIP]
> If you're doing [remote design sprints](https://curiouslychase.com/posts/what-is-a-remote-design-sprint/) in some cadence, then it's a good idea to create a rotation so that you're not having to do any cognitive burden of picking next week's facilitator.

The facilitator should do 3 actions (ideally on the Friday before):

### Determine Synchronous Collaboration Times for Monday, Tuesday and Wednesday
The most important part of having a successful [remote design sprint](https://curiouslychase.com/posts/what-is-a-remote-design-sprint/) is to make sure that you can maintain the group's energy by only having everyone _together_ for 1-2.5 hours a day.

In order to do this, you need to determine what times your team can get together.

Some things to keep in mind:
- **Document your overlapping working hours** if you're in different timezones.
- **Encourage everyone to keep their calendar up to date** so that you can pick times well.
- **Use everyone's calendar** to make sure you pick times that include the most people possible. Ideally you want your whole team to be able to make the synchronous times.

Now your job is to make sure that all of those sync invites end up on everyone's calendars along with links to the video conferencing, the Notion document and the FigJam

### Create a new Notion Sprint document
Using the [Notion Remote Design Sprint] template, create a new sprint document named `Sprint: Next`. 

> [!TIP] Process Tip
> I find it's easiest to name it "Sprint: Next" so that the team can easily find it until you've decided what the theme of the sprint is. 
> 
> Once you've decided on your theme, you can rename the Notion document, the Slack channel and the FigJam file. 

Once you have your document, create a channel in Slack named `#sprint-next` (see process tip) and add anyone who's going to be involved in the sprint as channel members. It's also important to let the team know in your team channel (or if you're small like Murmur is, in `#general`).

If you have a decider (for small startups, this is probably the CEO/founder), they need to pick a long term goal and it's your job as the facilitator to remind them to do it, add it to the Notion document's **Orient Yourself** section and Slack channel.

Now it's time to add the dates to the Notion document. Make sure to update the range of the week so that anyone can easily find it based on the date range.

Once you've done all of these things, your Notion remote design sprint document is ready to go.

### Setup the FigJam

The last thing to do here is to setup your **FigJam** file. There is also a template for remote design sprint that matches the steps in the Notion document, so all you need to do is clone the template (the first time) and create a new remote design sprint FigJam file.

**After you've done these three tasks (schedule time for next week's sprint, create and setup your Notion document and create your FigJam file), you're all setup to tackle your [remote design sprint](https://curiouslychase.com/posts/what-is-a-remote-design-sprint/) Monday!**

### A Note About _All of This Setup_ ☝️
All of this is in the **Facilitator checklist** in the Notion template, so don't feel like you need remember it all or make your own checklist.

It's also important to note that after the first time, all of this takes at most **fifteen minutes**, don't be distraught by the explanations!

## Monday

It's Monday morning. You're ready to go.

The most important thing to remember about today is that **everyone should know the goal, the 'how might we', the target user and the target moment**. At the end of Monday, your team should be ready to **ideate** because you've spent time **doing discovery**.

Your decider has filled in the **Orient Yourself** section of the Notion document. (If they haven't they need to do that as soon as possible, the success of the rest of the sprint depends on that being there)

### Asynchronous/On Your Own (Monday, Async Block 1)

As the facilitator, your job is to **orient everyone towards preparing for the remote design sprint**.

You want to make sure that everyone has had _at least_ 3 hours to do **adminstrivia** for orienting and the **first three asynchronous tasks**.

The administrivia that you want everyone to do as early as possible is:
- join the Slack channel
- review the long-term goal 
- joined the FigJam

The **first three asynchronous tasks** that everyone needs to spend 1 hour doing before your first asynchronous session:
- generate a **list of sprint questions** on the FigJam (these should come from a place of skepticism and cynicism, they'll help you come up with _juicy_ challenges to solve)
- generate **a list of "how might we" questions** on the FigJam
- generate a **rough map of the user journey** on the FigJam

### Synchronously/Together (Monday, Sync Block 1)
If your team did the work, when you get together, you should all be coming into a FigJam where the _first 3 sections are filled with sticky notes_.

#### Check-in
When you get together synchronously, the best thing you can do to get everyone "warmed up" for work is to ask them a check-in question. At [Murmur Labs](https://curiouslychase.com/posts/murmur-labs/), we do this _every meeting_ as a way to get us thinking in the same direction.

#### Review Remote Design Sprint Questions
Now that you're checked in, start a timer for ~6 minutes and let the team know that the next 6 minutes is a time for **silently reviewing questions alone**. 

They can generate new questions based on questions they read and add some stickies to questions that resonate with them _as signal for deciding on the "how might we" later._

#### Review "How Might We" Questions
Just like the **Cynical Questions** review before, start a timer for ~6 minutes for the team to silently review "How Might We" questions, generating new "How Might We" questions and adding stickies for signal for deciding on the winning "how might we".

#### Discuss The User Maps 
Now it's time to discuss the user maps on the board. _Hopefully_ the user maps are similar enough that there's not a lot of discussion, but the goal of the discussion is to talk about places where the maps deviate **so that you can consolidate to one user map**.

It's also important to notice if you all started with the same "Test User" in your user map.

#### Dot Vote Individual Components
Once you've discussed and consolidated to _one_ user map that you all consent to, it's time to **signal the individual stage on the user map** that the team thinks is the moment that, **if you design to make it better**, will make a user want to use what you made.

It's important to remind the remote design sprint participants that **adding a sticky is _just_ signal and is not _voting_.** The final vote is up to the _decider_ but they do it based on the signal they get from the team's dots from **cynical questions**, **"how might we" questions**, and **picking a moment in the user map.**

#### Decide on the Moment  
Now it's time for the **decider** to make 2 (possibly three decisions):

- What is **the moment in our user map we're going to build for**?
- What is the **"how might we" question we want to answer**?
- (optionally) If there are _multiple_ types of target users, which **target user are we building for**?

#### Fill Roles For Sprint
This last piece is something teams often wait for but should be decided on _Monday_ to set the remote design sprint up for success: **who is going to fill which of the following roles?**

The roles that should be decided on Monday:
- Next Sprint's Facilitator (so they aren't the interviewer)
- Interviewer (not this week's sprint or next week's sprint's facilitator)
- Storyboard Stitcher

#### Setup Time Between Now and Next Sync Time
Now that you've done the work and your sync time is coming to a close, it's important to make sure that everyone knows what's happening between check-out and the next time you get together.

I've found the best way to do this is to share a screenshot of the blocks between now and when we sync, including the times any work is "due".

Doing this makes sure everyone knows exactly how to participate, what to participate on, when to participate by and to help make your _second async_ block in the morning smooth.

#### Check-out
The last thing to do is check-out! 

You can make this as easy as "share a gif of where your energy is after our first sync time" or something unrelated.

Also, remind everyone that if they have questions, they can ask in the Slack channel so that they don't get stuck and end up waiting.

### Asynchronous/On Your Own (Monday Evening/Tuesday Morning, Async Block 1)
Now that you know what your goal, the team can start to create lightning demos in the **FigJam** file.

The goal of a lightning demo is to find inspiration that's related to your goal in some way. 

As an example, if you are building a bot to help managers build effective, collaborative remote teams, you can start to scour the internet for inspiration about Slack bots and other integrations that do something similar. 

It doesn't have to be _specifically for your goal_, the main thing to remember is that it should be something that you think your target audience would identify with.

## Tuesday
It's Tuesday, and yesterday your team determined the user moment and "how might we" question you want to answer together. 

Hopefully everyone has done their lightning demos by now.

### Asynchronous/On Your Own (Tuesday, Async Block)
During this async block, it's time for your team to **make notes about the lightning demos**, **generate rough ideas based on what they noticed** and do **Crazy 8's**.

The goal of this asynchronous block is to **generate rough sketches that each person shares with the team**.

Encourage the team first thing in the morning in your earliest timezone to be **irreverent about their rough sketches**. 

### Synchronously/Together (Tuesday, Sync Block 1)
This block has 3 sections:
- each person explain their rough sketch
- each person signals which parts of the rough draft they like
- the team signals on what you're going to storyboard and build

In this block, you're going to **give each person about a minute** to explain 1 **rough sketch**, in a round robin fashion, until everyone has given a brief explanation of their **rough sketch**. 

It's okay to let people take a little longer than 30 seconds, the important thing to be aware of as a facilitator is **keep people from cross-talking** or **having conversations about a crazy 8**. 

The goal of this is to make sure **everyone's ideas are heard** and there's no judgement about if they're good.

Now that everyone has done their round robin explanations, it's time for the team to use stickers to **signal which parts of the rough sketches they liked**! 

Give everyone about **5 minutes** to do this silently together and let the team know that they can signal to you that they're done if they're done early. 

The goal of signaling is that everyone can now see which _parts_ of a rough sketch people liked and **use that signal in the next async block!**

The last action item to do is to take a quick pulse of the team of **what you're going to build this sprint**.

The decider **should make the decision based on the pulse.**

If your team has an existing product that's found product-market fit, you probably already know you're prototyping a feature.

If your team **does not yet have product-market fit**, you have a few options of what you can build:

- A slide deck
- A marketing site
- A prototype for an app
- A prototype for a bot

The last thing to do is to **let the team know what they can expect between now and the next sync time**. (Notice a pattern yet?) 

Now it's time to check-out! 

### Asynchronous/On Your Own (Tuesday Evening/Wednesday Morning, Async Block 1)

Now it's time for **each person to make a solution sketch**!

At this point, your team knows **what problem you're designing for**, **who you're designing for**, **what moment in the user map you're designing for** and they're equipped with a bunch of **rad, raw ideas from the rough sketches** to **create their first 3 panel storyboard**.

The goal in this async block is for **each participant** to create **at least one 3-panel storyboard**.

They can do this using pen and paper, sticky notes swipies or other dry erase board, iPad apps (Concepts App, Procreate, GoodNotes), whatever medium they want.

It does have some constraints though:
- a catchy title
- it needs to be self explanatory
- only **3 panels for each storyboard they make**.

Each member should add their storyboard as either a photo or an image (if digital) to the FigJam board **before the next Async/On Your Own** block.

## Wednesday

It's Wednesday morning and each person on your team should have created at least **one 3 panel storyboard**.

The goal of today is to **end the day with a 15 panel storyboard that everyone consents to and understands**.

### Asynchronous/On Your Own (Wednesday, Async Block 1)
Each person should review all of the storyboards on the FigJam board and **put stickers beside every part they like**. 

The goal of this exercise is to notice ideas that other people had that stand out as something that could be incorporated in the final storyboard.

Ideally each person should use 20-30 max.

These stickers **are signal** and not considered voting.

### Together (Wednesday, Sync Block 1)
Now that each person has added stickers to each storyboard, it's time to do a **speed critique** and review each storyboard, one at a time, for what ideas standout. This is also an opportunity to capture objections or questions.

At the end of each storyboard review, ask the sketcher if the group missed anything. 

This can be particularly helpful if an idea wasn't clear to the rest of the group but may be interesting to them once they've heard it.

Once all of the storyboards have been reviewed, it's time to **straw poll and have everyone silently choose their favorite idea**.

The goal of the straw poll is to leverage the wider signal from before **for a more narrow signal** for the decider to pick from.

All at once, each person (_except the decider!_) should put **one sticker** next to their favorite _frame_ or on their favorite _storyboard_.

Once everyone has voted, it's time for the decider to **supervote**. 

The decider will add up to three stickers to one or more sketches based on the signal from everyone else and their input. 

The goal of the decider doing the super vote is that they are **selecting the basis for the final storyboard**.

### Asynchronous/On Your Own (Wednesday, Async Block 2)
Now that the decider has selected the basis for the final storyboard, it's time for each member of the team to **break away for around 60 minutes** to create how _they_ think the final storyboard might look. This can be done alone or in groups.

The goal of doing a final storyboard alone is to give everyone the opportunity to give input to the final storyboard without having a decision by committee.

The frames or storyboards that the decider picked should inform each person's storyboard at this point.

### Together (Wednesday, Sync Block 2)
Now that the group has created their individual storyboards, it's time to come together again.

Have everyone group their storyboards in the same area of the FigJam.

Everyone should silently review all of the storyboards (for about 10 minutes). They can add dots for the individual frames that they like and question marks for any frames they may have questions about.

After everyone has reviewed, it's time to have people ask questions about frames they were confused about.

The goal of this is to try and gain as much clarity as possible for the storyboard stitcher when they compose the final storyboard.

Now that everyone has reviewed the storyboard frames, it's time for the storyboard stitcher to optionally ask the team if they could help group frames that are similar.

Once the similar frames are grouped and any frames with dots are pulled into the same region, the storyboard stitcher can start to create a final storyboard from all of the frames that were dot voted.

The two most important questions to answer "yes" to as a group, per frame are:
- Do we know **what** the UI should be in this frame?
- Do we know **what** the content should be in this frame?

It's important to be concrete on **what we're showing the user** and **what we're telling the user** when creating the storyboard, otherwise the team will lose momentum on Thursday.

After the storyboard stitcher feels good about all of the frames that are going to be in the storyboard (they haven't started stitching yet), it's time to decide on what roles are needed tomorrow for the build and who will fill those roles.

> [!TIP] Choose Roles ASAP
> Choosing the roles and who will fill them as early as possible on Wednesday gives the team room to start orienting around the final storyboard.

### Asynchronous/On Your Own (Wednesday, Async Block 2)
This is the point in time where everyone will start pulling together whatever they need to be effective during the build day.

While everyone else is pulling together any resources they need to be effective, the **Storyboard Stitcher** is creating the storyboard from the agreed upon frames during the most recent together time.

Ideally the person doing the stitching is (or is working with) good at describing what should be happening in each frame and the questions from above have been answered.

This process of stitching the storyboard should take about 30 minutes to an hour. Plan the next together time to be _brief_ (20-25 minutes) accordingly.

### Together (Wednesday, Sync Block 3)
The goal of this final together time is to make sure _everyone_ is clear on the start, the end and **what is being built** and **what is being communicated** in the middle.

It's best to start this with **5 minutes in silence** for everyone to review the storyboard and add a question mark to any storyboard items that they're confused by.

Once the 5 minutes is up or everyone is done, have your team ask their questions one at a time to the **Storyboard Stitcher**. The **Storyboard Stitcher** is not going to have all the answers but they'll be able to contextualize a question and help refine the frames.

Once everyone is done (again, try to keep it to 15 minutes of questions max), ask everyone to give you a verbal confirmation that they are clear about the storyboard.

The goal of the clarity is to do a _best effort_ at being prepared for tomorrow (which doesn't mean questions won't come up!).

**Now that you're done with Wednesday, it's time for the team to start building!**

## Thursday
Now that you have a storyboard that has team consent and roles assigned, _anyone_ can get started on scaffolding out the tasks that you need to complete for building the prototype.

> [!TIP] Facilitators Note
> **Remind** the team that **the frames on the board are serious and we shouldn't change course on the story**. 
> 
> If there are any last minute changes, the **heuristic** you should use for determining if you encourage the change is **is this going to help derisk the question we're asking this week?** and **is this achievable without overtime**? 

> [!DANGER] WIP
> This is section is a work in progress.

# Questions to answer about your remote design sprints
If you've gotten this far, here are some questions I'd ask in your [remote design sprint](https://curiouslychase.com/posts/what-is-a-remote-design-sprint/) retrospective to help you make these sprints work best for your team:

## How mature is what we are building in the product development lifecycle?

## How often do you want to hold the remote design sprint?

## How is your team feeling about the collective energy?

## How often are you successfully presenting something to customers in the amount of time you alotted?
