How to make your Remote Design Sprint a success.

David Ford, experienced Design Sprint and Hack Facilitator, draws on a wealth of experience in running Remote Design Sprints to share his best tips for a successful remote workshop.

Before the COVID-19 lockdown made home working the new normal, the team at Aiimi were regularly running Remote Design Sprints for clients via video conferencing tools.

Now, we’ve gone 100% virtual.

In some ways, this is pretty unfortunate – we’ve just moved into our new Milton Keynes headquarters with a beautiful, dedicated space for running sprints and hacks for our clients. Nevertheless, Remote Design Sprints are great too, and there’s even a few instances where they beat regular in-person Design Sprints, hands down.

Over the years, I’ve picked up a lot of experience whilst facilitating remote workshops and sprints, so I thought it’d be useful to share some specific challenges and learnings to help you tackle what might be your very first remote Design Sprint.

The basics

You probably already know what a Design Sprint is, but if not – it’s a process for getting a bunch of people together, learning about a challenge, converging on a solution, prototyping that solution and testing it with real users. We do all this really, really quickly – usually within five days.

If you want a great, comprehensive introduction to the process of Design Sprints, I’d recommend checking out Jake Knapp’s The Sprint Book.

Before we start, a disclaimer: at Aiimi we mostly work with B2B clients, so over time we’ve made some adjustments to our Design Sprint methodology to best suit our enterprise customers - you may notice a few differences between our approach and standard practice.

Our setup for Remote Design Sprints

The Software

The software we choose is a big part of what makes our remote sprints a success. It has to be easy-to-access and use, and deliver almost everything we’d expect to be able to do in person.

During the remote sprint, we usually use either Microsoft Teams or Zoom for video conferencing (whichever our client prefers) and Miro, a free online tool, for collaborative whiteboard and sticky note sessions. For communicating ahead of the Sprint, we set up a Microsoft Teams or Slack channel for all participants. Sometimes we have clients whose data and security policies won’t allow them to use Zoom or Miro, but more on that in the technical issues section below.

For the prototype build stage of a design sprint, we typically keep it simple and use Sketch and InVision, two great digital product design platforms. However, if the end-product is going to be built in Microsoft PowerApps, we’ll use that to produce the prototype instead.

For remote testing of our prototype, we mostly use Zoom and InVision to share our screens with participants.

The Team

Facilitator: The facilitator is responsible for onboarding participants, planning and prepping and – of course – for running each day of the remote design sprint. We’ve done very large in-person sprints where we’ve needed multiple facilitators, but for remote sprints we always keep the numbers down, so we go with just the one facilitator.

Helper: Our helper attends the remote workshops to discreetly support participants with technical issues, or provide assistance to anyone who needs further help with the exercises set during the Sprint. Having a dedicated helper means we can solve issues without interrupting the flow of the group.

UI Designer: The UI Designer’s main role in the remote design sprint is to create the prototype. In the past, we’ve tried having the UI Designer join us for only the prototype build, but it’s so much more effective to have them there for the whole sprint so they can gain context and insight. We also usually have the UI Designer run the storyboarding exercise.

User Requirements Specialist / Business Analyst. If we’re working on a Sprint for a product that we know is going to go into production (common in the B2B world where the problem is well-known and budget and resource has already been allocated to a solution), we’ll have a URS/BA join us. They’ll participate in the sprint exercises, but really, they’re there to understand the context, ready for the next stage of the process. This background knowledge allows them to hit the ground running once we’ve got approval to proceed to production and create the product backlog.

Platform Developer - This isn’t as common, but sometimes we work on projects where the solution needs to be built in Microsoft PowerApps. In those cases, we find it quicker and more effective to create the prototype directly in PowerApps rather than using a prototyping tool like InVision. This is where we need a Platform Developer who is experienced in working with PowerApps to get stuck in with the sprint.

The Participants

We typically try to limit our in-person sprints to a manageable number, but this becomes even more important when running a remote design sprint. The more people that you have in a remote workshop, the more potential for technology and connection issues to occur. We try and limit the number of participants to five or less, though occasionally we do exceed that.

We’ll usually have the Project Sponsor (or head of business unit) plus some other Subject Matter Experts, but we always ask that representatives from the end-user group attend too. I wouldn’t recommend doing this on a B2C project (you’ll get their input during testing), but it works well on B2B projects. The goal is really to leverage a good range of backgrounds and expertise from within the client organisation.

The Preparation

When running a design sprint, we’re normally dealing with an existing process that is problematic. This could be a manual activity that needs to be digitised, existing software that isn’t fit for purpose, or a combination of both of these things. We’re lucky to have access to a lot of background information (as well as great clients who are happy to spend time getting us up to speed), so our team will frequently spend up to a week on pre-sprint preparation and background research.

At Aiimi, we also work in industries with a lot of acronyms and jargon. We’ve found that things run much more fluidly if we’ve spent the time up-front learning as much as we can about the industry as a whole, the language they use, and the specifics of the particular project. It pays to be prepared – whether your sprint is remote, or in-person.

You might also like: 'What we learnt from 2 virtual hacks, 3 weeks, and 150 people' by Michelle Hall and Joanne Finch

The challenges of Remote Design Sprints – and how we solve them

1. Distractions

In the real world, we simply ask people not to use their phones and other devices during the sprint. However, working remotely, they’ll have to use a device just to participate. There are all sorts of temptations at their fingertips; email, slack, messenger…or even just browsing the web for the latest Coronavirus news.

How we solve this

First off, we ask participants to turn off notifications and close their email. We also ask participants to join from a quiet space, if possible. These days we always get the odd interruption from a child asking about their lunch, and that's okay! Where it does get difficult is when someone has joined from their local café, although this hasn’t been such an issue lately, #Lockdown!

2. Supplies

For in-person sprints we always supply stationery. Sharpie pens, clipboards, post-it notes, paper, scissors, tape, felt-tips. But we can’t rely on remote participants to have this stuff to hand, and, with the lockdown in place, it’s not reasonable for them to pop out and pick up some up in preparation.

How we solve this

The collaborative whiteboard tool we use, Miro, takes care of the post-it note situation, with the added bonus that digital post-its are a million times easier to read – no more bad handwriting! Participants only really need supplies for the sketching exercises. Lately, we’ve been allowing people to use PowerPoint or Keynote to produce their concept sketches if they prefer. We wouldn’t do this for in-person sprints, but we’ve actually seen some great results from digital ‘sketches’ during remote sprints. We find we get a pretty even split among participants – about half the people will use PowerPoint, and half will prefer using paper and pens.

3. Connectivity issues

According to Virgin Media, the UK’s Coronavirus lockdown has resulted in internet usage during the day almost doubling.

Thankfully, the increased traffic hasn’t had any major impact on UK service providers, and across the board speeds are still good. But despite that, it’s not unusual to have a participant or two whose home internet connection is unstable.

We ask all our sprint participants to turn their cameras on – it’s super important that we can see people and their non-verbal communications as we’re going through the process. But sometimes a participant’s internet connection is so bad that it looks and sounds like they’re filming underwater. This can lead to frustration from the participant and it makes some exercises, such as expert interviews, almost impossible.

How we solve this

Firstly, we try and keep the number of participants down. This means we’ll have fewer potential issues to deal with, and when they do occur, we’re not too stretched and can deal with them better. In the worst-case scenarios, when we just cannot communicate effectively, we’ve asked people to re-dial in from a phone, rather than using video conferencing like Zoom. The combination of a phone dial-in and Miro as an online whiteboard tool still works, it’s just not quite as good as Zoom and Miro.

4. New online tools

We’ll sometimes have participants worried about needing to get up-to-speed with tools that are totally new to them, like Miro, or asking whether there’s a tutorial available before the sprint. It can certainly be daunting to think that you’ll be asked to use new tools, with no one physically there to support you and guide you through how they work.

How we solve this

One of our main goals is to make sure participants are comfortable and relaxed, so they can just concentrate on the process of the sprint rather than the tools they’re using. Before each remote sprint, our Facilitator will have a brief one-on-one call with each participant. We’ll make sure they can access the tools and we’ll introduce them to the two or three functions that we use within Miro. At the start of the workshop, we’ll also do an icebreaker that is designed to re-acquaint people with the tools.

Recently, we’ve been getting them to drop a pin on a map to show where they are, then drop another one to show where in the world they want to go for their post-pandemic holiday.

5. Security Issues

At Aiimi, we sometimes work with government agencies and financial institutions that may have very strict security policies in place. This often means participants aren’t allowed to access tools such as Zoom, Skype, and Miro. This certainly presents a challenge for running remote Design Sprints, but there are ways to work around these obstacles.

How we solve this

We never ask for exemptions from a client’s security policies. We have to be flexible and creative in the ways we overcome these limitations, but we’ll always work with the technology our clients can access.

Where the client is setup to work with Microsoft Office 365, we’ll use Teams rather than Zoom, and the online version of PowerPoint rather than Miro. In extreme cases, we’ve even done Sprints using voice calls, emailing PowerPoint decks back and forth – not ideal, and much more time-consuming, but we still got great outcomes from the process in the end. Another thing we watch out for is email systems blocking collaboration invitations from tools like Miro. This is another reason why a pre-sprint call to onboard each participant is crucial.

6. Engagement

It’s certainly easier to make in-person workshops high-energy and interesting, mainly because you can read the room and adjust as necessary. As a Facilitator, I find that this is much more difficult to do when working remotely. Visual clues are much harder to pick up and, if a person is struggling, you can’t just go and sit next to them to have a quiet one-on-one.

How we solve this

We’ve stopped trying to run remote design sprint workshops as full-day sessions. Experience tells us it’s just too intense and exhausting for participants and the quality of the outputs may start to suffer. Instead, we break our remote workshop into smaller sessions over two or three days. These shorter sessions help to maintain high energy and concentration levels. Having a dedicated Helper in the workshop, whose job is to discretely support participants without disrupting the whole group, also makes things a lot more fluid.

Overall, we’ve found that with a few adjustments, Remote Design Sprints can be just as effective, or even better than, in-person sprints. The key is to make the participant’s experience as frictionless as possible. To achieve this, we spend much more time upfront on-boarding participants, planning and prepping than we would for an in-person sprint. We also really think through the outcomes we want to achieve for each exercise, and then make small, practical changes to allow us to best reach those outcomes in a virtual environment. The current lockdown situation is teaching us all what’s possible when we’re working in distributed teams - and Remote Design Sprints certainly are.

Ready to start sprinting? Find out more about our Design Sprint methodology and services.