The Design Sprint is a practical process for answering critical business questions through generating ideas, rapid prototyping, and testing solutions, all in a few days. Jake Knapp invented the concept at Google a decade ago, and since then thousands of companies from small start-ups to large multinationals have run their own sprints.
OVO’s first design sprint took place in 2017 and last year the awesome Customer Interaction Platform (CIP) team ran one to improve the tools our agents use to help customers. In both cases, bringing people together in the same place with whiteboards, post-its and sharpies to focus on a problem was hugely rewarding and fun for all involved.
Fast-forward to 2020, and the lockdown situation brought about by COVID-19 has meant months of home-working. So when Lauren, our Billing Product Manager, wanted to run a design sprint focussed on estimated energy billing, we had no choice but to do it remotely. Fortunately, there’s a growing number of resources available to do just that.
On the website for the Sprint book (recommended reading to gain an overview of key concepts) there is a helpful guide on Remote Design Sprints from which we gleaned lots of useful pointers. Jake and his co-authors are careful to state that this is an opinionated “greatest hits” guide based on input from more than 100 people and personal views. While there’s no sure-fire recipe for success, we’d like to share how we did it, what worked well and what we’ll try next time.
Team
To start with, setting up a slack channel (#design-sprint-estimate-billing) meant we could kick-off conversations about the sprint, find out who was able to take part and post regular updates. This also helped firm up the dates, and as we learnt that 5 days would be a challenging commitment, we opted for the condensed 4-day version.
I also created a project page on Confluence which was open to everyone in the business. This explained the ‘what, why, when and how’ in one place, a handy reference point for anyone interested in finding more about what we were up to.
We assembled a team of different disciplines from engineering, product, design and copywriting. Product Lead Nicki was our decision-maker, a key role given extra voting power to apply as required. Agile Coach Ewan would be the facilitator to keep us on time and on track.
We also reached out to different experts across the business and invited them to an Q&A session on day one. Our job was to act like detectives, to interview them and capture notes as HMW (‘How Might We’) questions.
Schedule
As the name suggests, sprints move very quickly. So it’s important that the schedule is carefully crafted to make the best use of the time available. Ewan and I put together a google spreadsheet with detailed step-by-step timings and descriptions. At a high-level, the plan looked like this:
- Day 1 - Map & Sketch: Define the challenge (AM), produce solutions (PM)
- Day 2 - Vote and decide on solutions (AM), storyboard (PM)
- Day 3 - Prototype
- Day 4 - Test what we’ve made with real customers!
Tools
Using familiar tools where possible meant we could get up and running easily (for instance, Google Meets for video conferencing).
We picked Miro for our virtual whiteboard, and adapted this neat template by JustMad. Miro is a clever collaboration tool with loads of features built-in – however, one tip, remember to export boards as PDFs to keep an offline record of your progress. (And if you prefer Mural to Miro, here’s a helpful comparison.)
Our prototyping tool of choice was Figma. Our brilliant team of designers switched from Sketch to Figma this year, and it’s very impressive. As someone who began their career using Macromedia Freehand, I can claim with confidence that design software has taken a big leap forward recently. For our research sessions we had Lookback which allows the team to watch interviews, view the participant’s screen and take time-stamped notes. But this presumes we’d actually have people to interview, right? Let’s look at that next.
Research
One of the most exciting/daunting aspects of a design sprint is the intention to test with real customers on the last day. For this to happen, advance planning is needed. Ahead of the week, our researcher Karen started sending out recruitment emails, found participants and obtained the necessary consent.
By Thursday, we had 3 sessions lined up. Running research teaches us to expect the unexpected, so while we had some difficulties with participant’s connection speeds, Karen expertly navigated these challenges and we found out a lot from the interviews.
Learnings
At the end, we reflected on if we’d answered the sprint questions and what we needed to do to reach our long-term goal. Like many other design sprints I’ve read about, we didn’t have a breakthrough success but instead lots of learnings - some were small and actionable, others raised bigger questions about business and product assumptions.
We also ran a retro. Overall, the team enjoyed the format, collaboration and the opportunity to experiment and prototype. We also learnt that being on Google meet all day is tiring, and should have built in more breaks from the screen. Also we wondered if we tried to execute too many ideas and could have involved more of the team in the prototyping – useful points to reflect on.
Giving a playback of the Design Sprint at one of our company showcases generated enquiries from teams who want to try running their own remotely. If this is something that’s sparked your interest, I’ve listed some handy resources below that we found helpful. Let me know how you get on!
Resources
- https://www.thesprintbook.com/remote
- Google sheet containing Remote Design Sprint resources
- https://miro.com/templates/remote-design-sprint/
- https://www.mural.co/blog/remote-design-sprints-cant-work-can-they
- Design Better Podcast, Remote Design Sprints & Design Reviews
Thanks
Huge thanks to the team: Lauren, Nicki, Ewan, Oli, Sara, Karen, Fei, Rob; our experts Chris, Harriet, Vytautas and Davey; our research participants of course; and everyone else who made this happen!