What happens after our discovery into community resilience?
Our discovery into community resilience is well underway. So far our team has interviewed 20 people who have experienced floods or house fires, as well as people who have supported those experiencing these emergencies. Read Mieka’s blog post about some of the things we’ve already learned.
Although our discovery is far from finished, we thought it would be useful to say what our plans are for when it is.
Discovery is the start, not the end
Doing a discovery is not doing research for the sake of it. Its discovering unmet needs in lots of detail. It’s about learning enough to start designing a service; stimulating and informing ideas.
What follows a discovery is testing these ideas. This is the second stage in the service design process. A stage sometimes called the ‘alpha’ stage. An alpha stage is what sits between exploring a problem space like emergencies and building a service.
Prioritising what problems to focus on
Before we can test ideas for solving problems, our team will have to decide which problems to focus on.
Already there are lots of problems around emergencies our team could focus on. Getting temporary housing, accessing mental health support and keeping emergencies private to name just a few.
How do we decide which problems we should focus on after discovery? Knowing all we’ll know at the end of discovery, we can focus by answering questions like these:
- Which problems if solved will have most impact?
- Which problem is British Red Cross best placed to try and solve?
- Which problems do people affected by emergencies care about most?
- Which problems are easier or quicker to try and solve?
- Which problems are the ‘right’ size to try and solve?
In short – which problems have the most value in trying to solve?
Testing the value of different ideas
Once deciding what problems to focus on, it’ll be time to start testing different ideas to try and fix them. What we’ll be testing ideas for is something called ‘value proposition’. In other words why would someone want to use our new service? Be that someone affected by flooding, a local volunteer supporting them or a frontline worker helping to coordinate a response.
A common reason new services fail is because they don’t define or test their value proposition. That’s why it’s important to test ideas first — it reduces the risk of launching new services nobody uses, wants or has any impact.
A way of reducing risk further is testing multiple ideas for solving a problem. This stops us falling in love with a single idea. Meaning it’s easier to drop ideas that testing shows are unlikely to work.
Making prototypes to test ideas
Testing the value of ideas sounds a bit abstract. How will our team practically do this? The answer is by making and testing prototypes.
As one of my colleagues who works emergency response pointed out – not everyone knows what a ‘prototype’ is. So here goes, a prototype is the easiest way to test a hypothesis about how to solve a problem. What that looks like in practice will vary but could include quickly making fake websites, physical products or other solutions we can test with people.
Hypothetical example
Let’s use a hypothetical example to show what I mean. Say we focus on reducing the distress caused by not being able to cook in homes damaged or destroyed by floods and fires.
One way to try solve this problem might be to coordinate local restaurants to provide hot meals to people after an emergency. To test this idea, we could make a fake website for restaurants owners to sign up to the service.
The hypothesis we’d be testing with the prototype is local restaurants are willing to be coordinated to provide hot meals in potential emergencies.
We could then test this prototype in something called a usability lab – a place where a team can watch people try to use their prototypes and see how they react to them. In one room someone is shown prototypes by somebody from the team and is asked to use them. Meanwhile in another room, the rest of the team observes and takes notes, watching through either a camera feed or one-way mirror.
In our hypothetical example we could invite restaurant owners who live in towns and cities at high risk of flooding. In a single round of testing, a team would typically test prototypes with 4–6 people. The project team will be interested in people’s thoughts on the concept as well as how user-friendly the prototype is.
Multiple rounds of testing and iteration
In the alpha stage we’ll do 8 rounds of testing, as is the norm in service design. Each will last a week — this is what is known as a ‘sprint’. We’ll iterate ideas that show promise and discard ones that don’t.
After these 8 weeks, we’ll move to the third stage of service design–building and refining our most promising idea.
But right now we’re still in discovery. Learning and exploring the problem space of floods and fires. Getting into the detail of the problems people in these emergencies face.
Stay tuned to our blog to see what we’re learning.
