design sprint

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.

Online tools

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.

Rachel Hand
User researcher

Last week we launched an app that helps people view, order and manage their NHS repeat prescription from their phone. We want to make prescription ordering easy and convenient for people by providing self-service, simple collection and delivery options, and transparency throughout the process.

The app is very much a first version that we’ll continue to test with users and iterate on.

However, we think this is a good opportunity to talk about the work we did on a feature that we hope to add to the app soon.

Trying out a 5-day design sprint

As with many big, traditional organisations it can sometimes be difficult to move at pace within the Co-op. Design sprints can be useful to answer critical business questions quickly so we thought we’d give it a go. We got a group of designers, researchers, engineers, pharmacists, product managers as well as subject matter experts together for 5 consecutive days to build a realistic prototype. Having the relevant people in the room who could make decisions on behalf of their area of expertise was essential.

Design sprint: booking medical appointments

During the design sprint we were looking at how people book an appointment with a medical professional.

Together, we spent a day on each of the following tasks:

Defining the challenge.
Sketching ideas that might help us solve the challenge.
Choosing an idea to take forward, then storyboarding it.
Designing a prototype of the chosen idea.
Putting the prototype in front of users and listening to feedback.

Day 1: Defining the challenge

The first day allowed us to reframe the problem we were trying to solve. So, our week-long sprint goal was to build a simple, intuitive app for booking appointments for anyone registered with a GP in England. With this in mind we created ‘how might we’ questions, and turned problems into opportunities by asking questions such as:

How might we help people get the help they need, more quickly, so they can lead happier and healthier lives?
How might we be open and transparent about the process of booking appointments?
How might we update people about their appointment?

Working in this way encouraged everyone involved to see the bigger picture. It helped us think about our end goal and why we want to achieve it. Zooming out like this also helped keep us on track for the rest of the sprint when there’s a focus on detail.

Day 2: Sketching ideas

When it came to sketching out ideas for possible solutions to the ‘how might we’ questions, we used the ‘4-part sketch method’. It guides team members through note-taking and generating 8 rough ideas through to a ‘solution sketch’ – something slightly more carefully thought-out. Importantly, it asks that people work alone at this stage.

We found this really beneficial because when you’re working with people you don’t necessarily often work with, it can be intimidating. Working alone and then sharing ideas anonymously avoided extraverts and ‘leaders’ grabbing the most air time and encouraged more confident participation from quieter team members because they knew their ideas would later be seen and heard.

The solution sketches included chatbots; statistics dashboards and smart reminders as well as the use of video to explain complex processes and ideas that use artificial intelligence.

The next step was to choose which of these ideas we’d take forward into the rest of the sprint.

Day 3: Choosing and idea and storyboarding

On decision day, we put the solution sketches on the wall for everyone to see. The ideas were so wide-ranging which shows the importance of including colleagues from different business areas. It highlighted that we all have different priorities, but explaining our sketch solutions helped everyone understand where those priorities come from.

Using stickers, we flagged anything that aligned to our sprint goal which made it easier to see where or if we could merge different ideas. We then did a ‘speed critique’ which involved an impartial person talking through an idea that wasn’t theirs – it helped make sure everyone’s ideas were viewed equally.

Settling on one idea

After a vote, the team decided to combine ideas around organising different types of appointments, smart reminders and linking repeat prescriptions and appointments. This is what we’d take forward to prototype, but first we created a storyboard – a visual map of the user journey.

Day 4: Prototyping

The next day we brought the storyboard idea to life by creating a working prototype. Working in this way allowed us to quickly create something which we could place in front of users the following day to get their feedback.

These images show how reminders might work in the app.

Day 5: Getting feedback from users

On the final day of the sprint we put the prototype in front of potential users. We held 5 sessions in the Federation user research lab, and we visited 1 participant who had accessibility issues in their home.

Here are some of the things we learnt from the research:

People don’t just manage their own health, they book appointments for children, parents or grandparents too.
A big pain point in the process of making an appointment is waiting (particularly waiting on the phone for half an hour) Any way we can reduce the time spent on managing / booking the better.
People often have a preference about things like whether they see a male or female doctor, or their appointment time (for example, on their lunch break). Allowing people choice is important.
People were very positive about appointment reminders. They felt they helped them manage their health better.
Our service needs to be reliable with no technical issues. If there are issues a person is less likely to use a service like ours again and revert back to non-digital methods.

What’s next

We’ll be feeding what we’ve learnt back into the design process and improving the prototype. Now the app is live we’re also gathering customer feedback & seeing what the pain points are we need to work on next.

And we’ll continue to work closely with stakeholders because their expertise have been invaluable.

Lucy Tallon
User researcher

You can read more about the Co-op health’s proposed work.

Co-op Digital Blog

How to run a design sprint remotely