15 tips for running remote design sprints
Design sprints (a.k.a. research sprints) are great. A week or 2 of super focused collaborative work to answer critical business questions by rapidly designing, prototyping, and testing ideas with customers. Jake Knapp has made design sprints all the rage with his book Sprint — how to solve big problems and test new ideas in just five days and like many organisations, Redgate has embraced them.
Design sprints are certainly productive if you can get everyone in the same room, but what if you can’t do that? What if you’re forced to run a design sprint remotely? As Jake Knapp himself acknowledges:
“I’ve heard stories of people running successful remote sprints, but to be honest, I never totally believed it. Part of the sprint magic is being in the same room.”
A few weeks ago, we were forced to find out if you can indeed have the same sprint magic in a virtual room. The SQL Monitor design group had planned to run a co-located design sprint, but with Coronavirus and the subsequent lockdown scuppering that particular plan, we had to rapidly pivot and run a remote design sprint instead.
Whilst this certainly wasn’t the first design sprint we had run at Redgate, it was the first one we’d attempted to run remotely. The remote design sprint went well given the circumstances but wasn’t without its challenges. We learnt a lot about what works and doesn’t work when working remotely, and how you can’t simply run a remote design sprint as you would a co-located one. If you’re planning to run a remote design sprint, whether by necessity or design, you should keep these tips in mind.
1. Don’t run a remote design sprint (unless you have to)
Spoiler alert. Running a remote design sprint doesn’t produce quite the same sprint magic as when everyone is in the same room. It’s like watching a sporting event on the big screen. The experience is kind of similar, but it’s not a patch on being there in person.
Thanks to Coronavirus we didn’t have a choice about running a co-located or remote design sprint. The choice was to run a remote design sprint, or no design sprint at all. If you do have the choice run a design sprint where everyone is co-located in the same room if you can. Whilst we haven’t tried it, a good halfway house is to run a design sprint remotely, but with small co-located teams. For example, 2–3 people working together in each location. This can ensure that your remote design sprint retains at least some of the magic of working face-to-face.
2. Split the remote design sprint over 2 weeks
Even if you’re running a co-located design sprint, we’re not huge fans at Redgate of compressing it into 4 or 5 days. We find that 1.5 to 2 weeks provides a more realistic timetable. This is certainly true for a remote design sprint. You simply can’t get the same amount done when working remotely. Therefore, as Jake Knapp also highlights, “If there was ever a time to break a sprint over a couple of weeks it’s with a remote sprint.”.
We ended up splitting our design sprint over 2 weeks. The first week was focused on exploring the problem, choosing a target to focus on and generating some ideas. The second week on iterating ideas, creating prototypes and testing these with target customers.
3. Schedule testing with customers over multiple days
If you follow the classic 5-day design sprint format (shown below) you’ll invariably try to cram all your customer testing sessions into the last day of the sprint.
In our experience, not only can it be difficult to schedule all your sessions for the one day, but this also provides limited opportunity to adjust the format between sessions and to identify insights. Instead we carried out testing sessions with target customers over multiple days. This allows you to do a day of testing, a day to analyse findings and to refine the session format, and then another day of testing.
4. Prepare templates & material beforehand
To ensure that you get the maximum out a remote design sprint it’s important to prepare your material beforehand. For example, we made sure that we had templates, details of pre-existing customer insights and kick-off material prior to starting the sprint.
Mural and Miro, two of the leading collaborative online workspace tools both provide handy templates for remote design sprints:
5. Send out a design sprint brief beforehand
It’s a good idea to send out a short brief to those taking part in a remote design sprint beforehand. This is something that we did the week before our sprint kicked-off. This helps to set expectations and can speed things up, especially if you set a bit of homework. A remote design sprint brief, such as the template provided by Just Mad might might cover:
- Why the sprint is being run.
- Who is involved in the sprint?
- The goals and scope of the sprint.
- Equipment and material required e.g. webcam, sketching pad.
- Any guiding principles.
- The schedule for the sprint.
- Existing customer insights, such as personas.
- A checklist of things to-do prior to the sprint (like accepting meeting invites).
6. Pause all non-sprint related meetings and work
Whilst it’s easy to get everyone’s full undivided attention when they are in the same room, this isn’t always the case for remote workshops. Come on, admit it. I’m sure you’ve dialled into remote workshops or meetings in the past and barely had any idea of what’s going on because you’ve been trying to do something else at the same time. It’s therefore doubly important for a remote design sprint to ensure that everyone taking part puts any non-sprint related meetings or work on hold.
7. Road-test the technology
You don’t want to launch a remote design sprint, only to learn that your technology, or someone’s broadband connection isn’t up to the job. This is why it’s a good idea to road-test any technology that you plan to use, such as video conferencing or online collaboration tools beforehand. You should also have a back-up. For example, if your online workspace tool of choice goes down, you can always fall back on a basic real-time collaboration tool such as Google docs.
8. Keep it focused
1–2 weeks is not a lot of time. It’s therefore important to have a relatively narrow focus for your remote design sprint. Otherwise you’ll just end up scratching the surface of a problem. Rather than trying to answer a very general business question, such as ‘ How we can improve [product / service]?’ we aim for something more focused. For example, ‘ How can we improve [product / service] for [type of customers]?’ or ‘ How can we improve [customer journey] for [product / service]? ‘. The focus of our remote design sprint was:
How can SQL Monitor better support Enterprise customers with larger, and more complex estates?
9. Keep the team small
We purposely followed the infamous two-pizza rule throughout the remote design sprint. In other words, a team that can be fed with 2 decent sized pizzas (assuming they’re not too greedy). We find that this is a good rule-of-thumb to follow.
10. Keep sessions short
Short sessions are especially important for remote design sprints. There is something about the extra mental effort of working remotely that seems to be particularly draining. We ensured that workshops were a maximum of a half a day and had breaks at least every 60 mins.
11. Use webcams where possible
You want a remote design sprint to capture at least some of the magic of a co-located design sprint. It’s therefore a good idea to encourage everyone to switch their webcam on (assuming broadband connections can take it). We certainly found that being able to see everyone helped keep things running a little more smoothly.
Make sure that everyone is comfortable with this and is aware beforehand (another reason why sending out a design brief is a good idea). Having webcams on also helps to ensure that everyone is solely focused on the design sprint. After all, it’s much harder to surreptitiously watch Netflix if you know that everyone can see you!
12. Divide and conquer
Some design sprint activities, such as prototyping and sketching can be tricky to do collaboratively online. It’s often more effective to ask everyone to work individually and then to come together as a group to discuss, critique and iterate. This ‘divide and conquer’ approach is a good way to find the right balance between online and offline work. For example, on one of the days we spent some time as a group discussing design challenges. We then individually sketched some concepts to tackle these and came together once again as a group to critique and iterate.
13. Create individual work areas
We used Mural, a really nice collaborative workspace tool for our remote design sprint. Tools such as Mural provide the digital equivalent of a whiteboard and are great for real-time collaboration. When setting up boards it’s a good idea to create individual work areas, such as a row or column for each participant. You’ll find that otherwise everyone is invariably trying to use the same space and getting in each other’s way. You can see an example of one of our online boards below. Rows were created for each participant to add their ideas.
14. Take a break
As anyone who has ever taken part in a co-located design sprint will tell you, they’re pretty intense. We found the remote design sprint to be equally as intense, all be it in a slightly different way. It’s therefore important to ensure that everyone regularly takes a break during a remote design sprint and to leave sufficient downtime between sprints. We certainly wouldn’t consider running concurrent remote design sprints for example.
15. Don’t just share insights at the end
Design sprints can sometimes feel a little bit like watching a magician at work. There’s lots of frenzied activity, the odd bit of misdirection and then the big reveal at the end. Rather than waiting until the end of the remote design sprint to share insights, we had a show and tell session part way through the first week, and then another at the end of the first week. This helped to keep stakeholders in the loop and to build buy-in and engagement with the wider business.
Conclusion
Like Jake Knapp we had a few reservations at Redgate about running a remote design sprint. Hand on heart, we still wouldn’t choose to run one over a co-located design sprint, but the last few weeks have shown that they can be almost as effective. If you’re thinking of running your own remote design sprint then we’d encourage you to give it a go. Hopefully you’ll find these tips useful. You should also checkout The Remote Design Sprint Guide from Jake Knapp, John Zeratsky, and Jackie Colburn. It’s a great collection of further hints and tips for running remote design sprints.
See also
- How to Run a Remote Design Sprint Without Going Crazy (Jake Knapp)
- Remote design sprints can’t work! Can they? (Mural)
- The Ultimate Guide to Remote Design Sprints (Modus)
Image credits
- You got this photo by Prateek Katyal from Pexels
- Fanzone photo by Dominik Gubi from flickr
- Webcam photo by cottonbro from Pexels
Originally published at http://www.uxforthemasses.com on May 5, 2020.
