Design Sprints in the time of COVID

July 29, 2020

Tags: Design Sprints, Lessons Learned

Design sprints have become crucial to our workflow when kicking off projects with new clients. They have become especially fundamental for our work with clients where we’re building a product that has never been released.

The reason for this is two-fold. For our clients, it provides customer validation, which gives them confidence they are investing in the right product at the right time. For us, all of the discovery and feedback is invaluable context when we get to the design/development phase and helps us produce better work.

This is great, except during a pandemic. Design sprints are highly collaborative, so we’ve always run them in person. Because of the current state of affairs we recently had to figure out how to do it remotely. On top of that, because of scheduling challenges, we had to compress what is typically a three-day process into just one day. This is what we learned.

Running a Design Sprint Remotely

We ran the session as a single day-long Zoom meeting. I actually think this worked out OK. I don’t think my default will be to run sprints remotely, but I think it’s entirely possible without a lot of downside.

One positive aspect of using a video conferencing service is that we were able to record the entire day, which was great for stakeholders and for us as a reference tool.

We used Mural as a digital whiteboard and it’s a tool that I would use again. It’s not without limitations/frustrations, but I think it worked overall. We set up pre-sprint activities and office hours so participants could get acclimated with the tool and I think that was really important. Half of the group still lacked confidence using it but the other half took to it well.

There are a few downsides to doing a sprint remotely. We found it hard to gauge if participants were understanding the process. It was also quite difficult for the sketching phase. If you’re good with a mouse or have an iPad, sketching in Mural is fine, but for most it’s cumbersome at best. So we offered an option to let people sketch using pencil/paper and then uploaded photographs of their sketches to the shared Mural. This took some time (waiting for emails, etc) but was acceptable.

It was also harder to feel the room to know, for example, when a break was needed. To encourage participants to be fully present for collaboration, we have a no distractions/devices rule. It’s much harder to enforce the distraction/device rule (especially during COVID, where some people are parenting while working); it’s also so much easier to “dip out” for a meeting over Zoom. Overall I’d say it was fine, but it’s definitely a downside.

For some participants, we’ve learned that seeing how others in the room interact with the activity (e.g. crazy 8s) helps guide them, so doing it remotely hurt participation somewhat. We worked around this by having one facilitator share their screen and show their work during activities to provide some guidance and perspective to other participants.

Compressing a Design Sprint into One Day

Design sprints are worth doing because of the results you get, but they’re tough. Each day is long and mentally taxing. That’s true when you do it over three days, but it’s even more true when you compress it into one day.

Here’s what our day’s schedule looked like:

  • 9 – 9:30 AM: Introductions and explaining the process
  • 9:15 – 10:30 AM: Set long-term goal / list sprint questions
  • 10:30 – 10:45 AM: Break
  • 10:45 – 11:45 AM: Lightning Demos
  • 11:45 AM – 12:45 PM: Lunch
  • 12:45 – 2 PM: Make a map
  • 2:15 – 2:30 PM: Break
  • 2:30 – 3:30 PM: Four-step sketch
  • 3:30 - 5:00 PM: Make a storyboard

We actually had to run this day twice for two groups of people. This schedule is what we did the second day after learning from the first.

On the first day, we skipped lightning demos entirely, considering them less important. But it turns out those are rather crucial: they help ground people who aren’t used to thinking in terms of products or UI/UX. This grounding turned out to be important for the sketch.

We also flipped the order of the demos and the map. We found that by time we got to the mapping on day 1, right before lunch, people were too lethargic to really dig in. Mapping is, arguably, one of the most important activities of the entire process, so that wasn’t ideal. Leading up to lunch with something lighter really helped and everyone came back ready for the map after re-energizing over lunch on day 2.

We ended up skipping the How Might We / Ask the Expert portions both days to positive effect. We were able to gather a lot of this information during the goal setting/sprint questions phase by phrasing the excercise a bit better. It helps that the people in the room were the experts and had practical experience they could speak to while envisioning the success goals.

After running two one-day sessions, I think the process is better when run over multiple days. One day is just too short: it’s way too taxing mentally and you don’t get to let your brain percolate overnight. I can see where three days is even too much and instead a two day version would be "goldilocks" — just right.

If I were to spread the process over two days, I’d spend the first day getting to the map and the second doing the sketching and storyboarding. Those are the three important outcomes from the process and you can eliminate a whole day’s worth of effort. By doing it over two days instead of one, you let your mind process everything that’s happened and recover for the remainder of the process, which I’ve come to believe is very important for success. It also makes for more sustained engagement from participants to not be on a video call for such a long duration (even with breaks) — instead, I think two 6 hour days is sufficient and keeps the energy and focus higher.

How’d We Do?

We got good feedback on our post-session surveys, scoring high marks for the process and the facilitation. So I think it’s fair to say that this worked out alright. I would definitely be open to running a remote sprint again, but I'll stay away from one-day versions in the future and instead opt for two- or three-day sprints.

Interested in running a design sprint? We'd be happy to facilitate! Get in touch.

Thanks to my co-facilitator Glynnis Ritchie for helping prepare this post.

Logan Leger

Founder & CEO

Founder. Engineer and entrepreneur. Husband and father. Writes in Ruby, Elixir, JavaScript, and Swift. he/him

let's talk.

Together we can make something great.

contact us about new work



Social Media