We’re currently updating the Digital Service Standard. The standard exists to help government build and run effective, user-focused digital services, and came into force in April 2014.
We’re updating the standard partly because users’ expectations change as technology changes. And partly because we want to move from looking at isolated transactions to whole, end-to-end services. Services as users understand them. This reflects a commitment in the Government Transformation Strategy to design and deliver joined-up services.
We need to make sure that the new standard supports everyone in government who is involved in designing and delivering services – no matter which role or organisation they’re in.
So we’ve been working with colleagues across government to work out what challenges the new Service Standard should address. Here’s what we found out.
Workshops and wider discussions
We worked with teams across government to understand their experiences of using the current standard, and to get insight into the challenges government would want a new version of the standard to meet. We ran 4 workshops across the UK: in London, Sheffield, Newport and Newcastle. Around 150 people came from a diverse range of roles – including digital, policy and front-line operations. And for people who couldn’t come to the workshop, we set up a Google group.
From these workshops, a number of themes emerged that we’ll consider in the next version of the standard.
1. Support end-to-end services without impeding delivery
There is a huge ambition to transform services from end to end. Digitising existing processes isn’t the goal.
So it’s important that the standard supports progress towards end-to-end services, from the point where the user starts trying to achieve a goal to the point when they’re finished. This includes website content, the transactional part of the service, the phone, post and face-to-face channels, as well as the digital elements. And it includes the internal processes that government needs to deliver an outcome.
But it’s also important that it doesn’t stop services being built quickly and incrementally. Progress – even if it’s not perfect – is better than stasis. We also need to find ways to encourage and support the retirement of services when they are no longer meeting user needs or serving a purpose for government.
2. Solve whole problems for users
The new standard should help to align services to things that users are trying to achieve. Such as learning to drive, or starting a business. We need a way to build a shared understanding of what those user needs are and a way to decide on a collective approach to meeting them.
This is partly about openness. The more we can do to encourage service teams to be open about what they’re doing, the easier it is to spot opportunities for collaboration and avoid duplication. For example, by publicly sharing roadmaps, business cases, experience maps and prototypes.
But openness alone won’t be enough. We need a standard that makes it possible to assess whether the right problems are being solved in the right way, by the right people working together. And we need to be able to identify who owns the whole problem and the whole service that cuts across team and organisational boundaries.
And we need to make it easier for teams across government to share knowledge, research and analytics. People thought this could include supporting new approaches to data infrastructure. Others suggested a central list of APIs.
3. Promote working across organisational boundaries
Solving whole problems for users often means working across organisational boundaries.
That’s hard. There’s a perception that it increases risk, because it’s not certain that two organisations will treat the problem with the same degree of priority. Plus government funding and governance processes have traditionally been designed on a departmental basis.
But the Service Standard can and should help to encourage this way of working. One participant put it really well:
Outcomes are the glue that holds departments together.
4. Revisit the discovery, alpha, beta and live phases
Some people felt there was a need to revisit what each of the phases of service development – discovery, alpha, beta and live – are for. In particular, there’s sometimes a tendency to arrive at discovery or alpha with a solution already partly defined, rather than using the discovery and alpha phases to learn about the problem and experiment with different solutions.
Other people felt that a new, post-discovery check point would help make sure that service teams have sufficiently explored the problem space before they start experimenting with solutions during alpha.
5. Broader approach to accessibility and inclusion
Government services should be accessible across all channels. If the accessibility of non-digital channels is neglected, that’s a problem because some transactions can’t be completed in one channel.
There’s a need for more patterns showing how to use offline channels effectively and how to make service-specific decisions about channel priority.
6. Don’t break things
People liked the idea of a standard that supports end-to-end services. But they identified some risks.
Digital teams use the current standard to make the case to stakeholders for investing in user-centred services. Some people wondered whether expanding the standard would make that more difficult.
It’s important that the assessment process retains authority, and that online services which don’t meet the standard don’t go live. It’s also important to get broad buy-in to the approach, since we’re asking people to consider how the user’s experience of the service is affected by a wider range of things.
We definitely want to avoid unintended consequences that make it harder for government to deliver services that meet user needs – and to deliver quickly. So we’ll make sure the new standard reflects that. And we’ll keep consulting and testing our assumptions.
7. Wider context: culture and governance
It’s not easy to build end-to-end services that meet user needs. That’s partly because it means people from different professions tend to have different working practices.
For example, the digital, operations and policy professions can have very different expectations about how far outcomes should be specified early on in the process. And we tend to work in very different cycles.
A new standard could raise the visibility of those challenges and help the professions work together to build the best service for users.
Other things that might help include developing more examples of service design and policy working together – such as the work of Policy Lab. And giving people ways to get an insight into how the other professions work – for example, service design training for policy makers.
What’s next
This has been a truly collaborative process from the start – thanks to help from colleagues across government, we’ve got a good idea of the main challenges the new standard needs to meet.
We’ll share more on our current thinking soon, so we can get further feedback from teams across government and hone our approach.
Once we’ve gathered this feedback, we will run a pilot with a small number of services so we can make sure we’re providing the right support to service teams going through the assessment process and to our-cross government service assessors. As part of that work, we’ll work out the best way to to phase the introduction of the standard so that service teams have plenty of opportunity to prepare before it’s implemented.
1 comment
Comment by Andy Jones posted on
Way to go everyone. I'm trying to inspire staff and customers to take up digital services. But isolated registration services, lack of e2e or one complete journey is holding back not just customers but also staff. They're finding it difficult to justify why customers should use say a registration process and then go back to phones, paper or F2F to continue the journey. This approach looks like common sense on a stick.