The 14 points of the Service Standard and what to show a panel

The Service Standard has 14 points. GDS publishes them in the Service Manual and an assessment panel checks your service against them. If you are developing a transactional service for central government, GDS says you must get it assessed, and that includes a service only civil servants use.

Each heading below is GDS’s exact wording. Under it is what GDS asks of the team and what to show the panel.

1. Understand users and their needs

GDS asks the team to do user research, build quick throwaway prototypes to test its hypotheses and use data it already holds, such as web analytics and call centre records. Show the panel who you researched with, what you learned and what you changed as a result.

2. Solve a whole problem for users

Show how your service joins up with the other things a user has to do, including the parts another organisation runs. GDS also asks whether someone has solved the problem already, and whether you considered an alternative to building a service, such as publishing content. Name any constraint, such as legislation, and say what you did about it with policy colleagues.

3. Provide a joined up experience across all channels

Show that your designers and user researchers work with front line operations staff, and that you test and can change the offline parts, such as call centre scripts and letters. Tell the panel how the people who answer users’ questions keep up with changes to the online service.

4. Make the service simple to use

GDS asks the team to test usability often, with actual and potential users, on every part a user touches, letters included. Show the rounds of testing, what you changed after each and whether people now get through first time without help.

5. Make sure everyone can use the service

Show the research you did with people who have access needs, how the online and offline parts meet accessibility standards and what help you give people who lack digital skills or internet access. Before public beta, GDS asks for the results of your accessibility audit.

6. Have a multidisciplinary team

Show who is on the team now, who you will need in the next phase and where you get specialist advice, such as legal or policy. If contractors or suppliers do part of the work, GDS asks that you set that up “on a sustainable basis”, so say what happens when their contracts end.

7. Use agile ways of working

GDS describes this as “inspecting, learning and adapting as they go”. Show how the team plans, give one thing it changed after it learned something, and say how the right people hear what is happening, up to the minister or chief executive. GDS expects your governance to fit its six governance principles for agile service delivery. The first is “Do not slow down delivery”.

8. Iterate and improve frequently

Show that you will have the people, the money and the technical freedom to keep improving the service after launch. GDS writes that a live service can run without a full team all the time, but the team must be able to make substantial improvements for as long as the service runs.

9. Create a secure service which protects users’ privacy

GDS says service teams must follow the Secure by Design principles. Show your assessment of the security risks, your plan and budget for managing security through the life of the service and how you collect and store data. The senior leaders accountable for security have to know the risks, so say who they are and how you told them.

10. Define what success looks like and publish performance data

Show the measures that tell you whether the service solves the problem, and a decision you made with them. GDS lists four measures a team must publish: cost per transaction, user satisfaction, completion rate and digital take-up.

11. Choose the right tools and technology

Show why you built some things and bought others, what the technology will cost over its life and how you could change direction later. GDS asks the team to understand how its technology works, AI included, and to manage any legacy systems the service depends on.

12. Make new source code open

Show the open repository where the team publishes its code. GDS asks teams to write code in the open from the start and to keep secrets such as keys and credentials out of it. Where you cannot open part of the code, the panel will expect a convincing explanation for that part.

13. Use and contribute to open standards, common components and patterns

Show which common components and patterns you used and what you gave back, for example a contribution to the GOV.UK Design System. GDS also asks teams to use open standards and to create APIs.

14. Operate a reliable service

Show how you monitor the service, who responds when it fails and how you deploy changes without significant downtime. GDS asks the service team to oversee quality assurance testing itself, and to monitor outcomes for users, bias included, as well as technical faults.

Check your own service against the list

Go through the 14 points as a team before you ask for an assessment date. For each point, write down what you can show today and what is missing, then put the gaps on your backlog.

Our guide to preparing for a service assessment covers who to bring and what happens on the day. Our one-day course, Agile Across the GDS Service Standard, works through all 14 points and finishes with a mock assessment. It costs £595+VAT per delegate.