I was recently involved in a 12-week Discovery project looking at improving the customer experience for citizens in receipt of multiple benefits. As part of a 9-strong team of both DWP colleagues and external contractors, my role as interaction designer quickly became focused on organising and facilitating a Design Sprint.
A Design Sprint is a 5-day co-designed workshop, aimed at rapidly generating solutions to a business problem, with an emphasis on collaboration, solution sketching, prototype building and user testing. Initially outlined in a framework by Google, Design Sprints are now an established methodology in the user-centred design toolkit.
As an interaction designer with a varied design background - from an architecture degree to graphic design work, through front-end development and user interface design - I have facilitated Design Sprints and many other kinds of workshops in the past. However, never in a purely remote fashion. I knew it would be an interesting challenge.
We came out of the Design Sprint having identified some innovative solutions to business problems. Though exhausting, I thoroughly enjoyed planning and facilitating it, and I learnt a lot during the process. With that in mind, I've collated some tips I would have found useful to know before I started the process.
1. Clear plans are crucial - even more so when working remotely
I spent several weeks planning, working closely with the rest of the Discovery team, in particularly the service designer. To start, we identified the key stakeholders we wanted to involve. Beyond the core Discovery team, we wanted to encompass the insights and experience of colleagues from across DWP. The Discovery’s product manager set about using her contacts to get different areas of DWP to suggest possible attendees.
We ended up with 12 core participants and 5 or so other passing contributors. I immediately ensured all involved had their calendars blocked out for the 5 days of the Design Sprint - not an easy task in this era of back-to-back calls! I had a rapid video call with the attendees I’d not yet worked with to introduce myself and to set expectations. This was particularly crucial for colleagues outside the digital sphere for who this kind of co-design sessions was unfamiliar.
The second focus was pulling together the relevant findings and insights so far to get people up to speed. We organised a set of lightning talks for the first day of the Sprint to help build a common understanding. This also included 3 speakers from outside the Discovery, covering topics such as accessibility and design for the digitally excluded.
2. Find a focus for each day and plan around people
It was clear from the start that many colleagues would have unavoidable commitments throughout the Sprint, so it was important to plan around these, particularly when it came to breakout rooms. Also, regular breaks are crucial in any Design Sprint, even more so in a virtual setting.
In order to manage everyone’s commitments, I created a spreadsheet to capture the participants, who was available and when. The planning of the schedule was done in basic note form - from my perspective activities rarely fit into neat 15 or 30 minute slots, so a spreadsheet doesn’t work very well. The planning of activities and time-boxing them was only worth doing in absolute detail for the first couple of days. As such, the precise plans for rest of the Sprint got vaguer as the days progressed. I focused mainly on an overall aim and output for each day which worked well.
3. Ensure everyone gets a chance to familiarise themselves with tools ahead of time
I used an interactive whiteboard tool, and created a board per day as the focus for all activities. In the week before the Sprint, I created 2 other boards - one I called ‘Sandbox’, and the other I called ‘Intros’. I sent these to all participants, with instructions to use the former to familiarise themselves with the tool ahead of time, and establish that they could access it without issue. This worked well and mitigated against wasted time giving instructions or solving technical issues.
The second board then included some ‘intro cards’ and I invited participants to add a photo of themselves, their name and role, and answer a few informal icebreaker questions if they were comfortable doing so. In a remote workshop anything that helps personalise procedures is helpful.
4. Make time for intros, icebreakers and warm-up exercises
On the first 'ideation' day, I asked all participants to attach something we could use as inspiration on the day’s board. We then started the workshop by running through these. I felt it added a personal touch to proceedings.
I had concerns about using Crazy 8s-type ideation activities without using pen and paper and sketching. Instead, I asked participants to spend a few minutes representing a hobby of theirs using the tools available: icons, importing photos, or even drawing using a mouse/touch screen. We then had to guess everyone’s pastimes. A warm-up, icebreaker and familiarisation with the tool all in one – really effective! Interestingly, many participants chose to simply describe their ideas using words when it came to ideation activities – which ultimately meant less ‘I can’t draw’ worries than during a physical Design Sprint.
5. Make time for just-in-time planning of daily activities
You never know exactly what is needed for the next day until the current day is over. On the days of the Sprint, I organised a call with the project manager and service designer first thing to run through plans for the day. We had another ‘debrief’ at the end of the day’s activities to talk through how things had gone and help make final plans and tweaks for the following day. Unavoidably, this entailed a fair bit of just-in-time planning of precise activities and breakout room participants. In a physical Design Sprint, it is far easier to pivot as a facilitator - as long as sufficient wall space and Post-Its are available! It became apparent that a remote Sprint can be approached in a similarly nimble fashion - but that it entails a lot of last-minute work to adjust activities and artefacts to suit the unavoidable twists and turns. This needs to be factored into the planning and resourcing.
I also finished each day with ‘1 minute retros’ - giving participants an opportunity to feed back. These were invaluable, as some crucial housekeeping emerged, for example around keeping track of tangent discussions occurring in the chat panel, something that could easily be missed as a facilitator.
I certainly learnt a lot facilitating a remote Design Sprint for the first time. I hope some of these tips prove to be useful for any remote workshops you’re planning to embark on.
6 comments
Comment by Michelle Butler posted on
This is a really interesting, insightful Blog Ben with some great tips, not only for Design Sprint but running them virtually. Thanks for sharing:)
Comment by Fay Cooper posted on
We are so lucky to have talent like yours, Ben!
Comment by Michael Norrington posted on
Solid advice there Ben, thank you. Hope you got what you wanted out of the week.
Comment by John David Ingleson Esq. posted on
Very impressive, 'love all the fancy buzzwords - I understand that you may be doing this "for the first time" but where in this process are the capture of issues and concerns of your ultimate clients - the benefit claimants?
I can see no engagements in your overview with the primary stakeholders to identify use-case scenarios with your ultimate clients -- the claimants -- inputs that are so essential to ensure that your design goals are met for the beneficiaries --- to prioritise that your methodology is not just an expensive navel-gazing exercise that superficially appears to cover all bases so as to 'tick all the boxes'?
I see you proudly proclaim that "we wanted to encompass the insights and experience of colleagues from across DWP" but, perhaps, more importantly, how and where have you included basic essential end-user planning and design feedback input into the IT architecture?
Maybe I'm being a bit harsh, that I'm missing something -- so therefore I would be grateful for you to please elucidate where your primary stakeholders' input originates to be incorporated into the solution? TIA
Comment by Ben Fraser posted on
Thanks for your comments John. To clarify, the focus of the blog was to give some useful practical tips for anyone facilitating a design sprint remotely - not the underlying methodological approach to solving design problems in a user-centred manner, which we feel is already very well established and an integral part of design sprints.
In the case of the mentioned discovery project, the majority of our efforts leading up to the design sprint were focused on primary user research and talking directly to benefit-claiming citizens. As such, the first day of the sprint was spent creating a shared understanding some of the problems citizens claiming multiple benefits face when using DWP services. The subsequent sessions were based on the user needs identified through the user research, with a focus on establishing technically-viable solutions. The solutions that emerged from the sprint were tested with citizens and will be subsequently iterated and tested again.
Ultimately, I'd like to think we approached our design sprint in a user-centred fashion, with the needs of citizens at the heart of the process.
Comment by Steve Warburton posted on
Thanks for taking the time to share your insights Ben - It is great to see innovation in action and sharing the outcomes of your own experiences with colleagues who can benefit from them is always a great thing to do.
People will like what they read, or not, but if they do and can improve even a single aspect, even slightly, through the hard work and sharing of others then the effort that goes into writing and sharing a blog, is effort well spent, if many people take this approach, the incremental gains become very powerful - Keep up the good work!