SERVICE STANDARD
The Service Standard
What the UK Government Service Standard is, why teams use it, and what each of the 14 points means in practice for user-centred digital services.
The Service Standard is the UK Government's set of principles for designing and running good public services. It exists because digital services in government affect millions of people — often when they have no alternative — and poor design creates real harm, wasted effort, and duplicated work across departments.
Teams use the standard as a reference throughout delivery: shaping research plans, prioritising backlog items, and preparing for assessment. For transactional services, independent panels assess whether the team is meeting the standard at the end of Discovery, Alpha, and before going Live. The exact assessment requirements depend on your organisation and service type.
Tools such as UCDOps Agentcan help teams produce the artefacts these phases expect — research evidence, prototypes, and documentation — but the standard itself is about outcomes for users, not document templates.
Explore how the standard connects to delivery in our phase guides and framework mapping.
The 14 points
Understand users and their needs
Spend time with the people who will use the service and the staff who support it. Research should cover the full journey, including assisted digital routes. Teams demonstrate this with evidence of user needs, not assumptions.
Solve a whole problem for users
Design for the complete task someone is trying to complete, even when it spans multiple organisations or channels. Avoid handing users off to another service or paper form to finish what they started.
Provide a joined-up experience across channels
People may start on a phone, continue on a laptop, or visit a face-to-face location. The experience should feel coherent: consistent information, shared progress, and clear routes between channels.
Make the service simple to use
Strip away steps that do not help the user. Use plain language, sensible defaults, and progressive disclosure. Complexity in policy or process should be handled behind the interface, not dumped on the user.
Make sure everyone can use the service
Build for accessibility from the start — WCAG 2.2 AA is the baseline for government services. Test with assistive technologies and with people who have disabilities. Accessibility is not a polish pass at the end.
Have a multidisciplinary team
Bring together the skills needed to design, build, and run the service: user research, design, content, engineering, and policy at minimum. The team should be empowered to make decisions without constant escalation.
Use agile ways of working
Deliver in small increments, prioritise by user need, and respond to learning. Fixed specifications and big-bang releases make it harder to iterate when research shows you were wrong.
Iterate and improve frequently
Treat launch as a starting point. Use data from research, analytics, and support contacts to prioritise improvements. Services that stop iterating tend to drift away from what users actually need.
Create a secure service that protects users' privacy
Design security and privacy into the architecture, not as afterthoughts. Collect only the data you need, store it appropriately, and make users confident their information is handled responsibly.
Define success and publish performance data
Agree what good looks like — completion rates, time taken, user satisfaction — and measure against it. Publish performance data so teams and the public can see whether the service is working.
Choose the right tools and technology
Pick technology that fits the problem, the team, and long-term maintenance — not the newest option by default. Reuse existing platforms and components where they meet the need.
Make new source code open
Publish new code under an open licence so others can reuse and scrutinise it. Open source supports transparency and reduces duplicated effort across government and beyond.
Use open standards and common components
Adopt shared patterns, design systems, and data standards so services interoperate and users get familiar experiences. Custom builds should be justified, not assumed.
Operate a reliable service
Plan for uptime, incident response, monitoring, and recovery. A service that is down when someone needs it fails the user regardless of how well it was designed.
The Service Standard is published by the Government Digital Service on GOV.UK. GOV.UK content is available under the Open Government Licence v3.0. UCD Services explains the standard in its own words and is not affiliated with GOV.UK or the Government Digital Service.