Damir Kotorić

Mar 23, 2020

9 min read

How to run remote Design Sprints

Originally scheduled to be a talk at Geelong Design Week, but after the coronavirus pandemic caused the cancellation of the event, so in line with the subject of the talk, I delivered a webinar instead. This article is a summary.

A remote design sprint underway.

Remote work is skyrocketing in the recent coronavirus pandemic. The demand for distributed design workshop facilitation skills has gone from experimental nice-to-have, to an overnight must-have for designers around the globe.

A traditional in-house design sprint.

Many companies are onboard with design sprints. But how do we do run effective distributed design sprints? How do we collaborate when participants aren’t all sharing the same room? Or even, the same timezone? In this post, I share some tips from my experience working on over a dozen projects that involved distributed design workshops.

A distributed design sprint, from beginning to end.

The ground rules of traditional in-person design sprints still apply. But there are additional factors to know, and be prepared, about in order to make distributed design workshops a success.

Tip: Use a whiteboard-in-the-cloud

Tools like Miro and Mural, along with fast internet connections, have given birth to distributed design sprints. I personally use Miro, and wouldn’t go back. It is an excellent tool.

Miro has all the features that one needs for design sprints, including video chat and a timer. But it incorporates all these features really well. The user experience is great, the performance, phenomenal.

Tip: Invite participants a few days ahead of the workshop

My tip here is to set up the board ahead of the workshop, populate as much of it as you can before the workshop, and send a link to the board to the email addresses of the participants.

You want people to create an account, open the board, and get a bit familiar with the tool before the workshop. You want to spend your time running a design sprint, not providing live group tech support — though this is somewhat inevitable, but can be mitigated by following this tip.

Tip: Use a template and customise

I‘ve created a Miro template that you’re free to use. I customise the exercises and order to every project, but a starting template is always handy.

Take inspiration from boards I’ve created in the past:

Tip: Ditch the meeting room — everyone jump on their own laptop

The best setup is one where each participant is on their own laptop, and each person is sitting at their own desk, connected via Ethernet cable to a reliable, high speed connection. In such a setup, everyone is equal.

On the other side of the spectrum, the worst setup is one where you’re the only person dialing in remotely, and everyone else is gathered in one room.

I pity the remote participant in this meeting.

Then there are varying degrees in between.

If at all possible, ask your participants to dial in via their own laptops. It’s a hard ask, especially at corporates and government agencies where Step 1 of anything is to book a room.

Tip: If the above isn’t possible, invest in the gear to bring remote participants closer into the room.

If some people gather in a meeting room, and you’re dialing in from somewhere else, you’re immediately disadvantaged. But with the right gear that disadvantage reduces significantly.

A $1K piece of equipment to bring remote participants closer into the meeting room.

“The Owl” — as me and my colleagues have dubbed it — is an indispensable, albeit pricey, piece of equipment that allows remote participants to feel as if they are there. It intelligently moves its multiple cameras around to focus on who is talking, and the audio that it picks up is stellar.

Tip: Go async-first

You’re already making the right step if you pick up a whiteboard-in-the-cloud, but I want to put even more focus on this tip as it really deserves driving home. Do as much work as you can in an async setup, before jumping in the sync workshop.

Why async first?

  • Jump between in-person and distributed without losing pace.
  • More inclusive to people who can’t attend the meeting.
  • Easier to onboard people later.
  • Document as you go.
  • Save trees 🌲

Do any research that you can upfront, and populate the board with the research findings. Place the project brief in the board. Add anything that the team might refer to in the workshop, any previous documents, designs, any previous deliverables. Comment on these in Miro. Encourage others to add their own comments. This helps you reap the benefits of async work.

Tip: If you know it’s gonna be a tough sell, don’t sell the whole design sprint.

If your team is convinced and has budget allocated for a full design sprint, with key stakeholders blocking out enough time to participate, well, count yourself lucky.

The majority of design sprints aren’t the Google Ventures style 5-days-straight showpieces that you might see in the videos of Jake Knapp. Most of us will be facilitating 2–3 hour workshops across 1–2 days, with the rest of the work happening in async.

And that’s okay.

Tip: Use conceptual designs to sell a full sprint

Getting buy-in for a week’s sprint might be tough. I previously worked with agencies who found a great way to entice clients to buy into our design sprint process. That trick was to show some conceptual designs, which take little time to put together.

Conceptual designs, taking a few hours to put together, sent as a way to entice stakeholders to buy in to a design sprint.

I would spend up to a half-day on creating mockups that illustrate what might be possible if we were hired to run a full design sprint, with a ~50% success rate. In one really successful month my conceptual designs managed to secure 3–4 different projects for the agency.

Tip: Aim for 5–7 participants, no more

We don’t want too many cooks in the kitchen. We want to have all the right people in the team, but with too many cooks it all turns into design-by-committee mayhem. That counts with all design sprints, not just distributed ones, but with additional difficulties like lag, and potential dropout issues, we want to be free to move quickly with a highly skilled team of specialists.

Of course, this is not always within your control. You may be facilitating workshops with 12 people. Don’t stress. Go with the flow, but err on the side of a smaller group.

Tip: Create an inner circle and an outer circle

In large organisations not everyone can take part in the design sprint. It would turn into mayhem. Therefore, create an inner and outer circle. The inner circle partakes in the design sprint. People from the outer circle are invited as specialists on particular workshops, and they are constantly updated (say, once a day) in order to be kept in the loop.

Tip: Decision makers must be either in the inner, or close in the outer circle. Otherwise you’re building too much risk.

We’re all for small teams that can move fast. But if a key decision maker isn’t in the inner or outer circle, that’s a problem. That’s a risk factor. That’s a person that you have to sell your finished idea to. We want to eliminate the need to sell ideas. By involving key decision makers you won’t need to sell to them later. Because they were part of the process. Sure, that brings risk forward, but more often than not, that’s a good thing.

Tip: Don’t worry too much about the end result. Focus on the next task.

It’s good to sketch out a rough 1–2 week plan for the design sprint and share it with participants. But don’t force yourself to stick to this religiously and to meticulously plan out every detail ahead of time. As long as you know what you’re doing today, and what you’re doing tomorrow, that’s good enough.

Tip: Utilise design systems. Don’t waste time reinventing the wheel.

Applicable to the prototype build stage of the sprint, I utilise a Figma Material Design template which I customise to the brand of the client. I then use this to quickly put together prototypes. I don’t want to waste time creating a design system from scratch. That can come later if needed.

With a design system ready to go prototyping can happen fast.

Looking ahead

I believe that face-to-face is irreplaceable, but remote is the future. Sure, there is nothing like the zero millisecond latency of sitting in the same room and doing design sprints together. There is a charm and energy there that cannot be recreated online.

Face-to-face is irreplaceable. Remote is the future.

However, I still believe that distributed workshops are the future of work. Access to talent for companies, work/life balance for employees, and the “automatic documentation as you go” aspect of async work, creates a strong value proposition for distributed workshops.

Some of my best work was created in environments that don’t look like what you would expect:

Some of my best work came about at home, and in environments like this:

In-house and remote workshops are not mutually exclusive. Both come with their respective advantages and disadvantages. Both have a place.

But to not bore you with a politically correct conclusion here, I shall finish strongly, and say that I predict that remote, async-first processes will become the de facto standard for design processes everywhere. In a world where teams are distributed across the globe, where team members in the same office rotate working from home on different days, and with the benefits of the process and decision-making being automatically documented, it just makes sense to learn the art of running a remote design sprint.

I’d like to encourage you to share your tips as well, so we can together create a world where creativity and innovation isn’t limited to any geographic location. May the best ideas win.