Beta This is new guidance. Complete our quick 5-question survey to help us improve it.

  1. Service manual
  2. Design
  3. Getting your service scope right

A service can only be easy to use if it’s easy to understand.

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.

Solve one whole problem for users

Sometimes government offers several solutions to the same problem.

For example, students can apply for a grant, loan and a bursary to help pay for their higher education.

Bringing these things together in a single transaction makes sense: it helps solve the user’s whole problem – paying for university – without asking them to provide the same information twice.

If your service scope is too narrow, it won’t fully solve the user’s problem.

For example, it’s not uncommon for private sector organisations to offer multiple services, schemes, rates or tariffs that overlap in terms of the needs they meet. That’s part of how they position themselves and compete in the marketplace.

But it adds complexity: users have to work out what deal is best for them.

Government doesn’t have to do that. We can do the hard work to make things simple and build services that solve a whole problem for users.

Start with one service per problem

It can be helpful to offer users the chance to use another transaction after they’ve completed a transaction (or if it turns out they’re not eligible to use the first transaction).

But people generally want to complete one government task at a time – so there’s usually no advantage in making a service serve more than one purpose.

And if you try to solve several problems with one service, you’ll struggle to give it a descriptive name and users will struggle to find it and understand what it’s for.

For example, the Environment Agency (EA) is breaking the ‘What’s in your backyard?’ service into several smaller services. Doing things this way lets the user access the thing they need directly, and makes it easy to give each service a descriptive name - for example, ‘Sign up for flood warnings’.

So start with one service per thing. And only bring transactions together into a single service if:

  • you can’t solve the user’s whole problem without bringing separate transactions into one service
  • you see in research that users think of a group of separate tasks as part of the same problem - this will be obvious from the language they use

Otherwise, keep things simple. Government services are already in one place – on GOV.UK, where users can get to them through search and navigation based on the tasks they want to complete.

Don’t let organisation structures or technical choices dictate service shape

Users shouldn’t have to understand the structure of government to access services. So it’s important to group services based on tasks rather than the organisations providing them.

Don’t let technical choices dictate the shape of your service. For example, services that need it can use a common authentication system without necessarily being brought together into a user account.

If you start with separate services, you can always bring them together later. It’s usually much harder to do it the other way around.

Only put information inside a service if it needs to be there

It’s important that users can find the information they need, and they won’t find it if it’s hidden inside a transactional service. Especially one that’s behind a user account.

So only put information inside a transactional service if it’s an integral part of the transaction.

For example, you might see in user research that a user is struggling with a particular question. It makes sense to provide more information at this point in the transaction: just enough to let the user answer the question. You’re providing information at the point of need.

If the information isn’t an integral part of the transaction, publish it as guidance on GOV.UK so it’s easy to find.

If information needs to be inside a service, put it there

Provide all the information a user needs to complete a transactional service inside the transaction. Avoid sending users outside the transactional ‘tunnel’, because they may struggle to find their way back. That might mean duplicating small amounts of information on GOV.UK or within other transactional services.

On the other hand it’s a good idea to provide external links to the user once they’re finished with the transaction – either because they’ve completed it, or because they’ve been told that they’re not eligible.

Published by:
Design community
Last update:

Updated guidance on getting service scope right, when to put information inside a transaction

  1. Guidance first published