WIREDGOV

Blog posted by: Joe Harrison and Louise Miller, 17 May 2018 – Categories: Content design, Ways of working

As we mentioned in a recent blog post, the way government thinks about services is changing.

We’re moving from looking at isolated transactions to whole, joined-up, end-to-end services as users understand them. Like learning to drive, or starting a business.

To work in this way, government needs a new service standard that supports and encourages this changing approach to services.

Teams will also need new guidance to help them implement the standard and create and run great services.

This will pose challenges for those of us writing guidance for the Service Manual, which is a collection of guidance for teams building government services.

To work out how best to tackle this challenge, we started by consolidating what we know about our users.

Our user groups

We carried out some user research on the Service Manual in the middle of last year. As you might expect, we found that people need a range of different things from our guidance depending on their level of experience.

People newer to government services or agile ways of working need:

• ways to get up to speed quickly
• information about their role and what’s expected of them
• examples showing how principles have been put into practice

Those with more experience and expertise want to use Service Manual guidance for more complex things like:

• teaching and training other people
• bringing about culture change

This group also said they have to decide how to balance what the guidance says with what their team can realistically do.

Any guidance we write needs to work for both of these groups, as well as nudging less experienced practitioners towards becoming experts in their fields.

Our new guidance model

As a result of this, we’ve come up with a new model for writing Service Manual guidance. It’s a model that we think will meet the needs of all our users, regardless of how experienced or confident they are about running a government service.

We’ve also been thinking about some of the concerns raised by the National Audit Office (NAO) in their ‘Digital Transformation in Government’ report. The report suggested that GDS guidance wasn’t doing enough to help teams implement our standards in practice.

We think our new model goes some way to fixing this for the Service Standard and Service Manual.

The new guidance model is based on a few principles.

Expose the ‘why’

We think it’s a good idea to start a piece of guidance with a summary statement or principle, and to explain why that principle is important.

Something like the following, from our service scoping guidance:

The best way to make your service easy to understand is to frame the problem it’s solving in a way that users understand, using the language they use.

If your service scope is too broad, it won’t be obvious what problem it’s solving. And users won’t be able to get straight to the task they need to complete.

If your service scope is too narrow, it won’t fully solve the user’s problem. So users are less likely to get the outcome they need.

Introducing the guidance in this way works well for a few reasons.

Firstly, this is probably all the detail an expert practitioner needs, so they can stop there. They’ll understand what they’re being asked to do and will likely have a good idea of how best to do it.

It’s also useful for people new to building government services. Understanding the ‘why’ is a crucial step in the journey to mastering a topic and becoming an expert.

It’s helpful for stakeholders, too. Exposing the thinking behind a principle or piece of guidance makes it easier for teams to explain why a certain approach is or isn’t the right way to go.

Provide practical examples

While principles are important, we acknowledge that they won’t provide enough detail for everyone.

People new to government in particular will need more help to implement an approach, or make a decision.

This was one of the criticisms the NAO made: that the high-level nature of GDS guidance "[left] scope for interpretation and disagreement".

There’s an issue here, though. Across government, teams are working in different ways, designing different services for vastly different user groups.

This means that there simply isn’t a one-size-fits-all approach to doing a thing. To some extent, the guidance needs to be open to interpretation, so teams can apply it to the context they’re working in.

The National Cyber Security Centre has faced similar issues with people asking for definitive guidance about very nuanced issues.

We can still help service teams make good decisions, though, even if we can’t give them a single implementation model.

By providing a range of models from across government and beyond, we can help teams understand how particular problems have been solved previously. With some context, they’ll be able to see which types of approach have worked in circumstances similar to their own.

It’s fine to ask service teams to use their discretion: we trust them, and it’s part of their job.

Invite people to collaborate

We want to make it easier for people with a lot of experience to share it. We want people to challenge us where they think we could improve things, and pitch in if they’d like to.

And of course, we’ll continue to do research to understand our users’ needs in greater depth.

What about service assessments?

This guidance model should help us move the Service Manual in the direction we think it needs to go.

We believe the manual should serve 2 main purposes:

• help teams build the best possible services for users
• share best practice with people new to government

The manual shouldn’t simply be a resource to help teams get through a service assessment. If you’re building a great service, the assessment will take care of itself.

To make sure you don't miss any future updates on this work, sign up for email alerts.

What we’re doing to make it easier to blog at GDS