I’m on the Operational Innovation team which supports store colleagues and empowers them to spend more of their time and energy on customers and members rather than on admin and paperwork. Unsurprisingly, lockdown has affected a lot of work for our team. We had to pause some trials, and of course we couldn’t do face-to-face user research. Because we haven’t been able to get what we’d been working on into our users’ hands to validate our assumptions, we’ve had to delay making some decisions.
Making the most of things with a design sprint
The pause on our regular work meant we had an opportunity: suddenly, the team had enough time in their diaries for a design sprint.
A design sprint usually lasts 5 full working days and involves a small team. The team works together to understand a problem and design a solution. It’s challenging, because each part of the sprint is time-boxed and lasts one day only. The intensity means the pace is super quick but generally, teams keep focus, build momentum and sustain incredible productivity over the short time.
Design sprints can be really inspiring but our question was, how can we do this well, remotely, with the added anxieties of lockdown?
We adapted the format
We knew the usual 5 full days would be impossible. Staring at our screens for 8 hours a day isn’t realistic or fair, especially when some people are caring for elders or children, or they’re keeping things ticking over on other projects. So, we broke the work up into 10 lots of 2-hour chunks and spread these out over 7 days. Even though we all agreed to try a design sprint and make it our biggest work-related focus, we also refused to let it become completely exhausting.
The activities and stages during the sprint followed the methodology developed at Google. Our sessions focused on:
- Understanding the problem and mapping the user journey.
- Interviews with subject matter experts.
- Sketching ideas using the Crazy 8s technique.
- Critiquing ideas.
- Storyboarding one cohesive idea.
- Feedback from subject matter experts.
- Start prototyping.
- Review and finish prototyping.
- Testing with users.
- Synthesising research.
Format: things to note
We had one or 2 sessions each day, depending on what else we had on. On the days with 2 sessions, we scheduled in a 2–hour lunch break which felt needed.
Prototyping took around 6 hours (2x 3 hour sessions) rather than the 4 hours we had planned and was pretty tiring, so I’d recommend splitting up the 2 prototyping sessions and spreading them over 2 days.
Organising and setting up the remote research took a couple of hours outside of the group sessions, so if you’re a facilitator or researcher, schedule in the extra time.
It would have been good to spread the research interviews out over a long morning so we could reflect on our observations together. As it was, it felt like we were cramming all the interviews into that 2–hour session.
Preparation and facilitation
Once the team had given the go-ahead for the sprint, I put together a plan that laid out the activities, the timings and the tools needed for each session. I had Annette Joseph and Emily Cowell as co-facilitators who gathered the problem statements and relevant materials beforehand, invited subject matter experts to the relevant sessions, and helped me find users to research with – I couldn’t have done it without them.
Agree roles and responsibilities from the start. As well as facilitators, it will speed things up if you involve at least one subject matter expert, as well as designers to lead the prototyping and user research. A mixture of skills and experience is really beneficial to a sprint.
Structure sessions so everybody gets to share. And related: decide how you’re going to interact. For example, will you all respond to open questions, or have cameras on?
Agree what you’re trying to learn with the prototype and decide the scope of the sprint. It’s easy to be overly ambitious but a design sprint is such a short space of time.
In our team, a couple of people hadn’t worked in this way before so at the start of each session it was essential to outline how it was going to work, how to use the tools and most importantly, the desired outcome of the next couple of hours.
I made the basic mistake of not checking what browser user research participants were using which resulted in technical difficulties and a last-minute change of plan.
Get the whole group to take part in synthesis – so everyone sees all the notes and engages with the learnings.
Online versus in real life
Plenty has already been written about the difficulty of facilitating sessions when you can’t read the room. I learned to avoid ‘open discussion’ style sessions, in favour of more structure. I asked participants to take turns to share by reading out the notes they were adding to the whiteboard.
I also felt that despite getting loads of valuable insights from the research, the team lacked that amazing buzz we usually have when we’ve just observed research in person, and we can’t stop talking about it. Maybe allowing time for team reflection after each interview could go some way to replicating that feeling.
Digital teams are used to working remotely and although some are more favourable than others, there’s usually a piece of software to help with remote collaboration. Lockdown has probably caused us to experiment with more of it, but use something you’re familiar with so you know it does what you need it to do for sprint sessions.
Here’s what we used:
Miro – an online whiteboard
In the absence of physical whiteboards and sharpies, the team used Miro to write and group post-its simultaneously. There’s also almost infinite space (unlike on our office walls), so we could keep all our notes and maps in one place, everyone could see everything at once because we weren’t in each other’s way, and there was no illegible handwriting.
Figma – for prototyping
We normally use Figma so there wasn’t much difference here.
Microsoft Teams – for video calls and scheduling.
Again, our usual.
User Zoom – for user research
User Zoom is a remote research tool that shows the prototype on the user’s screen and allows us to watch them using it via video. Very different from face-to-face research, and prototype on a device.
I’d do it again
Overall, the sprint went well – we went from no knowledge to a validated prototype in 10 sessions, and it didn’t feel like we’d compromised in our learnings or output.
It was a tiring 2 weeks, but we‘re proud of what we achieved. A remote design sprint is not without its challenges, but I’d be happy to run one again.