In a previous blog post, we shared our ambition for every form on GOV.UK to be accessible, easy to use and quick to process.

To support government to collectively work towards that vision, our team initially compared some of the different forms technologies currently in use. While not a fix-all for every form or every team, online HTML forms emerged as more accessible, easier to use and quicker to process, compared to document-based forms. We hope more government teams using online HTML forms will make it easier for people to use niche, but important government services.

How we compared different forms technologies

We’ve looked at some of the main technologies used in different forms to collect information from members of the public and businesses. On GOV.UK, most services use document-based forms, such as PDFs, Word documents or OpenDocuments. Higher volume services also use online HTML forms.

We did not evaluate forms sent in by post. The volumes of posted forms equate roughly with the 10% of the UK adult population who don’t use the internet. This suggests there is a need to support posted forms rather than replace them entirely, so we didn’t think it was fair to compare posted forms with internet-based technologies, as this group would be unlikely to use them.

While there were some differences between file formats and how technologies are used, we initially only compared two groups: document-based forms sent over email and online HTML forms.

We wanted to see how these two technologies could help us achieve government’s collective vision of every form on GOV.UK being accessible, easy to use and quick to process. Let’s see how they fared against those three criteria.

Accessibility

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 use the WCAG 2.1 AA standard. While meeting the standard is just a starting point for improving accessibility, it’s a useful bar for assessing different technologies.

Document-based forms can currently only meet the WCAG 2.0 AA standard, not WCAG 2.1 AA. For example, documents designed to be edited don’t reflow when zoomed in, instead users have to scroll horizontally and vertically which makes things much harder for some users.

Even creating document-based forms that meet the lower WCAG 2.0 AA standard requires specialist accessibility skills. While we haven’t conducted a comprehensive audit, we have found very few examples of document-based forms on GOV.UK that meet the WCAG 2.0 AA standard.

Online HTML forms can meet the higher WCAG 2.1 AA standard, but creating them usually requires a digital team with specialist digital skills. There are many examples of these types of forms on GOV.UK. While there are platforms that use templates to make it easier to create online HTML forms that meet the standard without specialist skills, they are relatively expensive, require a lot of training or lack necessary features.

We conclude that online HTML forms are better than document-based forms for meeting the WCAG 2.1 AA standard, but at the moment it can be too difficult or expensive to create them.

Ease of use

Unlike accessibility, measuring ease of use is less standardised. We considered the main factors that would affect someone’s ability to successfully complete a form.

Document-based forms have a few benefits that online HTML forms don’t always have. For example, they can be filled out in whatever order the user prefers and are easily filled out by more than one person. However, they can be difficult to use on all device types, particularly on mobile devices, which make up the majority of users on GOV.UK. We heard from many services that people struggle to fill them in using specialist PDF editors or word processors. Many users resort to printing forms out, filling them in with pen, then scanning or taking photos to attach to an email. For people that don’t have access to a printer, this isn’t an option. Some users just give up.

With the right platform and templates, we think most of the benefits of document-based forms can be mirrored in online HTML forms. In addition, online HTML forms are much easier to use on all device types, particularly on mobile devices. Being able to fill in a form in a web browser without downloading and editing a form means people can more easily access government services on their phone on the bus home.

Processing time

The time it takes a civil servant to process a form affects how long members of the public and businesses have to wait to get what they need from government.

Drawing on our team’s own experiences of working on different government services, we estimated the time it could take to process document-based forms received over email compared to online HTML forms. We estimated timings based on the steps involved in processing information collected using forms and used them to help our team prioritise areas to explore. Actual processing times will vary from team to team, and we did not ask other government service teams to verify our estimates at this stage.

The first scenario, ‘emailed document-based forms’, assumes the information is sent to the processing team in a document-based form attached to an email, with supporting evidence in other attachments. It assumes the document-based forms are a mix of scans, photographs and digitally-edited documents, with around half the information unable to be copied and pasted.

The second scenario, ‘online HTML forms’, assumes the information is sent by an online forms platform to the processing team in the body of an email, with supporting evidence in attachments.

Our initial estimates show that online HTML forms could be twice as fast to process compared to document-based forms sent over email. Most of the potential time savings come from using validation to check all of the form information is there before someone submits it. Form validation could significantly reduce the amount of time civil servants spend contacting people who didn’t submit the right information.

The rest of the potential savings come from collecting the information in ways that are easier to process, such as faster copying and pasting. In the long term, we hope to be able to make this even more efficient by feeding information directly into case management systems.

Other considerations

Having done an initial evaluation of accessibility, ease of use and processing times, it seems like there are big benefits of using online HTML forms, especially when there are currently thousands of forms only available as documents. However, we’re also considering some other factors, not least matters of digital inclusion for example, ensuring document-based forms remain available for people that don’t use the internet.

In addition, we estimate that between 20 and 35% of document-based forms on GOV.UK have complex and less common question or answer formats. These formats probably wouldn’t be available in a typical form-building platform, and there might be some that are too complex to use without a digital team. Others might be so specific to one particular service that it would not make sense to have in a common platform.

Teams could recreate these features in online HTML forms using a developer to write some bespoke code. However, if they’re a lower volume service and don’t have a developer, they might not be able to use online HTML forms. As a result, we think for some lower volume services, the best way to improve forms may still be to get help from specialists to make document-based forms more accessible.

Help us test easier ways for civil servants to start using online HTML forms

To bring these benefits to members of the public and businesses, we want to make it as easy as possible for more government teams to start using online HTML forms alongside document-based forms.

To help us achieve this, we’re now looking for civil servants to be the first to test out a new form-building platform we’re developing. At the moment, we’re looking for civil servants outside the digital, data and technology profession that currently create or edit document-based forms.

This month’s episode of the Government Digital Service (GDS) Podcast focuses on maps. Whether it’s to convey important data, or simply to help users navigate from point A to point B, maps feature prominently in public services.

The best way to approach using maps in digital services is something we’re asked about a lot. So in this episode, we decided to explore some of the challenges services currently face when it comes to things like designing and prototyping maps at speed. We also address the question on everyone’s lips: just how do you make maps accessible?

Tune in to hear why Head of Design at the Department for Environment, Food and Rural Affairs’ (Defra), Cathy Dutton, and Imran Hussain, Community Designer for the GOV.UK Design System, have joined forces on a community-led approach to making maps more accessible, consistent and user-friendly.

We explain how you can get involved in pooling expertise and good practice into a powerful central resource to benefit public sector teams at 17 minutes 30.

Subscribe to our podcast

You can subscribe to the GDS Podcast on Spotify, Apple Podcasts and all other major podcast platforms. You can read a transcript of the podcast on Podbean.

Take our 2 minute survey

Do you enjoy the GDS Podcast? Help us to make it even better by completing our short, anonymous survey.

What’s happening now

Right now, people have to register and share the same information, like their name, over and over again to be able to use different government services. That’s why we’ve made it our mission to build a simple, joined-up and personalised experience of government for everyone. Delivering a single sign-on and identity checking system will help make our One Login for Government vision a reality. 

Building on our blog post in October I wanted to provide further detail on the digital identity team’s progress so far and look ahead to our priorities over the next 3 years. 

User research

Over the last 7 months we have spoken to more than 720 end users and learned many things.

Significantly, and perhaps surprisingly, user research has found 61% of participants  responded positively when asked about sharing their information with government and are broadly comfortable with departments sharing that data because they think we already do. 

Interestingly, many people assume they already have an online ‘government’ account that holds data on them and that services are joined-up. 

What shines through in the research is a need for users to have visibility and control of the information that the government holds on them and how it is shared.

Our research has also shown that many people see the value of a reusable proof of identity to save them time when engaging with government services in the future. So, this will be a key aspect of our service and we’re working through the details of how it should work. 

Barriers

There are currently many barriers that prevent users from being able to prove their identity online, including complicated or incomplete credit histories, poor internet access, low digital confidence and a wariness of sharing personal information online.

Inclusion and accessibility are the thematic core of all our work and we’re tackling the hard stuff now to make sure this works for everyone in the future. 

In particular, we’re building on the work done by DWP who design their services to work for users who experience multiple, overlapping barriers to completing things online. 

Speaking to government service teams is key to the success of our product, as it needs to meet their needs and expectations too. So far we have completed more than 150 research and engagement sessions with teams across government and will continue to speak to, learn from and partner with teams in the months ahead. 

What we’ve done

Our most significant recent milestone so far has been getting GOV.UK accounts live with the authentication component. This is a real achievement, but there’s a lot more to deliver. 

Users’ expectations of service delivery are shifting. Around 70% of overall traffic to GOV.UK is now via mobile and citizens are increasingly looking for faster, simpler ways to get stuff done. 

To deliver that, we want to provide a superhighway for users who can and want to use their mobile to apply for government services, so we are building an identity checking app. 

This will give smartphone users who have a photo ID, like passports and driving licences, the choice to prove their identity to a high level in around 10 minutes. It will do this by making use of Near Field Communication (NFC) readers and cameras built-in to modern smartphones. 

We will be working with a partner to deliver the app and to accelerate access to services for people for whom this ‘superhighway route’ is the right choice.

Use of the app will be optional; it will be just one of the ways people will be able to prove their identity based on their preferences and documents available. 

That’s just part of our work to ensure no-one is left behind. We are also looking at the alternative journeys we need to provide to support inclusion and we are working through how online and offline channels need to come together to make sure everyone can use our system. 

Next steps

Our next step is to create the first user journey combining the authentication and identity components by April 2022, and we are delighted that the Disclosure and Barring Service (DBS) is partnering with us to make this happen.

User feedback is a key part of our delivery plan. I’m determined to get stuff out there that we can really learn from. This means that by April next year users will be able to request a basic DBS check through their GOV.UK account by entering their UK passport information and answering some questions that only they should know the answer to in order to prove their identity. 

Dealing with personal data like passport information means we need to make certain our infrastructure meets the highest standards of security and resilience. We are working in partnership with the National Cyber Security Centre, investing in our own security architecture capability and drawing on the expertise of the Cabinet Office’s Cyber Security team.

Getting the first services and users using GOV.UK Sign In is essential, but to really have met our vision of One Login for Government we need to quickly go from one or two to 10s and then 100s. So we are working with other departments, directorates, agencies and individual services to build a clear, joined up and shared roadmap. It will enable services to understand when their required functionality will be available and give clear milestones and timelines for migration.

Expanding the scope of the system

Over time, through their GOV.UK account, our system will enable users to sign in to all government services and share information once to prove their identity. It will replace more than 190 different ways people can currently set up accounts to access service on GOV.UK and give citizens one fast, simple and secure route. We’ll be providing users with greater control over what personal data they choose to share and how that data will be used. It will also reduce unnecessary duplication of effort and save taxpayer’s money by ending the need for each department to find its own solution to authentication and identity assurance.

The potential scope of the system doesn’t stop there. We will be continuing to learn from Local Authorities, gaining an understanding of their needs to make sure our systems can work together in the future.

Because of the user research we’ve carried out and the insight we’ve gained, we’re working with our partners across government to update legislation to allow departments and services to share data whilst keeping users data safe and reducing the risk of fraud. This means that, in time, government services should be able to meet the expectations users already have of them. 

We frequently report to and are held accountable by a cross-government group of ministers, and we’ll continue to develop our system in a spirit of openness, explaining things like our research findings as we did in October.

Over time we will add more features to give users more ways to prove their identity, as we tackle areas like delegated access, broader inclusion, and the option to save identity checks to reuse with other services. Right now we’re focussed on a near term set of things we need to have as core foundational blocks that will enable the next financial year to be a big digital delivery year for us. I can’t wait to cross the line at a canter (perhaps even a gallop) and get our products into the hands of real users. Exciting times!

Related posts 

How will the single sign-on and GOV.UK account work together?

You might think, given we’re celebrating our 10th anniversary, we’re going to tell you how much things have changed. In fact, we want to do the opposite because the purpose that underpins all of our work - a relentless focus on user needs - is exactly the same.

The job of making it easier for people to interact with government is something that will never be finished. We need to keep finding and building the things that will make it easy for people to get what they need from government, and then get on with their lives.

Thanks to secure funding, a clear strategy and mature, talented teams, we’re confident that that's what we’ll do. And it’s why we’re marking this anniversary with as much excitement for the work ahead, as we are with pride for what we’ve achieved so far. 

With that in mind, we asked some of our people to share what excites them about coming to work to tackle some of the most complex, but rewarding, challenges in government. Because whatever the next decade has in store, we’re certain our people will be at the heart of it. 

On that note, we’ll soon be advertising exciting new career opportunities across the UK including our hubs in Manchester, Bristol and London (with hybrid working arrangements too).  So if, like Daisy, Kelvin and our other colleagues, you're inspired by the idea of making it quicker and easier for every citizen to get what they need from government - why not join us for our next chapter?

In 10 seconds or less, what excites you most about GDS's next chapter?

Achieving simpler, personalised and more joined-up digital government services - Tom Read, Chief Executive Officer

Read our strategy for 2021-2024.

Making it easier for users to find what they need on GOV.UK - Kelvin Gan, Senior Developer

Find out more about our work to improve the navigation on GOV.UK, and what’s coming next.

Personalising government services with enriched metadata - Felix Reilly, Data Scientist

Check out mission 2 of our strategy to learn more about this.

Unpicking government complexity so users don’t have to - Daisy Wain, Lead Performance Analyst

This animation explains more about our vision for joined-up, proactive and personalised services.

Unlocking the benefits of One Login for Government - Natalie Jones, Director for Digital Identity

Explore the progress we’ve made so far with One Login for Government, and our plans for the next 3 years.

Continuing to use research to enable better, user-centred decisions - Paloma Jain, Senior User Researcher

Find out what life as a user researcher is like at GDS.

Offering opportunities for top tech talent outside of London - Stacey Till, Recruitment Business Partner

Find out more about our open roles.

Putting down roots in the north-west and south-west - Paul Schagen, Locations Programme Lead 

Join us

Played a part in the Government Digital Service’s first decade? Share your highlights, memories or shout out a colleague using #GDSis10 on social media.

Keen to play a part in our next chapter? Find out more about our open roles and forthcoming career opportunities.

We’re launching a new way for civil and public servants to help us iterate the Government Digital Service’s digital products and services.

The Government Digital Service (GDS) builds platforms, products and services that help create a simple, joined-up and personalised experience of government to everyone.

Our Government as a Platform (GaaP) products make it easy for civil and public service organisations to design and host services, send messages and take payments. These include:

• GOV.UK PaaS, a cloud hosting solution
• GOV.UK Pay, a transactional payment service that enables services to take payments by card online
• GOV.UK Notify, a notifications platform that can send email, SMS and postal letters for your service
• GOV.UK Design System, a framework for creating front-end applications that will live on GOV.UK

The list of these common tools for digital services is growing and we want your help to make them great.

Why create a research panel?

Unlike when we want to learn about the needs of our public users, finding civil and public servants to take part in user research activities can be a challenge.

We can’t use traditional participant recruitment companies because we want to speak with our colleagues across the government during office hours. This means we can sometimes be reliant on our collective networks to find suitable participants, and that can lead to speaking to the same people a lot across our service teams.

Building out these social networks takes time and can happen at an individual level. We want to demonstrate our values on delivering diverse, and far reaching research by creating the right tools to help us overcome some of these challenges, and demonstrate how we make informed decisions that ensure digital in government is representative of the UK.

In the past, we know that participants in user research have felt disconnected from the outcome. They may have taken part in studies that related to topics close to their own work and don’t think their contribution made a difference.

We want to change that. Developing our research panel is the first step.

What happens in user research?

We know there are many things in a given day that require your time and that being part of user research activities might not be something you feel is a priority.

Members of our research panel will only be invited to take part in studies we think you will find interesting, and that we believe you will benefit from the outcome of. You don’t have to take part in anything, and we’ll make sure that if you have taken part in a study recently, we’ll wait some time before we contact you again.

Your opinions, thoughts, experiences and feelings matter. Anyone that has taken part in user research in the past will have had a direct impact and influenced the way that a service was created or continues to be improved.

Why should you join us?

Everyone is welcome to sign up and take part in user research. It does not matter which organisation you are part of, what your role is, your grade, or your experience. You can choose when to take part, and the types of activities you want to do.

You may not have been aware until reading this that we run user testing with civil and public servants, almost daily. Or that GDS creates these products and services to support your organisation and its digital services to overcome common challenges.

User research is a big part of making digital services and transformation human. It is a way for teams to hear what is happening for the people that we want to help.

By taking part, you will have been an important part of making government services great. Whether you completed a survey, worked with a researcher and designer to come up with ideas for a new way for people to confirm their identity, shared your experiences of delivering a service with a researcher, or tried out a new product with us. Your active participation is what makes GDS great.

Get involved

The panel will be open to civil servants and public servants across England, Scotland, Wales and Northern Ireland who want to take part in shaping how products and services are created by the Government Digital Service.

In this month’s episode of the Government Digital Service (GDS) Podcast, we’re going to be talking about careers in tech.

Digital, data and technology roles in government - like the ones here at at the Government Digital Service - come with stacks of flexibility and career opportunities, the chance to be creative, and to work on stuff that really matters.

But according to a Tech Nation Talent report, young people could be counting themselves out of a fulfilling career in technology because they’re worried about things like their skills background, where they came from or their lack of “network”.

We don’t want anyone to miss out on a great career in digital, data or technology. Because diverse teams that reflect the society they serve are more effective and better to be a part of (and those are the types of teams we’re trying to build).

So in this episode we asked senior developers Rosa Fox, Iqbal Ahmed and Kelvin Gan to reflect on the report’s findings and hopefully, put some of those myths and misconceptions to bed.

Jobs at the Government Digital Service

If what you’ve read or heard has given you the confidence to pursue a career in technology, why not start your tech career here at the Government Digital Service? And you can always comment on this post if you have any questions.

Subscribe to our podcast

You can subscribe to the GDS Podcast on Spotify, Apple Podcasts and all other major podcast platforms. You can read a transcript of the podcast on Podbean.

Do you enjoy the GDS Podcast? Help us to make it even better by completing our short, anonymous survey.

In this month's episode of the Government Digital Service (GDS) Podcast, we're talking about user needs.

We have 2 user researchers (URs) from GDS, Lauren Gorton and Charlotte Crossland, joining us on this episode to share the work they and their colleagues have been doing to understand more about what service teams and their users need from government's new single sign-on and digital identity solution, GOV.UK Sign-In.

'Start with user needs' is the first of the government's Design Principles, but what does that mean in practice? We wanted to learn more about the approaches URs take to understand what services and products need to deliver.

In this episode, Lauren and Charlotte detail how they've collaborated with teams from different government departments to build on existing insights and gather new learning that is being used to help shape GDS's One Login for Government programme.

Also in this episode, we discuss the impacts of COVID-19 on the research community and how the mindsets model was used in favour of personas to provide a more accurate view of the complexity of real life.

Work with us

Interested in becoming an early adopter of government’s new single sign-on and digital identity solution, GOV.UK - or perhaps you’d like to share your insights with our programme team? Register your interest on our product page.

Subscribe to our podcast

In this month’s episode of the Government Digital Service (GDS) Podcast, we explain why we updated the GOV.UK homepage and its menu bars, and how we went about it.

Sam Dub, Senior Product Manager, and Jenn Phillips-Bacher, Content Strategist, join us on this episode to share how their multi-disciplinary team has approached the never-ending user need to find information easily.

Continuing to work in the open

While there's been lots of developments on GOV.UK, the way most people browse it has remained largely unchanged after 2014, so it was worth investigating whether improvements would help users find what they came to the site for. We’ve previously shared what the discovery process unearthed, and what our next steps were going to be.

True to the design principle of working in the open to make things better, we also provided an update on how our ideas for the menu bars were progressing, including changes to our initial ideas. We followed this up with a similar piece tracking the changes to the GOV.UK homepage, highlighting the positive implications for accessibility.

Get involved

Subscribe to our podcast

You can subscribe to the GDS Podcast on Spotify, Apple Podcasts and all other major podcast platforms. You can read a transcript of the podcast on Podbean.

Do you enjoy the GDS Podcast? Help us to make it even better by completing our short, anonymous survey.

At the end of last year, the GOV.UK Design System passed the live assessment and officially became a live service.

Becoming a 'live' service shows that the GOV.UK Design System is a mature, sustainable product that our users can rely on, and it will continue to be iterated and improved upon. It hasn't dramatically changed what the team's been doing, though it reassures us that we're building our product in the right way. The live assessment has been a great opportunity to have a panel of experts in their fields, our peers, review our work as it's difficult to see the whole picture when you're working in the thick of it. It also gives us an opportunity to reflect on how we've developed the GOV.UK Design System.

Getting to live status represents the hard work the team, both past and present, have put into the GOV.UK Design System over the years. Both the team and the GOV.UK Design System have evolved and now is a good time for us to reflect on what we’ve achieved so far — and what else is still to come.

What we learned from the live assessment?

While we were quietly confident in the product we'd built, we were also apprehensive as we prepared for the live assessment.

As it turns out, we did not pass our live assessment the first time. The assessment panel told us we did not meet the criteria in the Service Standard to 'Define what success looks like and publish performance data'. In particular, they identified gaps in how our team measured website usage, used data to complement qualitative research and improved our knowledge of the wider potential market.

We were definitely disappointed, but the assessment was helpful in telling us what we needed to work on. Specifically, it confirmed the need for us to bring in a performance analyst onto the team to properly measure performance.

Fortunately, it was something we'd been looking at and had already brought one on to the team that same month. So we had what we needed to pass the assessment the next time around, it was mostly a matter of priority.

The assessment report helped confirm that we were on the right path to build up our performance analytics and make sure they fed into our decision making processes. We also received helpful recommendations from the panel to make further improvements to the GOV.UK Design System. We're already working on improving some of these issues.

What’s changed?

The GOV.UK Design System contains styles, components and patterns to help teams in government create user-centred digital services.

Since its launch in 2018, we've:

• added or improved 32 styles, components or patterns
• seen our code reused over 3,300 times
• seen the GOV.UK Frontend code package downloaded over 2,700,000 times
• started running co-design workshops with the community
• started running an annual conference - Design System Day

Everything in the Design System is thoroughly documented and tested, to make sure that it's as useful, usable and accessible as possible. In fact, pages on GOV.UK built with the Design System download about twice as fast as those that haven't, as they use about half as much code.

Many of the improvements to the Design System are made by our users, who regularly contribute work back into the Design System, so that everyone can benefit from it.

What have we learnt along the way?

The GOV.UK Design System can be a really powerful tool to help teams get services up and running fast. This was exemplified during the start of the pandemic where 52 services were built within weeks, not months, to respond to changing information and policy to help the government provide essential services to citizens. The "Get coronavirus support as an extremely vulnerable person" service was built from concept to live service in fewer than 4 days — it’s estimated this saved the government £10.4m.

Throughout the years, we've relied upon the community to support us by sharing their work and feedback with us. In turn, we've also recognised the need to nurture and maintain our community. Last year we hired a community manager specifically to help us do this. We've started hosting co-design workshops with the community to progress some tricky components and patterns that hadn't been contributed yet.

What’s next?

Our team has expanded over the past year or so, which means we can start doing some of the things we've always planned to do, but never had the capacity for. Here are some of our highlights for this coming year (or you can look at our roadmap for more details):

• improving the way JavaScript is configured
• adding even more components and patterns to the GOV.UK Design System
• removing barriers to contributions
• looking ahead at new accessibility standard changes with WCAG 2.2

Documentation-driven development, or docs-driven development, means documenting what you’re trying to build before you build it. You’d use docs-driven development to write down things like the endpoints, responses and requests before you even start coding.

Essentially, instead of documenting your code, you code your documentation. It’s a low-cost way of prototyping your code.

Teams use docs-driven development for a number of reasons:

• interrogating the build at an early stage
• minimising silos or isolated work
• maintaining consistency

Interrogating the build at an early stage

Docs-driven development is a cheap and fast way to interrogate your design without wholly committing to its build. It’s important to know the team is creating the right thing in the right way without investing significant money, time and resources upfront to build the service and its design.

Crucially, docs-driven development isn’t a ‘Big Design Up Front’ approach to set every design decision. Instead, docs-driven development interrogates the top-level blueprint of what the team expects to build. The team can then use the documentation to:

• check the design works as expected and there’s no obvious gaps or inconsistencies
• check they’re building the right thing in the right way
• easily undo and rework the features or requests which don’t work

All these benefits save time and money overall. On top of this, docs-driven development allows for increased collaboration for a wider team to be involved and bounce ideas off each other in the early stages of building a service.

Minimising silos or isolated work

Docs-driven development means the team doesn’t work on features in isolation, but instead can see the build and how it works as a whole. Documenting the service and its features means it’s more straightforward to experiment with different architectural approaches and use the documentation to check how all the features worked in connection with other features.

This replaces creating individual features without seeing how they interact with each other. Minimising silos improves the end-user experience and can help inform wider design choices at an early stage before the product is too developed.

Maintaining consistency

Maintaining team consistency can be hard, especially when work spans multiple teams. Documenting how a product or service works means you can use the documentation as the single source of truth. This improves consistency and means the code will always be up to date.

Realising docs-driven development potential

In March 2021, GDS's One Login for Government programme started developing the authentication component for its new product that will make it easier for users to sign in, prove their identity and access government services. This product is currently called GOV.UK Sign In.

The authentication component will sit alongside GOV.UK Sign In’s identity verification component, which has an initial release later this month. Authentication needed to pave the way and set up practices and workflows which identity could integrate with at a later stage.

The authentication team chose to use docs-driven development because:

• we started from a relatively blank piece of paper without legacy technology or documentation
• the team was in the early days of conceptualising the technology we were going to use to build the authentication component
• we had subject matter experts who had worked on authentication solutions before, for example NHS Login
• we had a technical writer dedicated to writing user-led technical documentation

Mapping the technical architecture and user needs

We started with using subject matter experts’ previous knowledge of authentication solutions to work out the architecture for how the technology would work, the type of requests, responses and endpoints we would use, and the technical flow.

The technical writer and subject matter expert mapped this flow to users’ tasks. This helped with checking we weren’t flooding users with unneeded information about how the service worked in the backend, just what they needed to do to get it working.

We took these tasks and created a task-based top-level hierarchy of pages, for example: ‘Generate a key pair’ or ‘Choose the level of authentication for your service’. Using this approach helped interrogate our information architecture before we got too deep in writing the documentation.

We shared the documentation plan and technical architecture for the service build with the wider team. This meant we all had an understanding of what the build would look like and could contribute to any iterations.

Writing and developing the authentication component

The technical writer began pair-writing the technical documentation with the subject matter expert, prioritising the pages based on:

• whether the team had made the dependent technical decisions yet
• how crucial the page was to the overall flow
• estimated length of page

Referring to the OpenID Connect technical specification and writing the technical documentation became the first step in holding conversations for what features the authentication component would support. The developers then used the documentation to help build the endpoints, requests and responses. The technical writer could work with user researchers to regularly test the technical documentation and iterate based on changing user needs and feedback.

Maintaining docs-driven development beyond launch

Docs-driven development worked well before launch when the landscape was open, but we needed to maintain this approach through to launch and beyond.

To do this, the team instilled a culture to update the documentation as standard when building a feature or fixing a bug.

Having a technical writer dedicated to maintaining docs-driven development lifted the documentation load off the developers. The technical writer and developers could work in tandem with the developers building, while the technical writer could focus on writing.

Writing or updating documentation and testing the documentation is a success criteria for our features. This has helped create a user-led and interrogated build, which helps improve the service quality overall.

What’s next?

The authentication team continues to blend feature development with writing technical documentation, and our technical documentation for GOV.UK Sign In is now live.

The team is now working on building the identity component. The identity component will use docs-driven development to help build their technology.

GOV.UK Sign In is currently inviting beta partners for authentication. You can find out more about our selection process and GOV.UK Sign In on our recent blog post.

In the last 3 years of helping governments across the globe we’ve seen how agile approaches can help organisations and teams who want to start delivering better public services.

One of the main things we’ve learned is that every digital transformation initiative is different. While there are common challenges governments around the world face, localised issues and priorities means that the way reforms are approached can differ significantly.

Frameworks and standards can achieve change, like in UK, but these can't necessarily be applied the same way in different countries. Instead, by understanding, testing and adapting different approaches in small, regular iterations, other governments can shape and contextualise good practice ways of working and delivery methods over time gradually and methodically.

The approach we are taking with our international partners is:

1. Show or explain something
2. Delivering or working on something together
3. Taking a step back so our partner organisation can lead something (with our support)

Our work with Cyprus takes this approach with a GDS multidisciplinary team and a mirror team in the Cypriot government. We have been able to support them in adapting and building their skill sets so they can deliver more user focused services.

We’ve learnt a lot over the last few years of working with countries and helping them adopt agile practices. Our experiences from our country work fall into 3 broad areas: leadership, building hard and soft skills, and creating a narrative that works.

It takes people to lead people

In the countries we work in, the focus has been on developing the technical digital skills to push forward the delivery of services - a necessity often borne of political and economic pressures. It is just as important to build soft skills in leaders - and teams - to support agile ways of working, like leading with direction, not dictats. It takes a real shift in mindsets across all levels, valuing collaboration over hierarchy and traditional structures. Our work focuses on dedicated coaching for leaders and teams to ensure that agile practices and behaviours are embedded and really understood in the organisations we work with.

For leaders the shift in mindset is not only behavioural but also the need to focus on outcomes over outputs, evidencing tangible progress and working out what delivers the most value for the organisation and its users will help build the case for agile and build capacity through delivery. This also means that leaders need to adjust their focus, set expectations and help manage financial or political pressures so that teams can focus on what’s important - meeting user needs.

A ‘Big Bang’ approach does not (generally) work

Many of the countries we work with are looking for rapid change to help them meet user needs, often due to tight budgets and lower levels of digital capability in government. Over the pandemic, we saw that in some areas, that the rush to provide digital services has led to the fast implementation of solutions that don’t actually meet what users need, resulting in the loss of time and money as they have to be re-done, and damaging citizens’ trust in government.

For organisations that are new to digital service delivery, it is crucial to introduce new skills and behaviours gradually to help mitigate risk. Part of this sometimes has to be done through managing demand for technical support from across government, so that the lead organisation can succeed in delivering value in a sustainable way, building in long-term sustainability and capability.

Introducing change more slowly also helps teams developing digital tools and services to better understand citizen needs and incorporate them from the outset, and taking time to understand different regulatory approaches and attitudes to things like privacy that may impact how and what we help teams deliver.

Tell stories and celebrate wins

Another element of transformation that tends to be sidelined by the need for digital delivery is a narrative that underpins the work. Talking about what’s being delivered, what it means for the organisation, and how it impacts the organisation, is essential to helping get the buy-in and support at an organisational level.

Storytelling can help change the conversation from requirements to a discussion of outcomes based on user needs - a critical element of change.

What does this mean for digital practitioners in the UK?

These key areas also offer reflections and lessons for digital leaders and digital delivery teams in government.

Based on our experience in-country, as organisations move towards adopting agile practices, teams should consider how agile is scaled to take into account the organisational culture to ensure long-term sustainability - particularly in contexts where other factors might be driving an organisation’s agenda.

For those working with other departments, finding the balance between making recommendations, and giving people structure to gain experience can be hard to achieve. Part of the approach should focus on testing out what gives the teams we work with (as well as our own) the safety and structure to try new things, a critical factor in agile adoption when there may be organisational or political pressures.

In our next blog post on our international work, we will share more about our work in helping governments on the digital transformation journey by developing standards and assurance - one of the core foundations for digital transformation.

Summer Diversity Internship Programme (SDIP) graduate Jake Rutherford spent some of his internship collaborating with the Government Digital Service’s (GDS) Data Products team. Jake went on to be offered a full time role as a data scientist at GDS and here, to celebrate Learning at Work Week, explains how the opportunity to learn whilst working was instrumental to his career.

The foundations 

I first became aware of the SDIP after one of my friends completed the programme. He often spoke of his joy working collaboratively with humble, entrepreneurial, and talented people to serve the public. This, of course, filled me with the desire to work alongside such people myself. Furthermore, I thought it’d be great to be involved in something that facilitates social mobility and stimulates diversity of thought in government, by creating opportunities for disadvantaged people.

My placement on the SDIP began in August 2021, in the Central Digital and Data Office’s DDaT (Digital, Data and Technology) Profession team. I landed on my feet here, surrounded by lovely people that wanted the best for me. As my time at university was spent studying data science, my workplace mentor and supportive line manager were keen on exposing me to opportunities to continue learning about data science at work. This led me to collaborate with the Data Products team in GDS, and the rest, as they say, is history! 

I was thrilled to be offered a full time role in Data Products at GDS in September 2021. After all my studying, this was my first proper job in the career I had wanted so much to pursue. I derived great lessons from the experience of joining the Civil Service and transitioning into Data Products:

• those who ask questions are a fool for a minute, those who do not are a fool for life
• being brave and humble enough to admit you don’t understand something and seek clarification is a superpower
• people will move heaven and earth to nurture your development if you ask them
• find a mentor and benefit from their wisdom, they can point your learning and development in the direction of your ambitions

These lessons are foundational to the ongoing pursuit of learning in the workplace.

The journey

I see Data Products as a group of people, aiming to use data science to improve the experiences people have when consuming government content and services. That may be via deploying public-facing technology, or by empowering other teams to do their best work through the internal tools we build. 

Naturally, I learnt a huge amount about data science being in a data science team. My technical data science skills blossomed, whilst my soft data science skills were nurtured, as I learnt more and more at work and heightened my awareness of the opportunities for data science. Some of my development highlights included: 

• presenting to 150+ people at a GOV.UK show and tell, and to smaller groups of end-users and stakeholders
• daily stand-up meetings, retrospectives, sprint-planning and team time taught me the value of agile, and showed me what team spirit looks like
• I developed an algorithm, which utilises network analysis to automatically determine which whole user journey a page belongs to and that exposed me to a whole new area of analysis
• training machine-learning models to automatically determine which named entities are in a page of GOV.UK, resulting in experimentation with super cool large language models like BERT and GPT-3

Before I came to GDS, it was difficult to gauge the standard of my data science capabilities. This was a source of self-doubt… hello, impostor syndrome! When I first joined Data Products, I thought I’d be in the midst of all-knowing polymath demigods of data science. However, being amongst experienced data scientists, observing what they know and heeding their feedback, I realise now that I am unashamedly good at what I do. 

What’s more, we’re all still learning. Nobody knows everything. There are no all-knowing data scientists. Every day, at work and in our personal lives, there are endless lessons to be learnt. Admitting you don’t know everything and committing to being a student for life is something to be proud of.

The future

If I could give advice to anyone considering the SDIP or working at GDS, it’d be wherever you are right now, take the initiative: find opportunities, be bold and challenge yourself. Don’t ever let your background diminish your self-confidence or self-worth, and instead let it be a strength that propels you to the top. Your life so far has been an education in itself. 

This can be leveraged as a source of wisdom, which will be seen as a great asset to GDS and the Civil Service. You will be treated as an equal and your team will invest in you. Your potential will be unleashed and you will learn immeasurably. GDS, and my team, have helped set me on a promising career path, one in which I am brimming with confidence. 

It’s been a privilege to work alongside the great minds at GDS, united under a shared vision. The work we do here is difficult, but I think we all thrive on that. It’s why we wanted to work in tech – it’s an ever-changing, fast-paced sector that’s building the future. Constant exposure to challenge and innovation at work creates this unscratchable itch to keep learning. So let your workplace be your university. Look out bravely upon the fog of mystery and let it be the greatest teacher you ever had.

Government Digital Service Advisory held an event with their commercial suppliers on 11 May at the Government Digital Service (GDS) offices in Manchester. The team at GDS Advisory used this opportunity to explore ways of improving processes and management tools. Working together with their suppliers, GDS Advisory successfully highlighted great ideas to strengthen its ability to provide expert services to clients at a high standard and support Digital Capability across government. 

What is GDS Advisory?

GDS Advisory currently supports digital transformation across government in two ways via:

• a pool of civil servants
• third party suppliers

Our pool of civil servants comprises experienced civil servants in a range of Digital, Data and Technology (DDaT) professions. As well as bringing DDaT expertise, team members act as a ‘critical friend’ in their deployments. They consistently receive excellent feedback, in particular from organisations still in the early stages of setting up their DDaT function.

Our third party supplier route provides urgent DDaT support for departments or arm’s length bodies who can help deliver outcomes where no civil servants are available and procurement is time prohibitive.  

GDS Advisory uses the Digital Outcomes and Specialists (DOS) framework to find suppliers with the capability and capacity to support government with urgent digital delivery whilst maintaining the digital standard. We procure single supplier contracts which are managed centrally by our GDS Advisory team.

What we did on the day

We gathered four commercial suppliers together (Nomensa, Madetech, LAInternational, Opencast) to have thoughtful discussions in order to make suggestions on how we can iterate our contract management processes to provide better outcomes and ensure we leave clients and departments with all the tools and knowledge to continue into their next phases of delivery.  

We began the day with a presentation from the Head of GDS Advisory, Nick Tait, who provided an overview of where GDS Advisory sits within Government Digital Service (GDS), along with a summary of our strategic goals for the future.

Following on from that, we then broke off into teams to review current contract management processes and tools such as the Triage form, Statement of Work (SOW) and Weekly Contract Review. In keeping with GDS tradition, we used post it notes to document ideas before regrouping, sharing ideas and experiences to iterate how we deliver across government. 

Feedback from the organisers

Dean Woolliscroft, Contracts Manager

"These sessions are crucial in helping GDS Advisory deliver at pace whilst ensuring governance and the Digital standard are adhered to.  This was the 1st event in the 3 years I have managed these and previous contracts that we could sit and speak with our suppliers in one room.  The session will help inform how we iterate our processes and management tools but also gave crucial insight into how we can help broaden the GDS Advisory offering to focus more on supporting Digital Capability across government."

Nick Tait, Head of GDS Advisory

"An excellent day with our GDS Advisory suppliers, all of whom contributed to its overall success. Working together to improve our triage and Statement of Work processes means that we co-create a shared understanding of our client's needs so that we can meet and exceed them."

Feedback from the suppliers 

Nomensa

"With 21 years heritage in accessible user centred design, Nomensa believes that digital experiences should be accessible to all, which aligns so perfectly with GDS's manifesto to be digital by default for the benefit of all citizens. Today was a genuine meeting of minds that has inspired us all to keep doing what we love for the benefit of everyone we serve."

LA International

"Interesting to meet other suppliers and understand their challenges and it was good to meet the GDS team in person to build relationships. There were some really good suggestions that came out during the SoW and Triage document discussions."

Get in contact! 

The Muslim Community at GDS hosted its third annual Ramadan Fast-a-thon. The Fast-a-thon started 3 years ago as an opportunity for people around GDS to experience and appreciate what Muslims do during the month of Ramadan and build a sense of unity.

Ramadan is the month in which Muslims fast from dawn to sunset and spend time on more religious activities. Ramadan is something that Muslims look forward to and use as a time to reflect. It is usually a very social period when people come together to break their fast.

Taking part in the Fast-a-thon

To try and include as many people as possible, the Fast-a-thon provided different ways for people to take part. We were mindful that not everyone would have the ability to fast for the whole day.  Colleagues were invited to participate in a number of ways including:

• drinking water but not eating
• skipping lunch
• donating lunch money to the selected charity

This was really important and participants really appreciated that there were different ways to join in.

Beginning the day

As is traditional during Ramadan, for those that were able to fast, they would wake up before dawn (usually around an hour and half before sunrise) to eat their final bits of food before the fasting started.

Some participants reflected how it was amazing to think that millions of people around the world are doing the same thing, which gave them a sense of connection.

Support throughout the day

We hosted a Slack channel for all the participants, where they could share how they were doing throughout the day and send messages of support to others. People really enjoyed being able to share this experience together.

Whenever someone struggled, there was always lots of support and encouragement to keep people going.

Breaking fast together

This year, we also broke fast together, which is known as Iftar. This was done virtually. This was a really fun experience where we congratulated each other for completing the Fast-a-thon.

Many participants said how the fasting prompted them to appreciate the food in front of them and think of those who are less fortunate. There were also lots of comments about how good the food tasted after not eating during the day.

A big part of the Ramadan experience is getting together and seeing friends and family. So it was great to share that experience with GDS colleagues.

Reflections after a week

We also had a session after a week to share some thoughts and reflections.

A common theme was the feeling of togetherness and support in going through this experience together.

I was curious to know what it was like to fast, so I appreciated the opportunity to experience it along with colleagues, even just for one day. The conversations and reflections afterwards were really interesting. I'd definitely like to do it again next time!”- James, Lead Technical Architect

I really enjoy the day of fasting although I found it tough this year! There is something about the bonding and knowing that each of us is going through a similar experience that brings us all together. It makes you appreciate what you have and to think positively beyond the one day we fast. Utmost respect and thanks to everybody for taking part and to our Muslim friends for fasting for the whole month of Ramadan.” - Iain, Engagement Lead

I’m glad I took part in the Fast-a-thon and joined my colleagues in fasting. Not having my morning coffee was a challenge, and keeping my mind in check with good thoughts. It helped me be more mindful and purposeful. Knowing that I’m not alone kept me going as well. I really appreciated the moment of breaking the fast and sharing experience with others.”- Agz, Senior Interaction Designer

I'm really happy I chose to take part in 2022's Fast-a-thon. It was quite eye-opening to have a taster of what our Muslim colleagues experience during Ramadan, and the welcome and support I got from the Fast-a-thon Slack channel was heart-warming.

I found fasting hard at times. But overall, not eating didn't affect my work or mood as much as I thought it would. And of course, I had the privilege of knowing exactly when I would be able to eat again, many people in the world don't.” - Kim, Senior Content Designer

Reflections from Muslim colleagues

The Muslims at GDS really appreciated non-Muslim colleagues joining in. They enjoyed getting to know new people they hadn’t interacted with before and sharing their experience together.

As a Muslim, it's incredibly heartwarming to see non-Muslims fast alongside us out of solidarity, or take an active interest in our religion and what we do during Ramadhaan. The Fast-a-thon was a brilliant opportunity to connect with colleagues, and share knowledge and experiences! It was wonderful to exchange tips, thoughts and encouragement in the Slack channel - I picked up a few things myself despite having observed Ramadan for quite a few years now.” - Fatemah, Content Training Administrator

Final thoughts

The Fast-a-thon was a great opportunity to share the spirit of Ramadan and show different aspects of Islam. We also enjoyed the togetherness of the Fast-a-thon and the chance to get to know colleagues from different teams who we would not usually interact with.

We would like to also thank everyone for taking part in the Fast-a-thon with great commitment and enthusiasm. We hope to continue the Fast-a-thon next year and have more colleagues join in.

Site Reliability Engineers - or SREs - are primarily responsible for ensuring that the services provided by the UK Government (GOV.UK Pay, in my case) are working, continue to work, and that we spot problems prior to them developing into incidents.

There are a variety of ways this is accomplished: monitoring the current health and predicting the future health of the live service is only a small part of this. We also build the tooling and pipelines that help developers improve the service rapidly and safely, providing safety nets so that both the developers’ confidence in making changes is improved, and the changes that are made are safer to deploy.

A typical day

At the Government Digital Service (GDS) we enjoy a good work life balance, and a great part of this is the availability of flexible working. I tend to start earlier than most people so I have a quiet period leading up to the daily stand-up meeting. This means typically I will work on current project work from around 8am to 9.50am, when we have our team stand-up.

Some of the recent projects we have worked on as a team are:

• migrating our infrastructure from being installed on AWS EC2 instances, to running as containers in AWS Fargate, which allows us to run our applications serverlessly, reduce the overall support burden and maintenance required, as well as allowing us to scale our service more easily
• building a new continuous integration and deployment platform, and bringing all of our deployments and testing into it
• revitalising our performance testing environment, ensuring it is continuously deployed to after deployments into production
• automating performance testing and making it easy for developers to be able to load test changes they are working on

When approaching projects we often do a few exploratory pieces of work (known as spikes) early on to get a good understanding of where the difficulties may lie, to try and reveal any unknowns, and to test our designs before doing a fully robust and well-tested production build. This lets us iterate quickly towards our current goal and get a clearer view of which parts of the project might be more challenging.

At GDS we work in an agile manner, within most teams part of this is having a daily stand-up meeting. So at 9.50am our team has a stand-up where we have a very quick look to see if anything needs signing off, requires reviews, or is totally blocked. The stand-up continues and we each mention what we did the previous day and what we are planning to do on the current day, this also gives us a chance to ask for help or reveal any potential problems we have found.

After stand-up there’s usually a few more hours to continue working on the project work before lunch.

Many teams have some days a week which are no meeting days, so the afternoon will either be a solid block of time to get into your project work without interruptions, or a chance to go to one of the community meetings as well as continuing with your current project.

There’s also plenty of opportunity to present new ideas, or questions you might have to GDS’ communities which could need a wider discussion. These meetings often happen in the afternoons and give you a good chance to connect with your peers.

Community and collaboration

There are many communities within GDS: communities for Java, NodeJS, Golang, accessibility, content, and site reliability engineering among others. These communities tend to have get-togethers regularly as well as their own digital communications channels where you can ask for advice from other members of the community.

Attending either the weekly infrastructure meeting or an SRE community meet is an enriching experience where you can hear about what other work is happening around the Cabinet Office, any challenges people might be facing, and if any incidents might have occurred and what we can all learn from them.

Learning

GDS really helps people to work towards their career goals, so I’ll often finish off a day by spending some time using one of the e-learning platforms available to us. I’ll refresh my knowledge on an area of interest or work, working towards a future goal, such as attaining a new certification or refreshing an existing one.

One of the driving factors that led to me joining GDS was knowing that work is done with space for learning, with time to investigate and develop the appropriate solution - not necessarily the quickest in the short term but the most robust and appropriate long term. This space affords me the opportunity to grow as a professional and to deliver the best possible solution for the public which is accessible, robust, and delivers value.

Could this be a career for you?

If you’re passionate about helping to transform government services, why not join us? GDS don’t follow tech standards, we set them, leading on the once in a generation transformation of government services. If you think you’d be a good fit you can find out more information on the GDS careers site.

Naturally, I’ll be honest, I’m someone who avoids leaving their comfort zone. My daily life ordinarily consists of very little risk, and therefore very little personal growth outside of work. It is somewhat out of character then, you might think, for someone who’s never climbed before, never travelled, to be flying more than 11 hours to Tanzania to climb Mount Kilimanjaro.

Being someone who is hugely passionate about doing public good and working in the public sector - hence my time at the Government Digital Service (GDS) - it’s important to me to feel like my job, my hobbies, my pursuits make a difference. I will always be happy to work somewhere, or do something, where I can offer a benefit to the public at large: proud to make a difference.

At GDS I was proud to act as a mentor to both apprentices and people on the Movement to Work Scheme, passionate about creating equal opportunities for people both young and old. I think it’s vitally important that we, and organisations, look to unlock and empower potential and thus futures.

At first, naively, I was rather indifferent to the idea of climbing, seeing it as just another form of exercise. However, the literal sheer scale of this venture soon dawned on me. Standing at 5,895 metres, Kilimanjaro is the African continent’s highest peak - a snow-capped volcano made up of 3 cones: Kibo, Mawenzi, and Shira. Needless to say, I am now exercising as much as possible in preparation for my climb on 17 August.

Climbing high to dig deep

I am fundraising for Dig Deep, a charity that believes in the fundamental right of African citizens to have access to safe toilets, good hygiene and clean water. Where they work in Kenya, 8 out of 10 people are not so fortunate.

Dip Deep’s mission to collaborate with the Kenyan government is something I’m passionate about after working in government myself and seeing the transformative power of collaboration. Dig Deep focuses on transforming citizens' access to clean water and good hygiene, empowering people.

Most residents Dig Deep work with live in rural communities, spending hours every day walking to collect dirty water or find a safe place to go to the toilet. Dirty water and poor hygiene spread diseases, meaning even more time is lost to sickness. For a child, this can mean the difference between receiving an education and not; for a parent earning enough to feed their family or not.

In training

My climb, over the Mangaru route, will last 5 days, starting at base camp on 17 August, with a sleep on the summit, the dormant Kibo cone, on 22 August. Mangary, the oldest and most established trekking route, despite being one of the shortest routes, has the highest rate of failure due to the high stamina and endurance needed to acclimatise speedily.

In preparation I have become a familiar face at my local gym, as well as getting the most out of my training as an army reservist. I’m currently going through Phase One, or basic training, attending ‘drill nights’ and a number of weekend training sessions, with my fellow recruits. My military gear will certainly come in handy for the majority of my clothing needs on the Kilimanjaro climb: I’ll be taking lots of wet and warm kit to deal with constantly shifting climates as we climb higher.

The steps to come

Whilst I’m nervous about the climb I’m also incredibly excited, this after all is the challenge of a lifetime. Looking back at my career so far I’m really pleased that I get to work for organisations like GDS that really make a difference to people’s lives, and continues to support me on my career journey and fundraising work, even though I’ve now moved on - an organisation that, like me, wants to make positive change and supports their people as part of their alumni.

Working within government has inspired me to continue to do so in the future: in my career and in my fundraising work. GDS, and the civil service, are full of people like me, people who want to make a difference and empower others, both in their day to day job and in the work they do outside of the office. My climb in August is just one example of the steps I, and many others, take every day to have a positive impact on the world.

Building government services that are inclusive is a crucial part of our work. After all, not everyone can easily prove their identity and therefore not everyone can easily access the government services they are entitled to online.

This blog post talks about why this matters, to us and our users, what we are doing to address it as part of the One Login for Government programme and how it impacts not only what we build but also how we are developing our new identity platform.

Why this is important

The very biggest government services have to cater for everyone in society and therefore can’t adopt an identity solution that isn’t inclusive. A digital identity solution that locks people out has huge implications for service teams. This is because exclusion disproportionately impacts vulnerable users.

What’s more, these government services operate at scale, where small percentages amount to very large numbers. For example, if we build something that can be used by 99% of the UK it would still exclude about 700,000 people. By way of context, that’s roughly the population of Sheffield.

Added to that, alternative routes, like using call centres or face-to-face contact with agents, are far more expensive than digital services to run.

What we are doing

As part of this work, we’ve spoken to people who have been prevented from accessing a critical government service because they can't prove who they are. They include survivors of domestic violence who fled their home so no longer had physical access to any identity documents. There have been many more who simply can’t justify the cost of a passport only to use it as a form of ID. And then there are homeless or transient members of our society who aren’t registered at a fixed address.

We have been looking at the inclusion barriers and working with groups of excluded users.

We completed a discovery, pulling together existing knowledge about the problem of identity inclusion barriers, with folks in service teams from across government sharing hard-earned lessons and suggestions for approaches to explore.

Our initial focus was on understanding the needs and experience of users that were of low digital literacy, low income and with people that did not own a passport or driving licence.

We researched alternative ID sources to a passport or driving licence, such as a birth certificate, and used service prototypes to test whether people have access to these documents, if they would be comfortable using these documents to prove their identity, and whether this would be easy or hard to do.

The primary aim of the research was to understand attitudes to using information relating to alternative ID sources to prove identity, whether people can access the information required from these alternative ID sources, and to understand users’ mental models of identity verification in the context of accessing government services.

We thought about ID documents that people do have, and made some high-level estimates about how many people have access to them. There are a great many sources to choose from so we scoped this to a prioritised top 5: banking data, vouching, GRO (General Registry Office) data, patient records data, and pension and benefits data.

From this work we created a list of high potential opportunities that might improve inclusivity and ran short time-boxed experiments looking at each one, learning as much as we could before moving to the next.

In concluding that discovery work, we made 3 service and feature recommendations and are now pursuing all of them.

1. Digital vouching

For users who cannot prove they are the person they claim to be, we are investigating whether a digital vouching process would help. This involves a person asking someone else to confirm their claimed identity and is similar to a referee signing the back of a passport photo to verify the true likeness of someone. Early research suggests that most users should be able to use this new approach.

2. Security questions

Secondly, we will be supporting the use of security questions, also known as ‘knowledge-based verification’, which enables users who might not have identity documents to prove who they are. We will do this by asking questions, based on their records, that only they should know the answer to, and to provide the challenge at different levels of confidence depending on the service they wish to access.

This will allow us to serve up knowledge-based verification questions that will verify people to the level of assurance needed for them to access the service they need at that time. For example, checking non-sensitive information about yourself might require a low-confidence identity check because there is a low risk of fraud, but receiving a financial benefit may require extra steps.

This approach means that a person’s level of assurance can grow over time and they’ll be taken through top-up steps to increase their assurance level only when it’s needed for the service they’re trying to access. It will also increase the likelihood of users with little or no records associated with them on government or credit rating agency databases being able to complete a digital ID verification.

3. Joining up government data

Finally, we’re exploring how to widen the number and type of high-quality security questions generated to support different types of users. We are also investigating how we can use wider government data sources to create new questions so that people can successfully prove their identity online and access services. We're proposing new secondary legislation that will support making this data-sharing possible.

It will do this by opening up a range of government-held data sources and permitting the reuse of previously-verified identities across different government services that require similar levels of assurance, with user consent.

Collectively these initiatives will support the accessibility and inclusivity of the service, and will provide a way for users to interact seamlessly with services.

But we know an online solution will not be suitable for everyone so we’re looking at offline routes and working on effective user support channels as well. We will continue to share our learnings.

The GDSF (GDS + DSF) Team in Cyprus at an event showcasing our work and the Service Standard to suppliers.

"Simple, clear purpose and principles give rise to complex intelligent behaviour. Complex rules and regulations give rise to simple stupid behaviour." - Dee Hock

GDS Advisory International works across the globe helping countries on their digital transformation journey.

In some of the countries we partner with, our focus is on co-delivering service standards. Written for digital people, by digital people, the standards are a set of principles that helps departments create great digital products or services. They are one of the foundations for any digital transformation project.

Service standards are deployed in different forms in countries around the world, including the United Kingdom, Argentina, India and Singapore.

We’re currently partnering with Cyprus, and one of the areas of work is their first service standard. The adoption of their contextualised service standard has changed their approach to public and private sector digital delivery.

This proved critical in the delivery of their first exemplar service, through simplified language to make it more accessible and reduced input requirements for the user by applying integrations. The service standard enabled Cypriot colleagues to think of the service from a user’s perspective, reducing content and questions that are not relevant to their situation and making it easier for users to provide documents.

The new Cyprus Service Standard, that is easy to understand and use, is fundamental to ensure quality and consistency to all government services." - Theodoros Demetriades, Cyprus Standards Lead

The unique principles that make up a service standard are  developed with each country and are the source of useful guidance for achieving quality digital services and products. Having simple principles such as "understand users and their needs" makes it easy for everyone to understand and follow.

Most national or state governments’ service standards focus on 3 main themes for their principles:

1. Understanding users and their needs
2. Agile ways of working
3. Choosing the right tools and technology

We have been working on our own service standards since 2012, with several iterations along the way to reach the current 14 principles. To help grow the community, we have developed a process to support partner countries as they develop and tailor their own service standards and guidance.

Our approach to international co-delivery

By focusing on a country’s unique needs, GDS Advisory’s International Team supports countries to develop service standards that are bespoke to their requirements, markets and contexts. This drives not only what their final service standard looks like, but also how the service standard is developed. No matter whether it is in-person, delivered remotely, or a mix of both, we start with user needs, iterate, and develop a Minimum Viable Product (MVP) Service Standard for testing.

What we learned

Of course our own experience feeds into this process, but we’ve learned from and worked with many governments around the world.

1. Research early, research often

We start with thorough research about our partner country’s aims. We identify key priority areas for developing standards with them and focus on those.

In 2020, our team worked with the digital agency of Penang in Malaysia to establish bespoke user research guidance for their service standard, to support their Digital Transformation Masterplan. Working with their team, we were able to test if the user research standards and guidance helped improve their understanding.

Based on the findings, we changed their standards to focus more on user research. We also used our user research findings while working in Penang to help UK teams iterate and improve our digital and technology guidance.

2. Understanding user needs over user wants

We have learned the importance of listening to our stakeholders and the value of providing supportive challenges to ensure we are meeting their needs effectively.

An example of this is with a partner in Eastern Africa, which wanted to work with GDS to improve its digital spend controls to get better value for money from its digital products and services. They had a form of assurance, but it did not meet user needs as projects were still being approved without clarity on outcomes or benefits.

From our experience, assurance processes cannot add value on their own without clear standards to assure services against. Although standards were not a priority for them at the start of our work with them, we recognised their need and co-developed standards to complement the new spend controls process.

3. Keep a multidisciplinary approach throughout

Multidisciplinary expertise is central to creating user-centred and practical standards. Using a multidisciplinary team can bring together many different perspectives and areas of expertise to deliver a common goal.

A key example of this is our work with the Government of Cyprus’s Digital Services Factory team. As mentioned, our GDS multidisciplinary team has been co-creating a new national service standard with our Cypriot counterparts. These standards define our work in building exemplar services for GOV.CY, with practical delivery experience.

We used the service standards while co-delivering our first exemplar service. Each member of our multidisciplinary team is paired with a counterpart in the Cyprus Digital Services Factory to support the sharing of knowledge, build capacity and experience on how to apply the newly created service standards to a service.

This ‘learning by doing’ approach enables the Digital Services Factory team to deliver better services that meet user needs. A multidisciplinary team working together helps us demonstrate how the standards work in practice. The experience we gain from working with the team forms the next iteration of the standards.

What lessons can departments in the UK learn?

Using service standards is essential for digital transformation. Our work demonstrates the strategic importance of service standards to digital transformation in the UK and worldwide and shows the importance of applying service standards.

For those in departments either leading teams or working in them, these 3 lessons (research early and often, understanding user needs over that of user wants, and supporting multi-disciplinary teams) will help deliver services that meet user needs, and will help digital transform your department or organisation.

Diversity information, and particularly gender and sexual identity, is very personal information, but it is also complex and broad information about a person.

Diversity data matters because it can help us understand the impact of our working practices and policies. By tracking diversity data and cross-referencing it with recruitment, retention, learning, development and progression, we can work to make sure that both recruitment processes and career progression are more diverse. It allows us to see how far we have come and how far we have to go.

At the Government Digital Service, ensuring the diversity of our team is key. Located at the very centre of government, our role in supporting the government to build brilliant services for everyone means that we, more than ever, are working to ensure diversity of thought and representation of the country that we serve.

Recording your gender identity and what we did to change this

We surveyed staff at Government Digital Service in October 2021 and they told us that the options to record their gender identity for their employee records was too narrow and didn’t allow the option to provide a description that reflected their identity accurately. The data recording options only allowed staff to record their gender as ‘male’ or ‘female’, but didn’t cater to those who identified any other way.

People made suggestions to add more options and allow free text to describe their identity themselves. People felt that the lack of options restricted them and made it more likely that they would not provide information at all.

Our LGBT+ group worked with other parts of the Cabinet Office to explore what questions or options could be added into our data recording system, how these could be implemented and what the timelines could be. During this process, we shared the questions with members of the LGBT+ community in Government Digital Service to get views as well as keeping them updated on the progress.

Working with a wide network of colleagues across the Cabinet Office, we secured an option to add and recognise gender identity in our recording system, which was added in March 2022.

People are now asked firstly if they identity with the sex they were assigned at birth and can answer ‘Yes’, ‘No’ or ‘Prefer not to say’. If they answer the first question as ‘No’, they are then given the option to provide free text about their gender identity.

We’re looking forward to seeing the results of this change reflected in our quarterly data during 2022/23 and hope to share some more information about this in a future update.

Diversity and inclusion strategies

Government Digital Service supports the Civil Service Diversity and Inclusion Strategy: 2022-2025 to have a truly diverse workforce and culture of openness and inclusivity. Team diversity is crucial to organisational performance, innovation and difference of thought.

Establishing teams with differing perspectives, experiences and insight is integral to tackling complex problems, and there is a clear correlation between diversity and organisational performance; enabling better attraction of top talent, improvement of employee satisfaction and decision-making, which leads to improved outputs.

Recording data helps to review progress

However, we can only achieve this if we collect information about who is in our teams and match companies like Monzo in their ability to report and be transparent on the diversity of their organisation and see how this changes over time.

Enabling staff to record with the Cabinet Office that they identify as a gender beyond the binary of ‘male’ or ‘female’ is a major step forward in helping those people feel valued and understood.

As well as adding this option to our data recording, GDS has also encouraged people to fill out spaces in our internal communications tools to record their preferred pronouns and people are also encouraged to include these in their email signatures.

GOV.UK Pay is the payments platform for the public sector. We want to make it easy for anyone to pay the public sector online and over the phone. We want to make it easier and cheaper for public sector teams to take and manage payments.

In 2018 we released payment links. With these, public sector teams can set up a standalone payment page in a few minutes, without any technical knowledge, and send it to their users to take a payment.

Services can now pre-fill the amount and payment reference in the URL they share with the user. This means that services can set up one reusable payment link and then share a personalised version of the link with each paying user in an email or text message.

Payment links make it easy to take an online payment for services that aren't part of an end-to-end digital journey. For many of these services, the user was previously asked to make a payment over the phone or send in a cheque. Offline methods are around 4 times more expensive, are more manual processes, and can make it harder for some users to pay.

Payment links are used by more than 150 organisations, ranging from dropped kerb applications to surgical training courses to boatmaster licences. We've had feedback from services that it greatly improved efficiency of their operations, and they allowed teams to get services online quickly during COVID-19.

For example, instead of requiring users to call up to pay during office hours, they could now pay 24 hours a day. We also saw that users prefer to pay online when they have the option. On one Home Office service that introduced GOV.UK Pay, 75% of card payments are now made online, rather than over the phone.

What we learned

We used a mixture of data analytics and qualitative feedback to understand how payment links were being used in practice.

Some services told us they weren't sure about using payment links if users entered their own reference number. Incorrect references create manual work for finance or operational teams to match up payments to cases or applications. When we spoke to services using payment links, they said that paying users generally provided the correct reference, especially since service owners were able to add instructions on where to find the reference. But we could not guarantee that incorrect references would not get through.

We also looked at our logs and noticed service teams using payment links in ways we had not expected. We expected public sector teams to set up one payment link that lots of different paying users would use. Instead, some services were creating one payment link per paying user, and putting the reference number in the title of the payment link. One service had created more than 600 payment links like this.

It looked like a workaround to make sure that the reference number could be set by the service team so that they could be confident it was correct. Even though each payment link only takes a few minutes to set up, that is not a great use of time, it makes managing user permissions more complicated, and there are a lot of out of date payment pages still being hosted on GOV.UK.

We also researched pain points for finance teams through research interviews, surveys, and collaboration with the Government Finance Function and Government Shared Services. We found that invoicing is a problem. More than 400,000 invoices are issued each year in central government, and many cannot be paid online. Finance teams also spend a lot of time chasing overdue invoices and we thought this was in part because users had limited ways to make a payment, especially if they couldn't easily call during office hours.

We thought there was an opportunity for GOV.UK Pay to make it easier to pay invoices online, which would reduce the manual work for finance teams associated with offline payment methods and reduce the number of overdue invoices. We also needed to improve services' confidence that payments had the correct references.

What we did

Services can now use query parameters (extra information at the end of a URL) to pre-fill information when using payment links.

When the user opens the link, they're taken to a landing page explaining what they're paying for.

When the user selects 'Continue', they'll see the details that have been pre-filled by the service.

How it's working

We're currently testing pre-filled payment links with a few beta partners and will be releasing this to new and existing services in a few weeks.

HM Land Registry is sending pre-filled payment links to users who sent cheques that haven't cleared. When the payment is made, data about the transaction will go into their finance system (Oracle Fusion) and be automatically matched up to the right user.

We're hoping to see services that are currently creating dozens of payment links use this instead. We're also hoping that this makes it easier for public sector finance teams to start using GOV.UK Pay for invoices, fines, and other ad hoc payments.