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.
This guidance covers services for government users, whether you’re building them yourself or buying them.
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.
Don’t 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. This might mean it’s not appropriate to apply a one thing per page approach on all pages.
You can learn more about how people work across the civil service by downloading some civil service profiles.
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 2017 survey, 9.9% of the civil servants who declared their disability status said they were disabled. It’s crucial that your service is fully accessible.
Make sure you test with users who have disabilities or impairments.
You don’t 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.
Don’t 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 isn’t on a service.gov.uk domain, you can’t 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 isn’t necessary for internal services.
You also won’t 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.
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.
You might also find the Department for Work and Pensions’ blog post on designing services for colleagues useful.
- Published by:
- Design community
- Last update:
Guidance first published