Repository for versions of GDS Standards and guidance translated and/ or internationalised
View the Project on GitHub alphagov/gdmp-translated-standards
The Service Standard helps teams to create and run great public services.
Develop a deep understanding of your users and the problem you’re trying to solve for them.
Look at the full context to understand what the user is trying to achieve, not just the part where they have to interact with the government.
Understanding as much of the context as possible gives you the best chance of meeting users’ needs in a simple and cost effective way.
Focusing on the user and the problem they’re trying to solve often means that you learn unexpected things about their needs. You will miss this important information if you only focus on a certain solution.
The real problem might not be the one you originally thought needed solving. Testing your ideas early and often reduces the risk of building the wrong thing.
Service teams should learn as much as possible about the problem users need them to solve by:
doing user research to understand what users need
where needed, doing secondary research and analysis
building quick and easy prototypes to test their ideas
using web analytics and other data that’s available (for example, from government call centres or third party services) to build up their understanding of the problem
Work on creating a service that solves one whole problem for users. You should collaborate with other government departments when needed.
Fragmented services are difficult to use because users have to do the hard work to make sure they’re doing things right. For example, choosing the right form to fill in out of several very similar options.
That doesn’t mean building big, complicated transactions that aren’t intuitive to use because
they try to do too much. And it doesn’t mean trying to fix everything at once.
Start small, and deliver value to users through small changes, delivered often.
Just make sure any changes are part of a plan to bring related content and transactions together into a journey that makes sense to users, no matter which organisation they ‘belong’ to. Users shouldn’t have to understand how government works in order to use public services.
Service teams should:
consider alternatives to creating a service, for example publishing website content, running a campaign, partnering with a non-government organisation or making data or an API available to third parties
understand any genuine limitations that affect the service (for example, legislation) and work with policy colleagues to solve any problems those constraints are causing
make sure services are scoped according to how users think, not too narrow or too broad
be able to explain how the transaction they’re working on will join up with other things into a journey that solves a whole problem for users ( case study: come to the UK to study)
take responsibility for agreeing how this user journey will work with organisations responsible for different parts of it -
work in the open so that people outside the organisation know what they’re doing, increasing the potential for collaboration and reducing duplication of effort (for example by publishing business cases, mission statements, research findings, user experience maps, maps of existing services and product roadmaps showing plans to develop new features)
work towards minimising the number of times users are to provide the same information to government (while respecting users’ privacy)
work across organisational lines where that’s necessary to solve a whole problem for users
Work towards creating a service that meets users’ needs across all channels, including online, phone, paper and face to face.
Bringing different channels together means you can design an experience that makes sense to the user, however they use the service. Users shouldn’t be excluded or have an worse
experience because they lack access to technology or the skills to use it.
People working on the service are empowered to fix problems in whatever channel users’ decide to use. They can spend less time dealing with ‘failure demand’*, and more time with users who need their help.
‘Failure demand’ is defined as demand caused by a failure to do something or do something right for the user. You should try to avoid this as it means users come back, making further demands, unnecessarily consuming your organisation’s resources because the service they receive is ineffective.
Service teams should be able to show that:
the service team is empowered to find the best way of solving the problem
front line operations staff and policy people are invited to attend user research and to contribute to prioritisation decisions
designers and user researchers are working with front line operations staff
they are testing and can make changes to users’ experience of both online and offline channels (for example, call centre scripts and letters)
data and user research on the online part of the service is used to improve offline channels, and the other way around
front line operations staff responsible for answering users’ questions know how the online service works, and there’s a process for keeping them up to date with changes
they’re working with colleagues in operations to understand how changes to the online part of the service will affect offline channels, and equally how those offline channels will affect the online part of the service.
plans to increase digital take up don’t involve making it more difficult to find details of phone, paper or face to face channels
Service teams should be able to identify any problems with internal processes, systems or structures that make it more difficult than it needs to be to design and operate a joined up service.
And show that there’s a plan to fix them. For example, by having an agreed procedure for resolving issues with the online service that are causing problems for the offline channels. Or the other way around.
Build a service that’s simple, natural and easy to understand for the user. And test it with users to make sure it works for them.
People expect services to just work, and government services should be no different.
It costs government time and money to deal with mistakes that happen when services don’t work well. And making things more complicated than they need to be reduces trust in government.
Service teams should:
make sure the service helps the user to do the thing they need to do as simply as possible, so that people succeed first time, with the minimum of help
test for usability frequently with actual and potential users, using appropriate research techniques
test all the parts of the service that the user interacts with, for example online parts and offline parts (like letters)
design the service to work online with a range of devices that reflects users’ behaviour
Services should also provide users with a consistent experience from start to finish.
Provide a service that everyone can use, including people with disabilities. And people who don’t have access to the internet or lack the skills or confidence to use it. This ensures services are efficient and cost less to administer.
Government services should work for everyone who needs to use them. Public sector organisations have a duty to consider everyone’s needs when they’re designing and delivering services.
Inclusive, accessible services are better for everyone. For example, using simple words helps people who are in a hurry as well as people who have a learning disability.
Service teams should:
meet accessibility standards, including both online and offline parts
avoid excluding any groups within the audience they’re intended to serve
carry out research with participants who represent the potential audience for the service, including people with accessibility needs
make sure that people aren’t excluded from being able to use the service because they lack digital skills or internet access, providing appropriate assisted digital support to cover any gaps
Put in place a multidisciplinary team that can create and operate the service in a sustainable way.
You’ll need a team made up of people with a diverse mix of skills and expertise.
It’s important that people who are involved in decision making are part of the team, so they’re accountable to the team - and the team as a whole can respond quickly to what they learn about users and their needs.
Services should:
be built by a multidisciplinary team that’s appropriate to what they need to achieve during the relevant phase of the service’s development, and co-located as far as possible
include people on the team with expertise in how services are delivered across all the relevant offline channels, and the back end systems the service will need to integrate with
provide the team with access to the specialist expertise it needs (for example legal, policy or industry-specific analysis, from inside or outside the organisation)
if the team is working with contractors and outside suppliers, make sure it’s on a sustainable basis
Your team will probably be shaped by what it has to deliver at each part of developing the service. So you may need more help from user researchers and service designers at the beginning and more developers and people with technical skills as you start to build your service.
But start with the assumption that you’ll need a broad range of roles. A team with diversity of perspectives is more likely to come up with the best solution.
Create the service using agile, iterative user-centred methods.
Using agile methods means getting your service in front of real users as soon as possible. Then observing and generating data on how they use it, and iterating the service based on what you’ve learned.
Because you’re not specifying everything up front before you’ve developed an understanding of what users need, agile methods reduce the risk of delivering the wrong thing.
Service teams should:
use agile ways of working - inspecting, learning and adapting as they go
have governance arrangements that are consistent with the agile governance principles and make sure that the right people know what’s happening with the service, at the right level of detail (including, for example, the minister or chief executive)
where appropriate and proportionate, test the service with the minister or relevant senior stakeholder
Make sure you have the capacity, resources and technical flexibility to iterate and improve the service frequently.
Work with your organisation to make sure that you’re able to focus on improvements that have the most value.
Services are never ‘finished’. Using agile methods means getting real people using your service as early as possible. Then making improvements throughout the lifetime of the service.
Making improvements means more than doing basic maintenance like fixing bugs in code, deploying security patches and keeping call centre scripts up to date. If that’s all you do, you’ll be fixing symptoms rather than underlying problems. And over time, the service will stop meeting user needs.
Continuous improvement means you can respond to changes in user needs, technology or government policy throughout the lifetime of the service. So rather than having to be replaced, the service stays relevant until it’s ready to be retired.
Iteration isn’t just for the early stages of a service’s development.
Running a live service doesn’t have to mean a full team working on the service 100% of the time during the live phase. But it does mean being able to make substantial improvements throughout the lifetime of the service.
Evaluate what data the service will be collecting, storing and providing.
Understand how your government classifies data, the organisation’s legal responsibilities, and security risks associated with the service. Consult experts where you need to.
Government services often hold personal and sensitive information about users. Government should see it as their duty protect this information. Failing in that duty would undermine public trust in government services.
Service teams should:
actively identify security and privacy threats to the service, and have a robust, proportionate approach to securing information and managing fraud risks
have a plan and budget that lets them manage security during the life of the service (for example by responding to new threats, putting controls in place and applying security patches to software)
collect and process users’ personal information in a way that’s secure and respects their privacy
use an approach to identity assurance and authentication that balances the risks in a proportionate way (for services that need identity assurance or authentication)
work with business and information risk teams (for example, senior information risk owners, information asset owners and data guardians) to make sure the service meets security requirements and regulations without putting delivery at risk
carry out appropriate vulnerability and penetration testing
Work out what success looks like for your service and identify measurements which will tell you what’s working and what can be improved, combined with user research.
Collect and use performance data from all channels, online and offline.
Iterate and improve your measurements and data collection practices as you learn more about user needs.
Defining what good looks like and identifying appropriate measurements means that you’ll know whether the service is solving the problem it’s meant to solve.
Collecting the right performance data means you’ll be alerted to potential problems with your service. And when you make a change to the service, you’ll be able to tell whether it had the effect you expected.
Publishing performance data means that you’re being transparent about the success of services funded by public money. And people can make comparisons between different government services.
Service teams should:
identify measurements which will indicate how well the service is solving the problem it’s meant to solve, and track performance against them
use performance data to make decisions about how to fix problems and improve the service
Choose tools and technology that let you create a high quality service in a cost effective way. Minimise the cost of changing direction in future.
When you make a decision about technology, you’re making a significant investment. The choices you make will have a huge impact on your ability to create, iterate and operate the service in a sustainable way.
When considering technical architecture, choice of programming languages, development tools and other technology choices, service teams should:
use appropriate tools and technologies to create and operate a good service in a cost effective way - for example, by automating things where possible
be able to show that they’ve made good decisions about what technology to build and what to buy
understand total cost of ownership of the technology and preserve the ability to make different choices in future - for example, reducing the chances of getting locked into contracts for specific tools and suppliers by using open standards
have an effective approach to managing any legacy technology the service integrates with or depends on
Make all new source code open and reusable, and publish it under appropriate licences.
Or if this isn’t possible, provide a convincing explanation of why this can’t be done for specific subsets of the source code.
Public services are built with public money. So unless there’s a good reason not to do so, the code they’re based on should be made available for people to reuse and build on.
Open source code can be reused by developers working in government, avoiding duplication of work and reducing costs for government as a whole. And publishing source code under an open licence means that you’re less likely to get locked in to working with a single supplier.
Service teams should:
write code in the open from the start, and publish it in an open repository - minus any sensitive information, like secret keys and credentials
keep ownership of the intellectual property of new source code that’s created as part of the service, and make it available for reuse under an open licence
There are a few cases when you should not publish code in the open. For example, code that relates to a sensitive government policy that hasn’t been announced yet.
Build on open standards and common components and patterns from inside and outside government.
If you develop your own patterns or components, share them publicly so others can use them.
Using common components and patterns means you don’t have to solve problems that have already been solved. By using a component or pattern that’s already been extensively tested, you can provide users with a good experience in a cost effective way. If you develop your own components or patterns, share them so that others can benefit from your work.
Open standards help services to work consistently - so you’ll spend less time trying to make systems “talk” to each other. And they help you to avoid getting locked into a particular supplier or technology - so when things change, you can change your approach.
Service teams should:
use open standards, and propose a new open standard if there isn’t one that already meets their needs
use standard government technology components where possible, (example GOV.UK Common Components)
maximise flexibility in their use of technology, for example by using and creating application programming interfaces (APIs) and, where possible, authoritative sources of data like registers
use common components and patterns, and share details of any new components or patterns they create or adapt
When services create data that’s potentially useful to others inside or outside government, they should publish them in an open, machine readable format, under an Open Government Licence
This doesn’t apply to data that contains personally identifiable information, information that’s sensitive (for example because it could affect national security), or where publishing the data would infringe the intellectual property rights of someone outside government.
Minimise service downtime and have a plan to deal with it when it does happen.
Users expect to be able to use online services 24 hours a day, 365 days a year.
Many users have limited choice over how and when they access government services. For example, they may be a carer who only has time to apply for benefits in the early hours of the morning. If a service is unavailable or slow, it can mean those users aren’t able to get the help they need.
Service teams should:
maximise uptime and speed of response for the online part of the service
be able to deploy software changes regularly, without significant downtime (for example, by minimising the effort involved in creating new environments and populating pre-production environments with test data)
carry out quality assurance testing regularly
test the service in an environment that’s as similar to live as possible
have appropriate monitoring in place, together with a proportionate, sustainable plan to respond to problems identified by monitoring (given the impact of problems on users and on government)
actively work towards fixing any organisational or contractual issues which make it difficult to maximise availability (for example, by agreeing a common set of languages, tools, and ways of working for technical staff - either informally, or through something more formal like the GDS way)