We recently conducted a remote 5-day Design Sprint at Storyblocks for our Enterprise team. In this post, we discuss facilitators' tips we learned along the way.
We recently conducted a Remote 5-day Design Sprint at Storyblocks for our Enterprise team. Scott Simpson (Storyblocks’ Director of Design) and I had both led sprints and other various in-person workshops pre-pandemic but needed to adjust our planning to a week that best suited remote collaboration. We learned a lot about what does and does not work for planning facilitating a remote design sprint and wanted to share some of those tips with you, dear reader. Below are some key takeaways and suggestions for running your own remote Design Sprint.
The Design Sprint was originally a five-day process developed by Google Ventures for answering critical business questions through design, prototyping, and testing ideas with customers. It’s a great mix of business strategy, innovation, and design thinking packaged into a battle-tested process that any team can use.
A Design Sprint provides helps explore big ideas and test out riskier solutions that sometimes may take months (or even years) to validate in a very short amount of time.
It is important to meet with each Sprint participant beforehand to make sure:
Scott and I divided our Sprint Week participants between us and schedule 1:1 meetings the Thursday and Friday before the Sprint to:
Even though we used many of the activities detailed in the original Sprint book, we still made some changes to the structure and flow of the overall week. For example, we started the week with 5 customer interviews to gain insights into the creator’s workflows and pain points. We also asked individuals to provide asynchronous feedback on our Solution Sketches mid-week via a Google Form and reviewed responses with the Sprint team.
1–2 weeks before the Sprint, Scott and I reviewed each day’s schedule and activity that would take place during the Sprint Week. From there, I created a schedule for each day and made sure they were available on our Sprint Week Activity Board at all times for participants. This allowed us to determine if any activities needed to be moved around and to ensure participants had enough breaks throughout the day.
For our remote Sprint board, we researched pre-existing templates for remote workshops and sprints in both Miro and Mural. We then pulled from public examples we saw to use for the foundation of our board. In the end, we used aspects of templates created by Google Ventures, AJ&Smart, and Crema to create our Sprint Week Activity Board.
For our Sprint, we decided to our Butter, Zoom, and Miro as our means of video-sharing and collaborating. Although we tested Butter quickly the week, the software kept freezing and crashing on the Monday of the Sprint Week.
We completed customer interviews a bit differently than how the authors of “Sprint” describe. Instead of only speaking with individuals on Friday during prototype testing, we asked them to participant in our Sprint week in three ways:
Because we wanted to include customers more than usual, we made sure to reach out to them well in advance (about a month) to make sure they were available. Doing so allowed us to have great customer insights and feedback infused throughout our Sprint Week.
The Sprint Week moves fast. There’s a lot that happens each day. In addition to taking consistent notes, we recommend writing a quick summary of key decisions, feedback, and insights captured at the end of each day. This will help you quickly refer back to important moments.
A simple concept, but one that is easy to forget. Throughout the Sprint, always make sure to capture key takeaways in both writing and visually, when applicable. A lot of good insights take place during group activities and conversations throughout the week. Although it adds more work for the facilitator or co-facilitator, you’ll thank yourself that you took such good notes.
A remote Sprint Week means a lot of computer time, there’s just no way around it. I would argue that breaks are even more important during Remote Design Sprints than in-person one — screen fatigue is REAL. Off-computer breaks allow people to recharge and come back feeling refreshed and ready to re-engage. We wish we had included more breaks, or considered starting later and ending earlier, to help reduce participants’ screen time.
So much work went into the preparation for and week of the Design Sprint that come Friday, we realized we had not communicated a specific plan for how we’d implement the learnings of the week. I’d recommend spending some time with your participants, leadership, and/or co-facilitator to determine at least an outline of what the coming weeks will look like. Is there a specific team that will take prototype findings and implement them? Will several teams own the output of the Sprint? How will customer takeaways be shared more broadly across the organization?
Written by
Rebecca Silverstein