Reflections on our discovery into floods and fires
We’ve come to the end of our 12 week Discovery phase to understand what people’s unmet needs are to prepare for, respond to and recover from fires and floods. This post follows Harry’s blog post about how we planned our discovery and is all about the lessons we learnt along the way, which will help us to improve the process next time round.
People find it hard before there’s a solution
We’ve been extremely fortunate to have really supportive senior stakeholders for our work. But even some of our strongest advocates have sometimes struggled whilst there’s no tangible idea or solution to get behind.
Whilst we never fully overcame this challenge, we did find some ways to frame what we were doing that made people feel more comfortable about the process and accepting of why it was worth 12 weeks of the teams’ time.
We talk about service design as minimising risk. Explaining that by spending time understanding people’s unmet needs it reduces the likelihood of creating solutions that people don’t use, want or that won’t impact their lives in a noticeable, positive way. This was received well.
Emerging design principles
Keeping our stakeholders involved with updates, little and often, helped to demonstrate how our thinking was evolving. As our discovery progressed, we also realised there were some recurring themes which were barriers to the current support available. Around half way through the discovery we started to compile these themes into emerging design principles which we would apply such as:
- Offer proactive support
- Enable dignity and self-sufficiency
- Give people control and certainty
Again, this helped our stakeholders to see that we were progressing in our thinking, without having to talk about solutions.
Synthesis takes ages
Each round of user research involved five depth interviews each lasting 45 minutes to one hour. We had two team members at each interview, one to lead the discussion and one to capture notes. There was a copy of this GDS user research poster in our pack which included some great advice for team members who were new to this type of research.
So at the end of each trip we had a big bunch of post it notes to synthesise. Starting with some of the key topics of our discussion guide such as ‘support’ and ‘preparedness’ we began to group post it notes, adding a note with the overarching insight above a group of stacked post-its. Once we’d gone through all the post-its there were often several very similar insights and sometimes some draft insights which needed a bit more work. We’d do a second sweep so that we ended up with a list of clear, well-evidenced insights.
This. Took. Ages. We averaged around two hours synthesis per interview. Turns out this is pretty average. It didn’t take long to recognise the cognitive strain of this process. After a few hours of synthesis we got increasingly slow and unproductive. To make it more manageable we tried to spread synthesis over a couple of mornings and focused on other tasks in the afternoon.
We are planning on adapting our approach in Alpha to have 2-week sprints. We will do our user testing and interviews one week, then protect three days of the following week for synthesis, discussion and planning for the next round of testing.
Don’t go through your own channels to find people to interview
One of the more important things we discovered through our user research is that in emergencies, organisations do not know who is in need or what their needs are as not everyone is aware of or wants to register.
Registration happens at a rest centre and when British Red Cross responds to emergencies we would usually be based in a rest centre. We simply would not have found this out if we only spoke to people who had been supported by British Red Cross.
We worked with a market research agency to identify people for our user research. We set the requirements out in a research brief — for example that we wanted to speak with five people in Aberdeenshire who had been affected by flooding. As the research progressed our briefs became more precise, focusing on those flooded due to weather-related incidents, and people who had to move out for at least a few days.
Pitching to senior stakeholders
Two things in particular really helped us when we pitched our proposal for alpha to our senior stakeholders.
1. Working in the open
The first was something we had practised throughout our discovery phase: working in the open:
- We regularly blogged about what we were learning and how
- We had weekly show and tells
- We emailed short updates every Friday
- We could often be found working by our project wall, meaning if someone had 5 minutes spare, they could come chat with us
This gave our stakeholders confidence in the findings we were presenting, without needing all the detail of the evidence we’d gathered.
2. Practice your pitch
This was so helpful as we had become too familiar with the subject matter and the evidence to be able to tell whether we were presenting a coherent argument. Our team also prompted us to include more of the real stories we’d heard through our user research, to bring the evidence to life much more. This made a big difference to the final pitch.
We’re moving into the Alpha phase of the work soon, so keep following our blog to learn about the problem we’re going to be focusing on and the ideas we’ll be testing.
