As we go about redesigning public services to be clearer, simpler and faster, we sometimes hear things like, ‘civil servants are users too.’ And of course they are.
Internal users in many kinds of organisations can be inhibited by the systems they work with, particularly those working on the frontline or behind the scenes.
We all talk about ‘users’, but there are many kinds of people involved in a service. When we redesign larger services to better achieve policy intent and meet user needs, we have to understand important distinctions such as:
- what the end user is trying to do and what their needs are
- what the people involved in delivering or providing a service are doing and why
- what it’s like to be the user of an internal product or system
- what actually needs to happen behind the scenes – not just what’s currently happening
When we conflate what end users need with what people providing a service want, we end up with poorly designed, inefficient services that aren’t easy to use.
Equally, when we confuse what needs to happen with how something is done today, we make the mistake of designing ‘digital’ versions of the same thing without addressing the problems.
The aim is for services that are effective and efficient, that are fundamentally better and easier to change in the future.
Key questions we need to ask are:
- are we redesigning an internal system that has users?
- is this system part of a wider service for end users?
If it is, we need to look at the wider service that’s delivered by people behind the scenes so we don’t just redesign the existing system.
The perspective we take can result in very different outcomes.
Design based on what actually needs to happen
Let’s say we’re redesigning a casework system. We might watch people using the current system to see what makes it difficult or easy to use. Policy might work closely with the product team to make sure the system reflects the right criteria and that internal users apply the rules correctly and consistently.
We might watch caseworkers use prototypes of the new system to learn what works and doesn’t work. We could list the things the system has to do and we might apply the GOV.UK style guide.
While there are lots of positives with this approach, there’s a good chance we’d essentially design the same system again based on how things currently work, although it might be easier to use.
Let’s run that scenario again but look at what needs to happen. Rather than talk about a ‘casework system’ we’d look at the wider service. This part of it is there to decide if someone gets permission to do something.
We’d see that the activities behind the scenes are:
- comparing data against set criteria
- assessing suitability
- assessing eligibility
- making a decision
- recording an outcome
- notifying the user
These activities are the things that will still likely need to happen even in 10 years’ time, whether it’s a human doing this, a computer, artificial intelligence or some other way we haven’t imagined yet.
Perhaps we’d see that this activity takes significant time and resources because of the high volumes and what currently happens. Waiting for an answer can be really difficult for end users, who then spend time trying to find out what’s happening – and government bears the cost of that.
Even if we can make a casework system that’s easier and faster to use, building something that someone still has to manually operate won’t necessarily solve these problems and it probably won’t scale or allow us to radically cut the time it takes to make a decision.
If we considered what actually needs to happen, we’d talk about the project in terms of ‘how we make decisions about an application more effectively and efficiently’, not ‘casework systems’.
We could find practical ways to measure what we mean by this and make a clear and simple statement about what we’re aiming for – the time it should take or the resources involved – to make a decision.
By rethinking policy, process, content or technology, we open ourselves up to the many possible solutions we have.
A few of these are:
- simplify some of the criteria we’re using to reduce effort
- explain more simply and clearly what we need – and why
- design an application that works better for different scenarios across many services by looking at unchanging activities such as assessing suitability and eligibility, rather than on current workflow
- gather data by going to original sources and verifying it digitally rather than working with paper copies
- use information from digital government records
- use computers to compare data against set criteria automatically, where possible and appropriate
- check eligibility and suitability as an application is being filled in rather than after it’s submitted
- use computers to identify complex cases that need people to evaluate them in depth and train then use algorithms to learn how to improve effectiveness or efficiency
Thinking through these options takes many disciplines, including specialists in policy, user research, operations, security, legal, data, delivery and technology. The right approach is to learn which combination of these options will work best and to better understand what the challenges are.
The best service is where no one needs to do anything
To use public resources effectively and efficiently, we must not simply build digital-and-slightly-improved versions of the same old systems or workflow. Teams need to work on clearly identified problems and outcomes, not just build new systems.
When there is a logical and considered rationale for doing something tactical to buy us time, we still need to work out how to remove current constraints for the future.
And we need to give specialist digital teams room to fundamentally rethink the best ways of delivering the outcomes we’re after and measure progress on that basis.
2 comments
Comment by Kate Streatfield posted on
Yep all true. Trouble is - it's internal services people who give you the money to do stuff (and he who pays the piper etc). I wonder what would happen if service end users could decide how and what things get funded?
Comment by Dave Mason posted on
Good clear presentation. I especially like "When there is a logical and considered rationale for doing something tactical to buy us time, we still need to work out how to remove current constraints for the future."
With this in mind, I might add one aspect. Any project needs to factor in what is affordable, because the cash available frames what is achievable. Indeed, you can still have an eye for the future and phases yet to be resourced can be mapped and (hopefully) correct ground work laid. So many projects fail because this is not properly addressed in the very early stages - what can we afford? Then, design the phasing to keep the door open for future changes.