Service Standard

Version 2.0

Version control table

The Service Standard helps teams to create and run efficient and effective public services. It is made up of 3 sections:

• Understanding User Needs
• Leading Agile Teams
• Choosing the Right Technology

What is a service?

A service is a facility the government provides to help the user achieve an outcome with minimal effort. The government is responsible for delivering a well-maintained service in a user-centred way.

A service is available both through online and offline channels. It goes beyond the interaction; it’s the content, technology, people, policies, materials, tools, and processes too. It helps the user achieve an outcome from beginning to end.

A. Understanding User Needs 

All services are built with the user in mind. The users’ needs must be understood to solve the problem they face with a simple, accessible and seamless journey through the service.

1. Understand users and their needs

Develop a deep understanding of the potential users. Perform targeted research to find out who they are, and how they think and feel. Learn what they are trying to achieve overall, and not just the part where they interact with the government.

Why it’s important

Understanding as much of the user’s circumstances as possible gives you the best chance of meeting their needs simply and cost-effectively.

User research is a team effort. It is a process the whole team needs to get involved in to ensure the service is focused on user needs. Focusing on the user and the challenges they’re trying to overcome 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 best outcome for the user might not be the one you originally had in mind. Testing ideas early on and often is essential in reducing costs and most importantly, maximising user satisfaction. A satisfied user is always something that the government aspires to.

What it means

Service teams should learn as much as possible about the difficulties users face when trying to achieve an outcome by:

• doing user research to understand what users need
• identifying and involving all users of the service (digital users, non-digital users, government, etc) in order to have a complete picture of the situation 
• taking an ethical approach towards research, and building the service
• building in time for regular user research sessions in the delivery cycle
• getting all team members involved with user research
• doing secondary research and analysis where needed
• building quick and easy prototypes to test their ideas
• using web analytics and other data that are available (for example, from government call centres or third-party services) to build up their understanding of the problem

2. Solve a whole problem for users

Work on creating a service that solves a whole problem for users. You should collaborate with other government departments and private sector stakeholders when needed.

Why it’s important

The service should join up the things a user needs to do. This involves identifying all the ways users interact with the government right now to achieve an outcome and have a plan to bring them together. Aim to create a seamless journey for the user which allows them to achieve what they need to, without having to understand how the government works. 

This doesn’t mean you have to develop large, complicated interactions with the government that aren’t intuitive to use or try to fix everything at once.

Start small, and deliver value to users through small changes that are delivered often.

What it means

Service teams should:

• consider alternatives to creating a service, such as guidance or making application programming interfaces (API) available
• identify any genuine limitations that affect the service (for example, procedures or legislation) and work to solve any problems those constraints are causing
• make sure services are scoped according to how users think
• be able to explain how the interaction with the government they’re working on will join up with other things, to create a journey that solves a whole problem for users 
• work across organisational lines where necessary to solve a whole problem for users (for example working with different organisations responsible for different policy areas or services)
• explore ways to suggest related services users would benefit from 

3. Provide a joined-up experience across all channels

Work towards creating a service that meets users’ needs across all channels, including online, phone, paper and face-to-face.

Why it’s important

The user should experience the same functionality and content quality on all points of access and devices, including mobile phones. Provide a consistent service through channels that best suit the user’s needs and capabilities. 

What it means

Service teams should be able to:

• choose the right channels that meet user needs
• edit or improve all steps of the service, no matter which channel
• work with frontline staff to get regular feedback on how changes to the online part of a service affect offline channels, and to find out how offline channels affect the online parts
• test all parts of the service: online parts and offline parts (like letters)
• use data and user research on the online part of the service to inform improvements to the offline channels, and the other way around
• increase the number of people using online versions of a service, but not by making it more difficult to find details of phone, paper or face-to-face channels
• allow users to switch channels mid-service and continue their journey, where possible
• identify any problems with internal processes, systems or structures and have an agreed procedure for resolving them

4. Make the service simple to use

Build a service that’s simple, natural, and easily understood by the user. Perform tests with different users to make sure it works for them, and it’s efficient and effective.

Why it’s important

Using a government service should be an intuitive and stress-free experience, with minimal steps. Good services should be so simple that users can succeed on their very first attempt without the need for assistance.

Making the service simple and user-friendly saves money and resources for the government and increases public trust. It should also reduce the need for users to seek assistance from the government. 

What it means

Service teams should:

• make sure the service helps users do the thing they need to do as simply as possible, so that they are successful in their first attempt, with minimal assistance
• test frequently for usability with actual and potential users, using appropriate research techniques, and make improvements when necessary 
• design the service to work online with a range of devices that reflects users’ behaviour
• use simple, everyday language that’s understandable and jargon-free 
• make it easy for a user to complete a task without requiring any knowledge about internal processes or how government works
• ensure that support is available
• use style consistently for related digital services so that the look and feel is the same
• minimise the number of times users have to provide the same information to the government (while respecting the user’s privacy)
• provide users with clear information throughout all steps of a process

5. Make sure everyone can use the service

Provide a service that everyone can use, including people with disabilities. People who don’t have access to the internet or lack the skills or confidence to use it should still be able to access services. 

Why it’s important

Government services should work for everyone who needs to use them without exception – so no one is left behind. 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.

What it means

Service teams should:

• meet the law on accessibility, including both online and offline parts (such as letters and SMS messages), as well as compliance with the European Standard for Digital Accessibility (EN 301 549) and the W3C ‘Web Content Accessibility Guidelines’ (WCAG) 2.1 AA
• identify and involve all potential groups of users during the design and development of the service
• carry out research with participants who represent the potential audience for the service, including people with accessibility needs
• make sure that people are not excluded from being able to use the service because they lack digital skills or internet access
• identify support needed to cover any gaps for those unable to use the online service, and provide the service through various channels

B. Leading Agile Teams

Agile methodology is a way of working by breaking the project up into several phases or stages. It involves constant collaboration with the users and other stakeholders, and the agile teams cycle through the process of planning, executing and evaluating to improve the service at every stage.

6. Have a multidisciplinary team

You will need to put together a multidisciplinary team that can make and operate the service at a sustainable pace. Work with the Deputy Ministry of Research, Innovation and Digital Policy to guide and support you with this. 

You will need to ensure that your team has the people and skills it needs to:

• continuously prioritise what to make, consider user needs and adapt accordingly
• work in a sustainable, agile way
• design and make the service
• research and analyse what has been made
• understand how the services are delivered across all the relevant channels and the integration with back-end systems
• understand and consider policy and operational goals while building the service

You may need to recruit or re-train members of existing teams to take on these skills or ensure these skills are built into the procurement of new services. 

Why it’s important

The best services are built by multidisciplinary teams that are empowered to make decisions about what to make and how to make it.

Your service team will be the people who best understand the needs of users and are able to recognise and adapt to changing requirements. Having a diverse mix of skills and expertise on the team helps to improve and speed up decision-making at the team level.

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. 

What it means

The service team should:

• be multidisciplinary and work together on a daily basis
• include people with expertise in building digital services, for example, designers, user researchers, and developers
• be provided with appropriate tools and working conditions to work together effectively
• be provided with access to the specialist expertise it needs (for example legal, policy or industry-specific analysis, from inside or outside the organisation)
• include people who can overcome legislative and regulatory boundaries that hinder the service 
• include people with expertise in how services are delivered across all relevant channels, and integration with back-end systems

If the team is working with contractors and outside suppliers, make sure the service can still be supported (for example, make sure support and further iteration is part of the contract or have a plan in place for when the contract ends).

The skills and roles you need on your team will depend on what needs to be delivered at each stage of building 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 the service.

7. Use Agile ways of working

You should take an ‘Agile’ approach by understanding what your users need and then using small, frequent iterations to build a service that meets those needs.

Agile approaches will allow you to rapidly test your assumptions and react to changing requirements compared to ‘Waterfall’ approaches where you try to anticipate all of your requirements upfront.

Why it’s important

Our users expect and deserve high-quality services. Taking an Agile approach helps to deliver services that are better tailored to users’ needs, as it focuses teams on quickly making and testing ways of helping users with their biggest problems.

Using Agile approaches is about changing the way we think about delivering services to prioritise user needs above all else and having ways of being able to discover and adapt to change.

By basing decisions on regularly collected feedback and evidence rather than assumptions, Agile approaches help you to reduce the risk of spending time and money building the wrong thing. You can deliver usable services more quickly, and then keep making them better.

What it means

Service teams should:

• use Agile ways of working and methods (such as Scrum or Kanban), learning and adapting as they go
• gather performance data and user research to understand if what they are making works for users
• identify constraints as they go, working to remove things that block delivery and reduce risks
• 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 
• explain how governance works with Agile, 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)
• ensure outside suppliers have an agile team in place when procuring services 

8. Iterate and improve frequently

Make sure you have the capacity, resources, and technical flexibility to iterate and improve the service frequently. Work with the Deputy Ministry of Research, Innovation and Digital Policy to guide and support you with this. 

You should improve your service over time, focusing on improvements that have the most value to the users and building on data, lessons learned, and previous research. 

Your service team should continuously reflect on their own practices and ways of working, to improve and change how they work together over time.

Why it’s important

Technology, policy, and user needs change over time. You’ll need to change and improve your services to ensure they’re still meeting users’ expectations, as well as policy goals, or to meet unexpected challenges. So rather than having to be replaced, the service stays relevant until it’s ready to be retired.

Even for more mature services, 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.

What it means

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.

C. Choosing the right technology

The right tools and technology need to be chosen to create a high-quality service in a cost-effective way. Those choices will impact the ability to create, iterate and operate the service in a sustainable way. The technology should be reliable, provide security, and communication functionality through Application Programming Interfaces (APIs), and use common components and patterns.

Evaluate what data the service will be collecting, storing, and providing.

Understand how data is classified, your organisation’s legal responsibilities, and the security risks associated with the service. Consult experts where you need to.

Why it’s important

Government services often hold personal and sensitive information about users. Government should see it as its duty to protect this information. Failing in that duty would undermine public trust in government services.

What it means

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
• audit the security of the service before it goes live
• ensure a regular security audit – at least once a year
• 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 the user’s privacy
• ensure that, where necessary, they comply with the relevant laws on data protection including EU data protection rules
• 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

10. Define what success looks like and publish performance data

Define a small number of goals or measurements for your service based on its purpose. Choose your measurements based on your understanding of your users’ needs.

Work out what success looks like for your service and identify measurements that will tell you what’s working and what can be improved, combined with user research.

Collect, use and publish performance data from all channels, online and offline.

Iterate and improve your measurements and data collection practices as you learn more about user needs.

Why it’s important

Defining what success looks like and identifying appropriate measurements means 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. When you make a change to the service, you’ll then 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. People can then make comparisons between different government services.

What it means

Service teams should:

• choose measurements while the service is being built, not afterwards
• identify measurements that indicate how well the service is solving the problem it’s meant to solve, and track performance data against them
• use performance data to make decisions about how to fix problems and improve the service

11. Choose the right tools and technology

Choose tools and technology that let you create a high-quality service in a cost-effective way. Minimise the cost of changing direction in the future.

Why it’s important

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.

What it means

When considering technical architecture, choice of programming languages, development tools, and other technology choices, service teams should:

• use the 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, for example: listing the principles they used to make technology choices
• understand the 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.
• prefer tools that have long-term support, good documentation, and an active development community so that problems are easier to diagnose and solve, and help is available when required.
• prefer tools that are widely recognised in the industry. This will increase the ease with which you can hire specialists to administer, improve or otherwise manage them
• consider services that can be run on containerisation platforms. Containerised applications can be run on a number of different types of infrastructure and do not create lock-in with any one supplier

Services should be built to expose their data and functionality through APIs, including data and functionality that may be useful to other departments, or other parts of your own organisation in the future. This work must still conform to relevant data protection, security, and intellectual property guidelines.  

Why it’s important

Parts of your service may be relevant to other services in your organisation, or across the government. For example; the part of your service that looks up a user’s details in your database from their ID.

You can Instead expose this functionality via an API and use it in multiple services/ integrations, reducing duplication across the organisation and allowing for more efficient use of resources.

What it means

You should consider what the core service functionality of your application is and how it can be exposed via an API.

Service teams should:

• follow common API patterns such as REST
• Where possible business logic should be included and maintained at the API level, the best practice is to avoid such logic in application frontends
• provide suitable error messages
• test their APIs with developers the same way they test their software
• make sure security standards are enforced on APIs

Note

The team currently responsible for coordinating data integration across the Government of the Republic of Cyprus is located in the Department of Information Technology Services (DITS) and can be reached at CyLoginSupport@dits.dmrid.gov.cy

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

You should find out if there is an appropriate open-source library, recommending DSF’s Open Source Library, or a maintained open standard that you can use in the development of your services.

If you develop your own patterns or components, document them and share them publicly so others can use them.

Why it’s important

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 under an appropriate open-source licence so that others can benefit from your work. This avoids duplication of work and reduces costs for the government as a whole.

Open standards help services work consistently – so you’ll spend less time trying to make systems talk to each other. They also help in not getting locked into a particular supplier or technology – so when things change, you can more easily change your approach.

What it means

Service teams should:

• grant the ownership of the intellectual property of new code or standards that are created as part of the service to the Government of Cyprus, and make it available for reuse under an open licence
• consider whether they can publish their code in the open to help others
• use open standards or recommended standards 
• use standard government technology components (for example use CY Login if authentication is required by the service – refer to the Connecting Digital Services)
• use common components and patterns, and share details of any new components or patterns they create or adapt

14. Operate a reliable service

Minimise service downtime and have a recovery plan to deal with service outages when they do happen.

Why it’s important

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.

What it means

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 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 that shows the status of the service and can alert based on outages
• Prepare and document a proportionate, sustainable plan to respond to problems identified by monitoring and actively working towards fixing any organisational or contractual issues which make it difficult to maximise availability or quality (for example, by agreeing on a common set of languages, tools, and ways of working for technical staff – either informally or formally)

15.  Ensure your service is ‘DSF ready’

Ensure your hosting arrangements and service deployment are ‘DSF Ready’.

Why it’s important

To allow the service to be hosted on the DSF’s Cloud Infrastructure and comply with the DMRID ‘cloud first’ Digital Policy.

What it means

Service teams should:

• follow the ‘Service Delivery Team Onboarding and Service Delivery Guide’ to collaborate, develop and deploy new services on the DSF infrastructure
• follow the 12-factor methodology in order to support portability and resilience: https://12factor.net/
• develop containerised services to be hosted on the DSF Infrastructure and for maximum portability