GDS Service Standard

Assess UK government services against the Service Standard published by the Central Digital and Data Office (CDDO) and the Government Digital Service (GDS). These 14 points are the only scoring framework this plugin uses.

Judge each point from evidence the team can show: research notes, decision logs, maps, prototypes, audit statements, telemetry, runbooks. A slide that asserts compliance is not evidence. A point is Met only when the evidence answers the criteria below for the phase being assessed. A point is Not Met when the evidence is missing, contradicts the claim, or breaches a red line in context/rubrics/.

Use these titles exactly in findings and in the published report.

1. Understand user needs

The team has learned about the people who use the service, including people who need help, and has based decisions on that learning.

Met when:

• Users are identified as cohorts, not as a single "citizen" persona. Cohorts include people who are digitally excluded, vulnerable, or acting for someone else.
• Research is first-hand. The team has watched people try to do the task, not only surveyed them or interviewed proxies.
• Findings name pains, workarounds, and constraints in the user's context (time, trust, documents, language, access to help).
• The team can show what they changed, or what they stopped, because of research.

Not Met when research is internal workshops, stakeholder opinion, or a single round used to confirm a design already chosen.

2. Solve a whole problem for users

The service solves the problem the user actually has, including the parts that sit outside this team's organisation.

Met when:

• The problem is stated as a user outcome, not as a system, a form, or a policy instrument.
• The team has mapped the end-to-end journey, including steps owned by other departments, regulators, suppliers, and the user's own advisors.
• Scope cuts are explicit. Anything left out has an owner, or the team explains why the user can still finish the task.
• "Do nothing", "join an existing service", and "stop" were real options.

Not Met when the team optimises its own transaction and leaves the user to re-enter data, phone a contact centre, or navigate a second organisation with no design for that handoff.

3. Provide a joined-up experience across all channels

Online, phone, paper, face-to-face, and third-party channels tell the same story and hand the user across without making them start again.

Met when:

• The team knows which channels exist today and which users depend on each one.
• Data and case state move with the user. Staff can see what the user already did online, and the user is not asked for it twice.
• Non-digital routes are operational, not a sentence in a policy document. Someone answers the phone or processes the paper, and the scripts match the digital service.
• Guidance on GOV.UK matches what the service actually does.

Not Met when the digital service is designed in isolation and other channels are "out of scope" or contradict it.

4. Make the service simple to use

A person who has the documents and the right to use the service can finish the task without learning the department's structure.

Met when:

• The team uses the GOV.UK Design System and GOV.UK patterns unless a tested reason not to is recorded.
• Content is in plain English. The team can show a reading-age check and the changes it caused.
• The fewest questions are asked. Questions the department does not need, or already holds, are gone.
• Users can recover from errors. Error messages say what went wrong and how to fix it, in the language of the task.
• The team has removed steps that exist for internal convenience.

Not Met when the interface mirrors the legacy case-management system, invents new patterns for standard tasks, or uses internal jargon.

5. Make sure everyone can use it

The service meets WCAG 2.2 AA. People who use assistive technology, and people who cannot use the digital service unaided, can still complete the task.

This point is non-negotiable. WCAG 2.2 AA is the minimum, not a target to grow into after go-live.

Met when:

• People who use screen readers (including JAWS and NVDA), screen magnifiers, and speech input (including Dragon) have used the service in research, and the team fixed what blocked them.
• An independent accessibility audit against WCAG 2.2 AA exists for a Beta or Live service, and open issues have owners and dates.
• Assisted digital support is a working route: how to get help, what the helper does, and how the case is recorded.
• The team has tested with disabled people and people who are digitally excluded, not only run an automated scanner.

Not Met when the only evidence is an automated scan, an internal "accessibility review", or a statement that the Design System is accessible. In Beta, if no participant used assistive technology, point 5 is Not Met. See context/rubrics/beta-red-lines.md.

6. Have a multidisciplinary team

The team has the skills to design, build, run, and iterate the service, and the service is not permanently dependent on a single supplier.

Met when:

• Product, user research, design, and technology are filled by people who do that work on this service.
• The team can reach policy, operations, content design, and performance analysis when the phase requires it.
• Civil servants can direct the work. Supplier staff are not the only people who understand the service.
• For Live, there is a funded team and a credible handover from suppliers to civil servants.

Not Met when a discipline is missing, borrowed for the assessment week, or unable to influence decisions.

7. Use agile ways of working

The team shows work early, changes course from evidence, and is governed in a way that allows that.

Met when:

• There is a visible cadence of research, build, and decision, appropriate to the phase.
• A decision log shows options discarded because of evidence.
• Senior stakeholders see working artefacts and can change priority. They do not only approve documents at stage gates.
• Governance measures outcomes and risks, not compliance with a fixed requirements catalogue.

Not Met when the plan, the architecture, or the business case cannot change in response to what the team learns.

8. Iterate and improve frequently

The team can release changes safely and has a habit of doing so. Improvement is driven by what they measure and what users hit.

Met when:

• Alpha spikes were thrown away or explicitly retired. The team did not polish a prototype into the production service by accident.
• Beta and Live services have a deployment pipeline. Changes go out in small releases.
• The team can point to a recent change made because of a drop-off, an incident, or a research finding.
• They can roll a bad release back.

Not Met when releases are rare, manual, or require a freeze, or when the team has no record of what they changed after the last assessment.

9. Create a secure service which protects users' privacy

The service collects the minimum data, protects it, and the team can explain the risks.

Met when:

• The team knows what personal data they collect, why, who they share it with, and how long they keep it.
• A data protection impact assessment (DPIA) exists before Beta processes real user data, and it has been kept current.
• Threats and security decisions are recorded. Dependencies and infrastructure are scanned in the pipeline.
• Access is limited to people who need it. Legacy extracts and spreadsheets are in the threat model.
• Privacy notices match what the service does.

Not Met when personal data is in unowned spreadsheets, the team cannot name a lawful basis, or security testing is deferred until after public launch.

10. Define what success looks like and publish performance data

The team has agreed what good looks like and publishes the mandatory performance data.

Met when the team measures and can publish:

• completion rate
• user satisfaction
• digital take-up
• cost per transaction

Also look at drop-off by step. A completion rate with no drop-off analysis hides where the service fails.

Met when baselines exist before public launch, a named person owns publication, and the measures describe the user's task rather than internal activity (applications received is not completion).

Not Met when success is "on time and on budget", or the data exists but will not be published.

11. Choose the right tools and technology

The team can justify what they will buy, reuse, or build, and they are not locked to a vendor by accident.

Met when:

• The choice follows the problem. Discovery explains constraints. Alpha tests the risky options. Beta records the decision in architecture decision records (ADRs).
• Commodity services are bought or reused. The team builds only what is unique to the problem.
• Buy-versus-build is written down, including the options rejected.
• The service can be moved. Data can be exported. Contracts do not block exit.

Not Met when a platform, framework, or supplier was chosen before the risks were tested, or when production infrastructure appears in Discovery.

12. Make new source code open

New code is open so others can reuse it and so the service can be maintained if the supplier leaves.

Met when:

• New source code is in the open, under an open licence, from early Beta rather than "after launch".
• Closed repositories have a written exception (security-sensitive configuration, secrets, or a genuine legal limit) and the rest is still open.
• A civil servant can get the code, build it, and deploy it without the incumbent supplier.

Not Met when the code is "available on request", owned only by a supplier, or open in name with a private history.

13. Use open standards and common platforms

The team uses government platforms and open standards unless they have tested a reason not to.

Expect the team to have considered, and normally adopted:

• GOV.UK Design System and GOV.UK Frontend
• GOV.UK One Login
• GOV.UK Notify
• GOV.UK Pay
• GOV.UK Forms

Also expect open standards for data, APIs, and accessibility, and reuse of registers or canonical sources the department already trusts.

Met when a decision not to use a common platform is recorded, costed, and based on a constraint the team tested. Not Met when the team built its own identity, payments, notifications, or form runner without that record.

14. Operate a reliable service

Users can complete the task during the hours they need to, and the team can detect, respond to, and recover from failure.

Met when:

• The team knows the hours of the wider journey, including phone and paper, not only the website.
• There is monitoring against a service level the user would recognise, with someone who responds.
• Incident runbooks exist and have been used or rehearsed.
• Disaster recovery has been tested and the result is recorded.
• The on-call model and the supplier exit plan work if the people who built the service are unavailable.

Not Met when the only hosting evidence is a cloud account, or when recovery has never been tried.

How assessors use this file

• Score only the points assigned to your skill. Say so in the output.
• Apply the phase guardrails in rules/phase-expectations.md before you score. A later phase's criterion is not a failure in an earlier phase.
• Apply context/rubrics/<phase>-red-lines.md. A fired red line makes that point Not Met.
• Write findings as observations tied to artefacts. Name the gap. Do not lecture the team with the standard restated.