Here at GDS we’re focused on making digital government simpler, clearer and faster for everyone. As part of the early access phase of GOV.UK Forms we wanted to put this into practice by demonstrating just how quickly and easily you can create an online form.
With a sold out online audience, we hosted a webinar showcasing the service, current and future features, and showing how GOV.UK Forms is already making a difference across government.
GOV.UK Forms replaces the dependence on PDFs and document-based forms. In just a matter of minutes you can create a new online form that’s quick to process and incorporates lots of GOV.UK Design System components which are focused on accessibility. This makes it even easier for people to complete government forms. Best of all, there’s no need for any technical knowledge to create a form and it’s completely free to use!
During the webinar, we conducted a live demonstration to showcase the ease and efficiency of GOV.UK Forms in action. In under 20 minutes a form was created, which included basic routing and some detailed guidance for the person completing the form.
The purpose of the example form created in the webinar was to capture feedback from the audience. It included questions such as name, date of birth, webinar attended and previous experience of form builders. The questions used a variety of methods to submit data, from text to buttons. Another feature on show was the ability to autofill answers, where you have information such as name and address already stored on your device.
Providing questions that are clear and easy to understand are vital to help people complete a form once published. During the demonstration we also showed how the form builder provides helpful information in hint text, and prompts the person creating a form to include contact details for anyone needing additional support.
While you don’t need any technical knowledge to use GOV.UK Forms we’re also exploring more advanced options for departments and teams with more digital expertise.
The next presentation in the webinar provided a brief technical overview of the service and work towards future opportunities. For instance, currently form submissions are emailed to a chosen inbox from which they can be processed. This is fine in lots of cases and, as demo-ed, is really easy to setup. But we know departments have more complex needs for receiving and processing form data so we are learning and looking at how we might send data differently to support automated form processing.
This presentation also outlined how GOV.UK Forms follows the 14 cloud security principles from the National Cyber Security Centre.
User feedback is critical to the development of GOV.UK Forms and this formed an integral part of the webinar. John Ploughman, Head of Content Design at the Driver and Vehicle Standards Agency, described his first hand experience of GOV.UK Forms, emphasising its role in saving time and simplifying processes for DVSA teams:
It'll make life easier for your colleagues and for your users [...] all of this is saving teams at DVSA time.
John Ploughman Head of Content Design at the Driver and Vehicle Standards Agency
Looking ahead, we're enhancing GOV.UK Forms with new features and capabilities. In our final presentation we shared upcoming developments, including the integration of payment links powered by GOV.UK Pay, which is a seamless solution for accepting payments through online forms. Additionally, improvements to user access management processes and the introduction of multi-answer questions will further enhance the platform's functionality, empowering departments to utilise GOV.UK Forms in a more self-service manner. The audience also heard how GOV.UK Forms will be available to the wider public sector in a later phase, once we have a scalable product for central government as this is our core mandate at GDS.
The webinar closed with a chance for audience members to put questions to the GOV.UK Forms team. Examples included:
The questions shared and feedback to the presentations showed just how much interest there is in GOV.UK Forms. While we’re currently in the early access phase of the platform's development, look out for further webinars as more features are released.
During the GOV.UK Forms early access phase, government users can register and create a trial account to start building new forms. Get started today.
GOV.UK Pay has grown every year since launching in 2016. 2023 has been our biggest year yet with 364 public sector organisations currently using Pay to take payments for 960 different services, an increase of 21%.
The Pay customer satisfaction survey is one of the ways that we get feedback from Pay users, ensuring that we continue to deliver for the needs of diverse organisations and services that use Pay.
This survey allows us to collect quantitative data from a large group of people. We ask a range of different questions to understand how our public sector users feel about the different features available on Pay, and where we could improve.
In the questions, users are asked to rank the benefits of Pay and to score how satisfied they are with different features on a Likert-type scale.
In 2022 the survey was sent to 1,000 Pay public sector users who had logged in to the Pay admin tool at least five times in the last 12 months. We decided to widen the pool of people in 2023, sending to public sector users who had logged in at least once in the last 12 months; a total of 3,444 Pay users.
We saw an increase in satisfaction for the majority of categories in 2023 compared to 2022.
Overall, 88% of respondents said they are satisfied with Pay, a 2.7% increase from 2022.
Satisfaction with Pay’s 24/7 support increased from 72% in 2022 to 75% in 2023. Users said that the 24/7 email support is prompt and comprehensive, with one user from His Majesty's Passport Office stating:
I have always had a quick response when I have contacted GOV.UK Pay, and my queries are always dealt with to everyone's satisfaction.
The satisfaction levels for reconciliation increased by 17% from 2022 to 2023. The main theme for the high levels of satisfaction is the ease of use for reconciliation “Easy to use, simple to reconcile”.
Some of the main benefits users were satisfied with included:
In the 2022 survey, 50% of people told Pay that they wanted a pay-by-bank feature where customers can pay directly from their bank account. In response, we started a discovery in 2023 into how we can offer pay-by-bank.
46% of people surveyed in 2023 told us that they wanted to see an increase in the number of paying users that complete their payment. We are making improvements to the design of the payment journey to address this and these changes should be released soon.
We also know from both the 2022 and 2023 surveys that Pay users want to see improvements in the reporting options available—in 2022 users told us that they wanted more detailed and auto-generated reports. “Ad hoc reporting is very good, but daily reports should be system generated, not user-generated”. We are exploring how we can do this. In 2023, 30% of users surveyed wanted to reduce the time it takes to reconcile payments.
Some of our users also told us that they are not aware of new and existing Pay features, so we will be engaging with them to ensure we advertise Pay’s features more regularly.
We will combine the findings from other user feedback sources such as support requests, user research and analytical data to prioritise improvements that we want to make on Pay.
We’ve already started to update our roadmap based on what we have learned from our users. To start with, we're exploring pay-by-bank, then we'll be improving the filters on the Pay transaction dashboard, so that it is easier for our users to find and manage transactions. Keep an eye on our roadmap for new updates as we have them!
GOV.UK Notify is hosted on the GOV.UK Platform as a Service (PaaS). The PaaS is being retired, so we are migrating all of our infrastructure into our own Amazon Web Services (AWS) account. This blog post explains how we migrated our PostgreSQL database with minimal downtime.
The PaaS provides a database for us and we use it to store all of our data - from data about each notification we send to the content of the hundreds of thousands of templates service teams use to send those notifications. This is an AWS RDS PostgreSQL database and it lives in the PaaS’ AWS account. Our apps that run in the PaaS talk to this database. We are going to call this database our ‘source database’.
We needed to set up a new database in our own AWS account, and get all of our apps to talk to the new database. We are going to call this new database our ‘target database’.
Creating a new PostgreSQL database in our own AWS account is not too difficult. The hard part is transferring all of our data and getting our apps to use this new database, whilst incurring minimal downtime.
Our source database is about 400GB in size. It has about 1.3 billion rows, 85 tables, 185 indexes and 120 foreign keys. It is PostgreSQL version 11.
On a usual weekday, we do somewhere in the region of 1,000 inserts or updates per second (sometimes much lower, sometimes much higher), plus a similar number of reads.
GOV.UK Notify sends millions of important and timely notifications each day, from flood alerts to updating users about their passport applications . Every notification we send requires talking to our database. Therefore it’s important that we minimise any downtime.
The PaaS team offered us the ability to migrate databases using AWS Database Migration Service (DMS).
DMS is responsible for transferring data from our source database to our target database. It can be run in either the source or target AWS account.
DMS works by:
We would then be responsible for getting our apps to stop talking to the source database and start talking to the target database.
The database migration process was completed in several stages.
In our case, the DMS instance was created in the source AWS account. We chose the source account because the PaaS team had already set up instances of DMS in their account and so were able to do this quickly and easily.
The DMS instance also needed to be given PostgreSQL credentials to talk to both the source and target database.
The DMS instance and the target database live in different virtual private clouds (VPCs). With the help of the PaaS team, we set up VPC peering so that traffic from the DMS instance in the PaaS’s VPC could be routed directly to our VPC without the traffic going over the public internet.
We created our target RDS instance in our own AWS account. PostgresSQL version 11 was about to become unsupported, so we took this opportunity to upgrade our PostgreSQL version by making our new database PostgreSQL 15.
We then took a dump of the database schema for our source database using `pg_dump`. This gave us a file with the SQL commands to recreate our database schema.
From our database schema, we took the declarations for our tables and applied these to our target database.
We didn’t apply our foreign keys at this point because DMS’ full load process doesn’t try to copy across the data in an order that matches your foreign key constraints.
We didn’t create our primary keys or indexes at this point because this would massively slow down our full load task. Each individual insert would take longer; it would need to update our indexes and this would add up to a significant amount of time when inserting billions of rows. It was much quicker to first copy all of our data across and then add the indexes afterwards.
Once we had a target database with the tables created, we then started the DMS full load task. This copies across all the data that existed when we pressed the ‘start full load’ button. It doesn’t copy across any new data or updates that come in after this point. It took about 6 hours for the full load task to finish.
After the full load task completed, we applied the remainder of our source database schema file which adds our indexes and key constraints. Adding these took about 3 hours.
Once our full load task completed, the data in our target database matched the data from the source database at the point when we started the full load task. But many new inserts, updates and deletions had happened on our source database since then. And many more changes would keep coming in too.
To copy these new changes across, we then started the DMS ongoing replication (also known as change data capture) task. This reads all the transactions from our source database transaction log that were created after the full load task began and sends them to our target database. This ensures that our target database is in sync with our source database with, at most, a small amount of lag.
It only took a couple of hours for the replication process to catch up. At that point, we monitored the latency in the DMS replication process to make sure it could handle the number of changes happening to the source database and continued to stay in sync.
We ran the DMS replication process for about 10 days in the background, keeping everything in sync whilst we awaited the time for our apps to stop talking to the source database and start talking to the target database. We had announced this time to our users in advance and so had a set time already for the migration of traffic.
Several months ago we planned how we would stop our apps talking to our source database and get them using our target database.This was the process we used:
It was important not to have some of our apps talking to our source database and the rest talking to our target database at the same time. If this happened any changes on our target database would not be reflected on our source database which would mean users would get inconsistent data.
We wrote a Python script for this process so it could be explicit, easily repeatable and much quicker than being done manually. The quicker it could be done, the less downtime for users of Notify. Our target was less than 5 minutes of downtime. We ended up using this script at least 40 times during our various tests and practices beforehand.
We picked a Saturday evening for the migration. This is because it is one of our quietest times without us having to be awake in the middle of the night when we won’t be as alert.
Our script would stop all traffic to our source database by calling `pg_terminate_backend` on all the connections from our apps. This took less than a second. We also changed the password for the PostgreSQL user used by our apps, meaning that if the apps attempted to reconnect to our source database they would get an authentication error.
DMS inserts some useful tables into our target database on the status of the replication which are updated every minute. These tables allow us to see how much lag there is between our target database and the source database. Our migration script would check these tables to make sure our target database was entirely caught up.
To be extra safe, after our apps had stopped talking to our source database, our migration script would write a single record to our source database and then wait to see that it safely arrived in our target database. This gave us extra certainty that all changes had been replicated.
For our apps to connect to our database, they need to know the location of the database and also a username and password for a relevant PostgreSQL user. These are provided to our apps in an environment variable of the following format:
SQLALCHEMY_DATABASE_URI = postgresql://original-username:original-password@random-identifier.eu-west-1.rds.amazonaws.com:5432
If we want our apps to connect to a different database, we need to update the username, password and location in the URI and redeploy our apps so this change takes effect. Redeploying our apps takes about 5 minutes. If we redeployed our apps as part of our migration script then this would mean an extra 5 minutes of downtime. To minimise downtime we made two changes in advance of our migration so that we could use a quick Domain Name System (DNS) change instead of redeploying our apps.
The first change was to create a user on both our source and target database that had the same username and password. This means that we don’t need to change the username or password provided to the apps during the migration.
The second change was to create a DNS record in AWS Route53 for `database.notifications.service.gov.uk` with a 1 second TTL (time to live). It had two records with weightings:
We set our URI used by our apps to use our new username and password, and to use the new domain name for the location of our database.
SQLALCHEMY_DATABASE_URI = postgresql://shared-username:shared-password@database.notifications.service.gov.uk:5432
Now, when we wanted to swap the database that our apps would be pointing at, our migration script just needed to update the DNS weighting in AWS to 100% of results being sent to the target database location and wait 1 second for the TTL to expire. Then, when our apps next try to query our database they will be querying our target database.
When we gathered on the evening of Saturday 4 November, we had set up our target database, the full load process had run and new transactions were being copied across. We checked and only had a couple of seconds lag between our target database and the source database.
We then successfully ran our migration script so that our apps would stop talking to our source database and start talking to our new target database. During the migration there was a short period of downtime, roughly 11 seconds. This was much less than our 5 minute target so we were very pleased and so were our users.
We chose to use DMS because it was well supported by the GOV.UK PaaS and we could also get support from AWS. If we were doing a PostgreSQL to PostgreSQL database migration in the future, we would invest more time in trying alternative tools such as pglogical. DMS potentially added more complexity, and an unfamiliar replication process than what we may have found with other tools. This backs up what AWS say themselves on PostgreSQL to PostgreSQL migrations.
Now we’ve migrated our database, our next step is to migrate our apps. Sneak peek - we are moving them to AWS Elastic Container Service (ECS). We will blog about how this goes in the coming months.
If you’re interested in hearing about how a different team in government also migrated their database from the PaaS, then take a look at a recent blog post from the Department for Levelling Up, Housing and Communities.
]]>
We’re making it easier for departments to build digital services here at GDS and we’ve built a tool to make it easy to create online forms for GOV.UK without any specialist digital skills. GOV.UK Forms makes creating an online, accessible form as easy as creating a document.
We’ve been testing forms created using our tool with the public, and found they much preferred online forms to PDFs and other document-based versions. We learned some interesting things from users about why they find online forms easier to use.
We’ve been doing lots of testing with the immediate users of GOV.UK Forms - civil servants who create forms. But we wanted to check in with the people who end up using those forms - the members of the public who need to submit information to government.
We ran some user research sessions with members of the public to understand their experiences of using government forms. We asked them to complete a range of simple forms and share their thinking as they did so. Some of these were document-based forms in PDF or Word format and some were online forms created using GOV.UK Forms.
There was strong support for the online forms across the sample group we tested, with everyone stating they preferred the forms created using GOV.UK Forms. GOV.UK Forms uses the GOV.UK Design System, and our participants commented that they recognised the visual style as being a government site and something that they could trust.
I do like that familiarity every time I come to a form, and it’s something I’ve begun to kind of notice when I'm on the government website.
Forms using the GOV.UK Design System all look the same, increasing their sense of trust and familiarity.
Online forms created with GOV.UK Forms all end with a simple 'Check your answers’ page. Our participants said they liked this page showing them their information and giving them the chance to go back and change anything they weren't happy with.
Once I’ve finished, it also just means it's a lot easier to check as well, rather than having to look down through every section. You can be moving your eyes around quite a large area, whereas with this it's all nice and straight down the page.
When completing online forms, people were able to use ‘autofill’ to complete common information, such as names and addresses, that was saved in their browser.
One person gave more complete information because they were able to use previously saved information from the browser using autofill.
And yeah, obviously, you know, I know it's optional, but because I could just click, I'm quite happy to do it because it's not taken me a lot of time.
It's not always perfect, and one person found a previous form had caused them to save some incorrect information in their autofill, but it does usually save people time, especially if they use assistive technology.
One of the most distinctive aspects of online forms on GOV.UK is the 'one thing per page' principle. The online forms we tested had one question per page, and people commented that this was welcome and made the form easier to complete.
They said that this principle allows them to focus on one thing at a time and not worry about navigating through the form. They simply answer the question that’s in front of them.
You're not sort of presented with a long form straight away. It takes you through each section at a certain page, which I find helpful.
Being able to focus on one question at a time was also commented on as a positive by people with accessibility needs. We tested with people using a range of assistive technologies and this simple, focused layout was something many found helpful.
I'm not kind of bombarded or overwhelmed with loads of information at first looking at it. It's not making me look at it and think, you know, where do I start?
We also observed some people giving more accurate and complete information using the online forms.
We've been building GOV.UK Forms to make it easier for civil servants to create interactive forms on GOV.UK. It's been good to confirm that these types of forms are also easier for members of the public to complete.
Making forms easier and more accessible means people are more likely to submit accurate and complete information the first time around. This cuts down on the time both they and civil servants have to spend following up submissions.
It's quicker than the [PDF form] - and also, if I found out that I didn't put something in, it would alert me to it.
There will always be a place for document based forms where information needs to be provided in a situation where a hard copy works best, and to make sure people can access forms completely offline. However, using GOV.UK Forms can help government run services more efficiently, and can make it quicker and easier for people to access them.
[The online form] says it's been submitted without much of a hoo-ha, which is absolutely wonderful.
We’re providing early access for form builders across the government to set up a trial account and see just how quick and easy it is to start creating forms. You can register for a trial account on our website . While there you can also sign up to be kept informed of the latest developments and learn about new features added to GOV.UK Forms.
This is the first time I have written a guest blog for Government Digital Service (GDS), so I’m really pleased to be able to tell you more about my team and the work we have done with GDS and the GOV.UK One Login programme. You might be wondering why my team is called the FAT Badgers… We were originally called the Honey Badgers (due to being fearless and highly intelligent) but then we redesigned Find Apprenticeship Training (FAT) so rebadged ourselves the FAT Badgers.
In October 2022, our team in the Department for Education began the work to switch over to GOV.UK One Login for a range of our services. One Login will deliver a single consistent way for users to sign in and prove their identity to all government services, so being an early adopter was an exciting yet slightly daunting task! We knew we were in safe hands as services such as Disclosure and Barring Service basic check (DBS), Apply for a vehicle operator licence (DVSA), and Register to be a Social Worker service (SWE) had already joined GOV.UK One Login.
The Department for Education has a number of services which use different sign in methods. For example, the same people who use our ‘Find an apprenticeship service may use ‘Apprenticeship service account' however they have different portals to sign in.
Therefore, being a part of GOV.UK One Login increases our usability. We recognised that by adopting GOV.UK One Login our users would have a simpler process to register and return to our service. Our users include people like sole traders and small employers who really need their interactions with the government to be simple and fast, given they could be multitasking and how busy they can be.
Other important benefits of onboarding to GOV.UK One Login included:
The delivery team began the complex task of transitioning around a dozen separate sub-services to a new method of user authentication. The onboarding process involved working with the team in GDS to sign a memorandum of understanding, reviewing user journeys, planning our communications, and testing the service. After months of hard development work, our services migrated over.
Work in the open
Working in the open allows both teams to work at pace. We were regularly working to tight deadlines to ensure that there were solutions in place for all sign in processes. To improve ways of working we scheduled weekly meetings and set up shared Slack channels, letting us discuss issues together and unblock any stuck development tickets.
Working in an open way also helps teams that are planning their future switch to GOV.UK One Login. Our work was produced on public repositories so other teams can see how we integrated GOV.UK One Login and use our code, available on github, as a starting point.
This is particularly useful as we were one of the first GOV.UK services that use Microsoft .NET to implement GOV.UK One Login. We initially had some development difficulties as a lot of our services were using outdated Microsoft framework versions which did not support the updated security packages that were required for the integration to work. Now GDS can use our work as an example to support other teams which is a win-win for everyone.
User-centred design work is required
Though switching to GOV.UK One Login clearly involves development and resources for internal testing, this kind of project is an example of how each role in a service team is important.
For instance, our user-centred design team had to change the service to follow the GOV.UK One Login design recommendations. The design work included:
Throughout this experience, we've discovered that unexpected tasks can pop up now and then. It's crucial to leave some room for flexibility in your planning. We believe this is a valuable lesson that other service teams should keep in mind when making a switch.
Think about communications early
We worked closely with our colleagues in Service Engagement to ensure that users knew the switch was coming and understood what actions they had to take. We did this early: our first email was sent out to users over 4 months before the actual migration date. Service Engagement colleagues communicated regularly with internal employer facing teams, giving them key information to be able to support employers they work with.
As we were making a large change to the service, we also made sure we kept the National Apprenticeship Helpdesk in the loop. We provided guidance and documentation, so they could offer support to users.
Changing how users sign into a service could have been a daunting task, but by switching to GOV.UK One Login, we’ve implemented a future proof sign-in that improves our user journey. We found through careful planning of the migration, and regular communication with users, there was minimal impact on our support teams.
We couldn’t have achieved this successful migration without support from colleagues across GDS and DfE.
We recently reduced CSS size and improved performance across GOV.UK pages by moving away from bundling all CSS into a single stylesheet served to all pages to serving smaller stylesheets containing only the necessary styles for each page. There have been reductions of up to 40% in CSS size on some pages, accompanied by incremental improvements in timing metrics across many pages. These improvements could lead to a slightly faster experience for users accessing GOV.UK through older or low end devices or for people on slower connections.
GOV.UK is made up of many different applications. Previously, each application served a single stylesheet, a set of CSS rules that define the layout and appearance of a page, made up of many different types of styles bundled together. Styles can come from our component library (accordion, button, notice and more) or they may apply to specific pages within the application. Styles were served to all application pages. Bundles could sometimes include as many as 30 different style imports.
In addition, a separate stylesheet which includes commonly used styles like layout or typography styles is served from an application called static.
Bundling is a common HTTP/1 performance optimization technique where resources cannot be loaded in parallel and too many sequential network requests can take a long time to download, so it makes sense to bundle styles together to reduce network requests.
Concatenating multiple stylesheet assets into one bundle has its downsides.
Firstly, users might have downloaded CSS for unvisited pages. For example, the homepage previously loaded CSS for 24 components yet, aside from commonly used styles (included in the static stylesheet), only required styles for 5 components. Therefore, a homepage visit required 17 kilobytes of unused CSS to be downloaded.
Also, the application stylesheet cache was easily invalidated for small changes, which meant the browser had to download the application stylesheet again. For example, consider a small style change to the contents list component styles in our component library to change bottom margin spacing from 20px to 30px.
This small change would require the entire application stylesheet (27.7 kB gzipped) to be redownloaded. This is an important consideration when our component library is frequently updated.
Lastly, bundling all CSS doesn’t take advantage of the multiplexing features of HTTP/2 where multiple assets can be requested at the same time making it possible to serve many smaller files. HTTP/2 was switched on for GOV.UK in 2020.
To solve these problems, we created a new asset helper in the govuk-publishing-components gem. The asset helper is used to create a list of stylesheets required for rendering a page, it includes helper methods to add required stylesheets to the list and the `render_component_stylesheets` method to output the list of stylesheets as stylesheet link tags in the <head> of the document.
The asset helper ensures that all stylesheets in the list are unique. For example, if several button components are rendered on a page, only one button stylesheet is loaded.
The asset helper runs in the background for all applications that use GOV.UK Publishing Components, but implementing the individual loading of stylesheets feature is optional.
Once we had the asset helper available, the next step was to implement the individual loading of stylesheets feature in our rendering applications. We decided to do this one application at a time, starting with the `frontend` rendering app (which renders the home page, the register to vote and tax your vehicle services and more). This approach allowed us to monitor the impact of the change, giving us time to fix any issues before implementing in the next rendering application.
We also created detailed documentation for setting up individual component CSS loading in a rendering application. This includes step-by-step guidance, links to example pull requests and known issues.
Using SpeedCurve to test various pages, across various devices and connection speeds, before and after the changes, we’ve seen a site-wide reduction in CSS size together with performance improvements when measured against key performance indicators.
CSS size has reduced by 40% (dropping from 42 kB to 25 kB) on the GOV.UK home page along with improvements to timing metrics including Start Render (the time from the start of the initial navigation until the first non-white content is painted to the browser display), Largest Contentful Paint (a Core Web Vital metric which measures loading performance) and Last Painted Hero (a metric that shows you when the last critical content is painted).
On an emulated Mobile 3G device:
Likewise, for COVID-19 pages, there’s been a 27% reduction in CSS (from 44 kB to 32 kB) and similar performance improvements.
Such improvements will mostly be imperceptible to users on high end devices or faster connections but could make a difference for users on older or low end devices (GOV.UK analytics show a sizeable number of users using Galaxy A12, A13 and earlier models) or for people on slower connections - for some pages the improvements bring load times in under 3 seconds (statistics indicate that 40% of visitors will leave a website if it takes longer than three seconds to load).
Whilst these size reductions are encouraging, arguably the main advantage is in caching improvements. In the earlier example, a small spacing update to one of the application component styles forced the browser to redownload the entire application stylesheet. Now the same change means the client only downloads the updated component CSS (1.1 K gzipped). All other stylesheets are loaded from cache.
Whilst implementing the asset helper we identified other optimisation opportunities including finding and removing redundant code. We removed 32 stylesheets across 7 applications and more than 600 lines of CSS by removing unused CSS - styles that are no longer used anywhere - and also removing redundant code - custom helpers or component styles that are now available in the component library or design system.
Loading lots of individual stylesheets doesn’t always lead to performance improvements. For example, on detailed guide pages e.g. rates and thresholds for employers 2023 to 2024 which use lots of different components, users can download approximately 16 different stylesheets. Whilst CSS size is still lower than previously, performance indicators are adversely affected with time metrics slightly worse than previously.
Also, compressing files with small amounts of text doesn’t always produce smaller file sizes (or leads to hardly any size reduction) since there are fewer instances of repetition to be identified. It’s even possible to see larger file sizes in some cases.
However, the performance improvements across the site outweigh the downsides seen in these particular edge cases.
For some pages, where many individual stylesheets are served, performance metrics are slightly worse. We might look to group together some component styles, commonly served to the same pages, into smaller bundles to achieve better compression savings and reduce their size.
Also, we’re investigating loading JavaScript scripts individually, though this is more complex and will require changes to our component library to make use of ES6 modules.
Finally, future enhancements might include preloading assets based on predicted user journeys or lazy loading ‘below the fold’ component stylesheets such as footer and feedback component CSS; both positioned at the bottom of each page.
Interested in our work? GDS is hiring.
We launched GOV.UK Forms’ private beta back in April 2022 and we’re now ready to move into our next phase - ‘Early Access’.
So far, we’ve been working closely with 11 private beta partners and over 60% have already published forms. We’ve published 17 forms and we’ve got a pretty healthy pipeline of more forms being worked on. Our remaining partners are all getting closer to publishing their first forms which is hugely encouraging too. This means we’ve helped to solve some common problems experienced by lots of form owners and form processors.
Quotes from partners
This is happening at ridiculous speed, it’s a fantastic opportunity. I’d still be struggling to get a PDF through!
- Dan M, Animal and Plant Health Authority
And we feel that now is a good time to release the value we’ve created and allow more teams to use the platform.
During this phase, anyone who works in central government and has a gov.uk email address can try out using GOV.UK Forms by creating a trial account. They can learn about the platform and decide if this is going to be useful for them to build forms now. Trial accounts won’t allow users to create live forms but we’ll be considering requests to upgrade accounts, based on our criteria below.
This means giving access to our new form builder to more colleagues working in government. We’re doing this because we think we’ve got a great platform and lots of teams will benefit from using GOV.UK Forms, even at this early stage.
We want to do this in a managed way, one that helps us to test out new and existing features in a live environment and to scale up confidently.
Users can ask to upgrade their trial account and gain full access to the platform if:
It’s important to state that even with an upgraded account, users will not be able to publish any forms on GOV.UK themselves. To make a form findable on the website, form creators will need to work with their departmental publishing team to add a link and make any other content changes required.
We’re still in private beta and have lots to learn. Early access will help us to do this in a scalable way, releasing value to our users and tying this to our roadmap. We’ll be inviting more and more users to access the platform as we develop more features.
We’re building a brand new platform which means we have a growing, but still limited, set of features right now. You can ask questions for names and addresses, or for longer text answers, as well as asking for dates and answers which require a number. You can also create questions which ask a person filling in a form to select options from a list. You can even allow a user to skip future questions based on a previous answer.
Another really great feature we’ve recently added allows you to include detailed guidance, where typical hint text does not provide enough context or information to help people answer a question. It allows you to add guidance, as well as formatting, like bullet points, subheadings and links.
You can choose how to format certain questions such as, whether to ask for a name in one box or split this into first name and surname. We support autofill, allowing a user’s browser to automatically suggest information they’ve provided on other websites, for example for names, addresses and dates of birth.
We’ve just released a new feature to send confirmation emails to people who have filled out a form using an integration with GOV.UK Notify. Another cool feature allows you to see some simple form metrics, including weekly completion rates and the number of form submissions. This helps form owners to manage and to iterate forms, making them better and easier to fill out.
Over the next few months we’ll be developing our functionality in order to move into public beta where anyone working in central government will be able to use the product in a self-service way. We are hoping to move into public beta in the spring.
Before we move into public beta, we will integrate with GOV.UK Pay so people filling out forms can make payments using a payment link. We will also add functionality that allows users to include additional answers to the same question, a common pattern used on around 35% of government forms. For example, if a question asks for an address history for the past 5 years, users will be able to add multiple addresses.
We will iterate our sign-up journey and account management process to make it fully self-service. We will also complete some technical work to make sure our platform can scale for the increased demand.
Our aim is to design an easy to use, self-service tool which has an accessible interface, built with common GOV.UK Design System components. In this way, we think the new platform is a crucial tool to help us deliver better government services.
It’s our vision that all forms on GOV.UK will be accessible, easy to use and quick to process. This isn’t an easy goal - there are almost 10,000 document-based forms, most of which need to be transformed. GOV.UK Forms is making this vision real! Our product team has done a stellar job of creating research-backed solutions to real user problems, releasing value for the civil service and UK society. This is transformation and this team is on fire!
Amanda Dahl, Deputy Director, Digital Service Platforms, GDS
We’re already working closely with a number of teams to plan how they will improve their forms and help shape our product, both now and as we release more features in the coming months. If you work in central government, we’d love to hear from you, please do get in touch.
You can read more about the features we already have, and what we're working on next, on our product site.
Early Access is our big idea for scaling up! We hope you’re interested in working with us, learning more and helping to shape the development of future form features. We can only do this with your help, so please share with colleagues and any civil servants who may be interested in our form builder too.
We’ll also be hosting a webinar to discuss the new form builder and what’s coming up in January 2024. Details will be on our product site.
]]>Here at GDS, we’re making it easier for departments to build better digital services. GOV.UK Forms is an online form builder which can be used to make accessible and easy to use digital forms for GOV.UK. It saves time for departments that are processing form submissions, and time for users that are filling in forms.
In just a matter of minutes, government teams can replace PDF and other document-based forms with digital forms which all users can access and are legally compliant with the Public Sector Bodies Accessibility Regulations 2018.
Best of all, there’s no need for any technical knowledge and it’s completely free!
GOV.UK Forms is currently in private beta, where we’re testing the product out with a small number of teams that own forms. This is to help us steadily understand how our product is working and what issues we need to address. After that, we’ll move into public beta, where we’ll open up GOV.UK Forms for any central government department to use freely.
We wanted to share what we’ve been up to since our last update, and what we’re doing to open up private beta for a wider pool of users - a phase that we’re calling ‘Early Access’. This will allow departments with forms that only require current features to start building them, and also allow any government user to try out our product. It will also help us to ramp up our overall user numbers and test the stability of our platform before public beta.
In October 2022, the Insolvency Service was the first government organisation to publish a form with us. This was a relatively simple form as we only supported quite basic features at the time. The vast majority of document-based forms require more complex features to turn these into digital forms, including multiple options, declaration statements and more.
One of these features is routing, or skippable questions. If you think of any form that you might have to fill out, for example at the GP or for an application, the chances are that it will say ‘If you answer ‘No’, skip to question 13’ or similar. This is a really core requirement for form building, and we needed to find a way to build this so that people who aren’t digital professionals could understand how to set up this kind of logic for their form.
We created a new journey for form builders to add this to questions that ask for one answer to be selected from a list of options. They can specify which answer should route people to a future question and which question they should go to. The person filling out the form will then skip questions they don’t need to answer - saving them time and saving processing time too. You can see how this appears for form builders in the screenshot below:
We know this is not going to cover all routing needs though - in the future, we’d like to look at building branching (two separate sets of questions depending on the answer), and later down the line we might be able to expand our routing so you can add routes to more than one answer, and also routes based on a combination of answers.
At the start of 2023, if one of our users created a form, made it ‘live’ (meaning it can now be put on GOV.UK), and then later on wanted to edit their live form, any change made would be updated on the live form immediately. This would cause issues as form builders may be making multiple changes, or change their mind about what they want to edit. And each time this would happen, people that are filling in the form would be at risk of losing their progress.
So what we did is we made live forms uneditable - instead, if you want to make changes to a live form, you would create a new draft copy of that form. Then you could make all the edits you want, and only make that new version live when you’re happy with all the changes. This new version would automatically replace the existing live form - meaning this change only happens once, and affects a much smaller number of people filling in the form.
Our form builder already allows users to add hint text to a question, such as ‘Enter your name as it appears in your passport’. But sometimes on a form there are questions that need a bit more information for someone to answer - for example, specific guidance that they may need to refer to, or industry codes that need to be defined so that the right code is entered.
To do this, in September we released a feature called ‘detailed guidance’ that will allow this more detailed information to be provided to the person filling in the form. Here’s what it will look like for people filling out an example form:
Right now we use GOV.UK Signon to allow users to sign into our product and use it. However, each time that a new user wants access, our team has to set that account up. We also can’t give people custom permission levels based on what we want them to be allowed to do (and not do). Signon is currently making improvements to make it more self-serviceable, but this wouldn’t have been ready for us to start expanding.
So last year we decided that we needed to move off of Signon and use Auth0 (also used by Ministry of Justice’s MOJ Forms) for authenticating users, and bring the permission controls into the GOV.UK Forms product itself. We also wanted to create a system so that users could create their own trial accounts without our involvement (self-service), try out the product, and then be easily upgraded to the next permission level in order to make their forms live.
Doing this work is one of our key challenges to adding many more users onto the platform, and we’ve designed an easy flow to allow quick access to the product, whilst also keeping enough control of who can make live forms whilst we’re still in private beta. We also want to ensure we’re following good governance practices and ensure Memorandum of Understandings (MoUs) are agreed before somebody from a department is able to make a form live.
Before we kick off Early Access, there are some other features that we’re working on to implement, including:
Once we’ve achieved all these things, GOV.UK Forms will be ready for launching into our ‘Early Access’ stage within private beta, with a public beta launch planned for the first half of 2024.
We are planning to start our Early Access period in November 2023, at which point central government departments can start trying out GOV.UK Forms to see what they can make - and if they meet the criteria, we’ll be providing access to make those forms live. This will open up in public beta when departments can provide their own editor access to form creators. As with any agile development process, timescales can shift depending on what we find out along the way, and priorities.
Before we move to public beta, we have some much-requested features that we’ll be working on, including:
We’re not currently supporting organisations outside of central government, such as local councils or NHS and Police, but we’re hoping that we can see this scope expand later in 2024 and beyond.
If you’re interested in what we’re up to, please visit our product page and sign up to our mailing list, where we’ll update you when Early Access is launched - and please share with colleagues or any civil servants who may be interested in our form builder.
GOV.UK Pay is the payments platform for the UK public sector. Our vision is to:
September 2023 marks 7 years since we took our first live payment. Reaching such a milestone birthday gave us a great opportunity to reflect on how far we’ve come and decide on what’s next for Pay.
Here's what we're doing to deliver our vision.
Our aim is to support more central government and local authority teams to take payments for their services digitally. This allows them to automate their financial processes, reduces burden on their teams, and saves government time and money. This aim closely aligns with GDS’s strategy.
We’ve defined 6 strategic objectives as part of Pay’s product strategy. These objectives describe what we need to do for Pay over the next few years and why it’s important.
What: We want to expand from card payments into other inbound payment types
Why: Ten years ago, mobile wallets (like Apple Pay) did not exist, but now our users expect them as standard. This rate of change in the fintech industry is likely to increase and we’ll see our users’ expectations change too. We want to offer paying users with the most convenient ways to pay now and in the future
How:
In June, we released recurring card payments to enable our users to make payments in instalments without having to manually input their card details every time.
We already offer Apple Pay and Google Pay for our central government services. This month, we’ll be releasing the same mobile wallet payment types to our local authority services too.
Later this year, we’ll be investigating how Pay might offer open banking, so that users can pay for public services via their banking app.
What: We want to make Pay more usable and accessible for all our paying users.
Why: Paying for public sector services should be hassle free. It's important that the widest range of users are able to complete their payments as quickly as possible.
How:
We’re making updates to the payment journey, so that the content presented to paying users is clearer and easier to understand.
What: We want to improve the Pay admin tool and documentation for our public sector users
Why: So that public sector users can manage transactions and refunds quickly and focus their energy on delivering great services
How:
In June, we released webhooks so that services can receive automatic updates after payment events have taken place.
We’re reviewing and updating content in our tech docs to make it easier to use and understand.
What: We want to continue to provide a robust, reliable and secure payments platform for all our users
Why: We need to keep all sensitive information secure in line with legislation. We want Pay to continue to perform successfully as our number of users and services grows
How:
We’ll continue to provide responsive 24/7 support and improve our support processes.
We’ll continue to maintain our Payment Card Industry compliance.
What: We want to create the right conditions so that our team can do their jobs with as little friction as possible
Why: Reducing pain points for our software engineers will help our team to work more efficiently. This should shorten product release cycles, enabling our team to add value for our users more quickly.
How:
We’re improving the visibility of logs and metrics for our whole team, so everyone has access to the data they need to make decisions.
We’ve built up some technical debt and we want to address it. Over the next 12 months, we’ll be investing time in improving the quality of our code by breaking down known pieces of work and feeding them into our team’s backlogs.
What: We want to build up our team’s knowledge about procurement processes in government, and learn about payments suppliers in the fintech market
Why: So that we can make sure we work with payment suppliers that offer the best value for money for our services
How:
We’ll be growing our team’s commercial capability through training and partnering with commercial experts across government.
As well as describing what’s in our strategy, it’s equally important to describe what’s not in Pay’s scope and why.
The main areas Pay will not be exploring are outbound payments, Direct Debit and PayPal.
Pay provides inbound payments, enabling businesses and people to pay for UK public sector services. Outbound payments allow government and local authorities to make payments to businesses and people. Pay will not be offering outbound payment types as the approach required is vastly different from inbound payments and the public sector has other existing mechanisms to manage outbound payments.
Direct Debit was not originally designed with digital payments in mind. This makes it difficult for Pay to integrate with and offer Direct Debit to users. Instead, we’re prioritising other types of recurring payment (like recurring card payments) so we can still offer ways for our users to make repeat payments while limiting our technical overheads.
We’re prioritising the mobile wallet payment types that have the lowest fees for our services, while still meeting the needs of our paying users (Apple Pay and Google Pay wallets). PayPal is not a mobile wallet payment that we plan to offer in the immediate future.
We’re using the 6 strategic objectives in our product strategy to drive decisions about our product roadmap and to prioritise our backlogs. We’ll be working towards these objectives over the next few years.
Watch this space to see how we iterate on GOV.UK Pay, achieve our goals and find out more.
Core to GDS's mission for GOV.UK One Login is our commitment to make sure as many people as possible can easily prove their identity to access government services.
We are therefore excited to announce that we are now working with the Post Office to run an in-person identity check in their branches, for people who need additional support to use GOV.UK One Login.
The in-person service has been created to assist people who want to use GOV.UK One Login, but are unable to use the app or browser journey for identity verification. We’ve designed this route specifically for users without smartphones, or those who have a low level of confidence in using a digital platform to input their document details. Offering an in-person service allows for a wider range of people to access vital public services online. Once having proved their identity people will, in the future, be able to reuse this to access services across government.
The service is currently in private beta which means that together with the Post Office we are testing the route and making improvements. Once these changes have been made and tested, the service will be fully available to the public.
A user accessing the in-person service to help them prove their identity will go through the following steps:
We’re aware this process does begin and end online, which may not work for everyone. However, for those who lack confidence or don’t have a smartphone, this in-person option may offer all the help they need to prove their identity with GOV.UK One Login.
The in-person identity checking also allows people to make use of a wider range of identity documents, beyond driving licences, passports and biometric residence permits. This grows the number of people who can prove their identity using GOV.UK One Login.
There are many benefits to partnering with the Post Office on this service. The Post Office is a well known institution and many people in the UK use their services regularly. They have a selection of branches offering in-person verification already in place for other government and non-government services. Most people in the UK are within 10 miles of a branch that is offering this new in-person identity check for GOV.UK One Login.
Postmasters are trusted and often well-known figures in their local community. They can support those individuals who are unable to use the app or browser journey for verification through the in-person service.
Once initiated online using the above steps, during the visit to the Post Office staff will be happy to help with the identity verification process.
We are continuing to build out our offering so as many people as possible can access our government services using GOV.UK One Login. Which is why we are currently procuring a service where people can get support over the phone or by email when using the GOV.UK One Login service.
If you’re interested in finding out more about GOV.UK One Login read our latest update blog: GOV.UK One Login: June 2023 update.