Starting to build for real: what our third stage of service design looks like

Our team, Visible in Emergencies, is finishing its second stage of service design, testing options for solving our chosen problem: making more people visible in emergencies to the organisations that can support them.

Now we’re planning our next stage of service design. A stage sometimes referred to as ‘beta’. The third of four stages when designing services.

Stages of service design by Eliot Hill, UK government

Let’s go through what this third stage could involve for our team.

Building our best ideas for real

The most noticeable difference about our next stage is that we will start building our service for real. To get to this point we have taken time to:

1. Understand the unmet needs of people who experienced fires and floods
2. Test different ideas for making people more visible in emergencies to organisations that can support them to recover

With building our best ideas for real, our team will have different things to consider and design for.

Reducing new risks

Until now we’ve been concentrating on testing value proposition. In other words which ideas are more likely to solve our chosen problem. We’ve done this to reduce the risk of us starting to build a service nobody uses, wants or has any impact. Service design is all about reducing risk.

While we’ve reduced risks around our value proposition by testing it, in our next stage we will concentrate on reducing other risks.

These risks include building a service that is:

• hard to use for people who need support, who give up trying to do so
• hard to use for volunteers and staff, who revert back to old systems
• unreliable, breaking when it’s used
• insecure for collecting and keeping personal information
• expensive or slow to scale for increased demand
• over scoped with too many features and takes too long to deliver
• incapable of demonstrating what impact it’s having
• complicated and expensive to change and improve
• inaccessible to some people, such as those who don’t speak English or struggle with using with screens and the internet

Starting small

We can’t do everything. In fact it’s risky to try to. Our team is going do less and try to do a couple of things really well. So in building our service we’re going to start small. What that means is:

1. Start operating our service in just one UK region
2. Focus on one or two types of emergencies, most likely fires and floods as we’ve researched these most
3. Only include the minimum features needed to make people aware of support in emergencies and register their needs
4. Prioritise channels that support the most in need first
5. Collect the absolute minimum information to get someone support

Starting small reduces the number of things that can go wrong as we do the essential learning that can only come from running a live service.

Quickly learning from operational realities

We will test the support line we have prototyped in a live emergency

So far we have tested ideas with 5–8 people with at a time. People who in the past have experienced fires and flood or responded to one. When testing prototypes we have asked people to cast their mind back to the emergency. This has allowed us to get much more realistic and valuable reactions than if we had done research with people with no experience.

In this next stage we will be learning and iterating our ideas as realistically as it is possible to do: by trialling them in live emergencies. To do this we’ll be working more closely with frontline colleagues. Principally our Crisis Response team who’s work includes opening up a support line in emergencies and distributing cash to people evacuated from their homes.

We will keep being agile

Although we will be building our service for real, we will keep testing and improving our ideas. If something doesn’t work, we will change it. If something does work, we will improve it further, making it as useful, usable and intuitive as possible.

If anything, being agile becomes even more important as we support people experiencing live emergencies. We will have to respond to quick changes and the unexpected. Designing for surges in demand, people’s changing needs for support and frontline colleagues’ ways of working in these time-sensitive situations.

It’s both exciting and daunting to get to this stage. To make it less daunting, we will continue to work in sprints; breaking our goals for delivering value into manageable two-week blocks. There won’t be a big launch, but continuous learning and improvement for people using and running the service.

Measuring impact

Ultimately for Visible in Emergencies the impact we want is just that, making more people visible in emergencies to organisations that can support them. Our theory of change is that by doing this more people affected by emergencies will get more support, more quickly.

To measure the impact we want we will track things like:

• How many people contact us to get support
• How many people get support from us
• Time between an emergency starting and us making contacting with people
• Time between an emergency starting and people getting support from us
• How many people turn up at council rest centres
• How many people we make visible to other support organisations
• Time for us to make people visible to other support organisations
• Time it takes for people to get support from organisations we’ve referred them to
• How many people didn’t get the support they needed

We’re not in control of all these metrics, but they will help indicate if our service is doing what it’s supposed to. Already we’ve started trying to get baseline numbers for these metrics. For example how many people have turned up at rest centres in recent fires and floods versus how many properties have been affected.

Building a reliable, safe and scalable service

A prototype is the quickest way to test an idea. It just needs to work in the moments it’s tested. When it breaks it doesn’t do any harm to anyone. But in a real service it’s different: people are relying on it working. In emergencies a service being unreliable is made worse as people’s needs are so urgent.

A service being reliable can mean several things. For our team in this next stage it means:

• doing regular tests
• it doesn’t break in easily preventable ways
• when it does break it doesn’t do so the same way twice
• bugs and outages are quickly responded to
• people can trust it to keep personal information safe
• people can still use the service when demand surges

Alongside working more closely with our operational teams, we are doing the same with our colleagues in data, information governance and security to ensure our service is reliable.

We’ll keeping working in the open. Blogging about what we’re doing, learning and planning next.