Contact the Service Manual team if you have feedback, questions or suggestions.


Services for government users

Civil servants are users too - it’s important they have access to services that are easy to use.

Good internal services reduce training costs and the amount of time spent dealing with errors. This gives people more time to provide a good service to the public.

Hold internal services to the same standard you would a public-facing service. In short, this means making sure they’re:

  • meeting a user need
  • safe and secure
  • fully accessible
  • easy to change and improve

This guidance covers services for government users, whether you’re building them yourself or buying them.

You can check if you need to get your service assessed.

Understand the problem you’re solving

To work out how best to meet your users’ needs, you’ll need a deep understanding of the tasks they’re trying to complete and the circumstances they’re working in.

Do not assume that an existing working process is a user need. Investigate whether a working process is necessary or can be improved.

Strike a balance between simplicity and users being able to achieve their task quickly.

Start with the design guidance in the Service Manual. It’s okay to deviate occasionally, but you’ll need to back up these decisions with user research.

For example, a user of an admin system might need to repeat and switch between tasks quickly. Or they might need to see all of the information they’ve input about something in one place to help them make a decision. This might mean it’s not appropriate to apply a one thing per page approach on all pages.

You may find this blog post with a set of civil servant user profiles a useful starting point towards understanding your users.

Who to research with

You’ll learn more about whether your service is meeting users’ needs if you test with users who have real-life experience of doing the tasks, and realistic data to test with.

It’s also important to test with a range of users, for example people who:

  • have different amounts of experience doing the tasks
  • work alone
  • work as part of a centralised team


In a 2018 survey, 10% of the civil servants who declared their disability status said they were disabled. Your service must be fully accessible according to the Public Sector Bodies Accessibility Regulations.

Make sure you test with disabled users.

You do not have to provide assisted digital support for users who work in the public sector (including contractors) and use your service as part of their work.

Do not design for specific hardware or software

Government workers often face technological constraints, like having to use old browsers or operating systems. Use web standards so the service is fully accessible and works on all browsers.

That way, the service will still work even if the department’s technological situation changes.

Bear in mind that your users might not be used to iteration and you might need to explain why you’re taking an iterative approach.

Logos and fonts

If your service is not on a domain, you cannot use the GOV.UK crown logo.

It makes sense for public-facing services to look and feel like part of GOV.UK, so users know they’re in the right place. This is not necessary for internal services.

You also will not be able to use the New Transport font. Use the Helvetica or Arial CSS font stacks instead.


As more services move into the cloud, there’s little difference between internal and public-facing services from a security perspective. They’re subject to the same threats.

However, services for staff often have highly privileged functions (such as access to sensitive data) which brings additional risks. When designing cloud-based services for staff, follow the same security approach you would when building a public-facing service and include these threats in your threat modelling and mitigation.

Find out how to make sure your information is secure.

Share your success stories

It’s likely colleagues across government will be trying to solve similar problems. Share your success stories by blogging or talking about them with the cross-government design community.

This will help teams see what’s worked previously.

Further reading

You might also find the following blog posts useful:

Last update:

Guidance first published