GOV.UK Forms and the State of Government as a Platform

GOV.UK Forms is great

Recently, I’ve been very happy to see the development of GOV.UK Forms, particularly this recent show-and-tell style video, the related blog post and this section of the latest Services Week video (more on that to come).

One day, I will get around to blogging about the significant decrease in online show-and-tells and blog posts since the early days of GDS, but not today. Suffice to say, I was very impressed by all of the above, both in terms of transparency and content, but I wish there was much more of it from every government organisation.

Forms is a GDS platform to enable any service in central government (for now) to very quickly and easily set up an online form, in a manner similar to Google Forms. It’s currently in Public Beta. Civil servants can create forms for their services with no technical knowledge required. Its initial key purpose is to replace the vast number of download-and-fill-in PDF and Word forms that are still on GOV.UK. These smaller services are the long tail of digital transformation that are very unlikely to have a specific digital team assigned to work on them.

As you would expect, it is iteratively delivered using a significant amount of user-research from both the citizens who would fill in the forms and government users who would use the platform to create forms for their service.

It uses the GOV.UK Design System and is based on the Government Design Principles, such as “One thing per page” as explained in another great blog post from the team. It’s highly focused on accessibility, in the same manner as is described for GOV.UK One Login in this part of the services week video (you should watch the whole thing). It currently supports some limited form routing capabilities and more are planned.

It has a nice forthcoming features list, including integration with GOV.UK Pay, the ability to attach files to form submissions and form versioning.

GOV.UK Forms limitations

At the moment, Forms can only send the results of a user completing a form to a nominated email address. This isn’t a limitation of the Forms system, more a reflection of how difficult it is for data generated by one part of government to be able to get to the systems owned by another.

The UK Public Sector API list is still being updated, but the recent submissions are almost all from the CDDO and the overall list of APIs looks very similar to when I last checked it a year ago. In the Services Week video, many people in the live chat were asking about API submissions but “the ability to receive form submissions in formats other than in the body of an email” remains “further in the future” on the roadmap.

Some questions for the GOV.UK Forms team

I have a few questions I’d like to ask the Forms team. To begin with, it’s just a small thing, but the forthcoming features list on GOV.UK I linked to above doesn’t seem to match the slide they showed on the Services Week video.

I suspect this is just a case of them needing to update their team’s web page.

I’d love to know which organisations, services and individual forms are hosted on Forms. The team obviously already has that data, so creating a public dashboard would be fairly trivial.

I’m very interested in what metrics Forms is providing for its users. Back in the days of the Performance Platform, I’d have expected some public transparency about this data, but today I’m just curious to know what’s being provided to teams that use it. I see there being two types of information that could be provided. There’s the basic data, such as how many citizens have completed the form, but if I was a civil service user of Forms, I’d be much more interested in a Google Analytics-level of data, such as the drop-out rate per question or time-on-page, as that sort of information could really help me improve the form’s design.

The future of GOV.UK Forms

In the Services Week video, a number of people were asking about the use of Forms for local government. I don’t believe there are any plans for this at the moment, which is a great pity as it’s something that could greatly benefit the huge numbers of local authorities that are either significantly economically precarious, and so can’t afford further digital transformation, or simply the ones too small to have technical teams capable of supporting it. I’d like to think that providing this functionality for local government could, in time, lead to the kind of multi-organisational centralised local government services I was advocating for in my previous blog post.

Like many people, I was very impressed by Tim’s amazing twitter post showing the automated conversion of an existing document-based form into a Forms version. This is great and may prove a huge time saver for some teams. However, it cannot be overstated that a form is not a service. One of the most important things I’ve not heard discussed so far, as part of the development of Forms, is the creation and nurturing of a cross-gov form design community — probably as a subset of the Service Design community.

I would love to see a feature where a form could be created and then comments could be added by other users of Forms before it goes live, in a manner similar to the “2i” process used for GOV.UK. An optional request for feedback could automatically be shared in the #design channel on the cross-gov Slack. I would hope that this kind of feature would somewhat reduce the “fire and forget” wholesale copying of existing document-based forms to digital equivalents without any effort taken to reassess their current suitability

Forms should strongly consider the guidance for form design on GOV.UK and, in particular, “Know why you’re asking every question”. It would be very interesting to see how much push-back and impact to Forms take-up there would be if a mandatory non-displayed field was added to every new question a civil service user creates in Forms, asking them the reason why it’s there.

I don’t see anything on the roadmap related to supporting A/B testing. If versioning will soon be supported, it doesn’t feel like too much of an extension to be able to offer different versions to different numbers of users, to be able to compare submission rates, data accuracy, etc.

If/when Forms is tied into GOV.UK One Login, I’m sure it would be very useful for some users to be able to optionally save their form entries so that, when they need to fill in the same form again, they can do it instantly, if there are no changes, or still very quickly if only minor editing is needed.

This one may already be there and I missed it, but I think it would be very useful to have a “feedback on this form” link on every form and possibly even on every individual question. It would be an interesting discussion as to whether such feedback would just go to the form owners or be shared into the kind of cross-gov form design community I suggested above, so people with similar forms could benefit from the comments. The major issue with the latter is the number of users who, despite warnings, might enter personal data into feedback.

As more document-based forms are moved into Forms, the team will start to be able to see a small subsection of the number of times the government asks citizens for the same information over and over again. It would be very interesting to see just how many times citizens are asked for name, age, address, National Insurance number, etc, to feed into discussions around how data is collected, shared and used.

I’d like to be able to say that it would also be excellent if the use of Forms would lead to increased standardisation by offering the user creating the form templates for often repeated questions like “title”, “ethnicity” or “gender” (in many cases, these shouldn’t be being asked anyway — one more reason for the feedback process above). Unfortunately, I suspect that these will need to be different for some time as they will need to be fed into a large number of legacy systems that may each have their own versions of allowable answers.

So, is it all good news?

Yes and no. I’m very impressed by the diligent work that’s gone into Forms and hope to see some usage statistics in the near future. However, this isn’t GDS’s first attempt at a “forms tool”. Via this old FOI request, we can see that the GDS Submit project was being worked on all the way back in 2017. I’d love to know how much of the work from that, in particular the user research, has been carried over into Forms.

The time it’s taken to produce this kind of cross-govt solution — bearing in mind that GDS was created 13 years ago — is yet another example of how difficult it continues to be to produce genuine Government as a Platform (GaaP) digital platforms vs. individual departments duplicating expenditure to build the same thing.

In this case, we can be very specific as, very shortly after seeing all the good news about Forms in the Services Week video, this blog post about DEFRA Forms turned up in my feed.

The concept of GaaP goes back a long way. Tim O’Reilly coined the phrase back in 2010. The perpetually excellent Gubbins of Government video from Mark Foden was made in 2013. I personally worked in the GDS GaaP management team in 2016. Since then, GOV.UK itself, GOV.UK Pay and GOV.UK Notify have been shining examples of what cross-gov shared digital components can look like.

I also continue to be impressed by what I’ve seen of GOV.UK One Login and hope it lives up to its great potential. I’m particularly keen to see it take on the oft-failed task of providing a single login for civil servants, as well as having a really good go at codifying the often overlooked, often nebulous, yet critically important role of delegated authority.

What’s the problem then?

This is where people who’ve read my blog posts or been unable to escape a pub conversation with me may start to feel a sense of deja vu.

I sketched the following diagram in July 2013, a couple of months after I joined GDS.

It outlines a single cross-gov digital delivery platform with a number of what would eventually become GDS GaaP platforms, such as UX (Forms), payment (Pay), notifications (Notify), identity (One Login). It also includes two platforms that used to exist but have been cancelled, namely performance (Performance Platform) and static data (Registers). I also threw in a single common casework platform where everything related to an identified citizen could be tracked (controlled by citizen-provided access permissions with access to specific data naturally limited to public service users with the required permissions).

Actually, I fibbed back there about the “data” part — it was probably more than just Register. It probably related to storing, with citizen permission, common pieces of data that we frequently reused, such as their address. I’m planning to write more about that kind of thing in a separate blog post.

The main takeaway, though, is that the concept was a single platform not just used by, but contributed to by engineer teams all across government. If you look at the box on the left, that represents non-GDS organisations as the owners and guardians of the data they have responsibility for, but the transactions are carried out on a single platform.

This has multiple advantages but two massive ones in particular. Firstly, the huge reduction in duplicate spending in organisations all across government on building and maintaining essentially the same kinds of digital infrastructure for access to their services. Not only would individual departments need to spend less, but the work they did do could contribute to something that could be reused by a large number of other organisations. Secondly, it would allow the creation of services that are based around the desires of the user, rather than the constraints of the responsibilities of the individual departments.

It’s time again to show Tom Loosemoore’s related video from the 2015 Code for America Summit.

Tom shows an example of starting a business where, in a single service, the user can provide all the data needed to satisfy the behind-the-scenes existing services that may belong to a variety of different organisations. As we used to say at GDS, “Citizens shouldn’t have to know how the government is structured to achieve the outcome they want.”

Because forms added to Forms are currently created by separate individual departmental teams, there’s no incentive to move away from services that align to their current structures to ones that genuinely reflect cross-organisational user needs to deliver the whole outcome the citizen user wants.

How did we get here?

Back in 2012, the trifecta of Liam Maxwell (Government CTO), Mike Bracken (Head of GDS) and especially Francis Maude (Minister for the Cabinet Office) had significant authority over how digital delivery could be undertaken in government. The creation of GOV.UK from the over 1,500 previous government websites that existed at that time was an example of some of the excellent work that was delivered, along with Digital Spend Controls (alas, not as strictly followed these days) and the Service Standard.

So, what do I wish had been done differently? Two major things stand out, both of which were, I believe, choices made by GDS itself, rather than being imposed on it.

The first is the focus on only delivering one-shot transactional services. The policy was that almost all digital services had to treat the user as if they were interacting with government for the first time. Common fields like name and address had to be filled in over and over again and there was little or no discussion about data sharing between services, never mind organisations. As I mentioned above, I’m planning to do a separate post with some thoughts on the government’s attitudes to data, so I’ll park this one here.

The second is misunderstanding what open source means. Point 12 of the Service Standard still says “Make new source code open”. What this has meant in practice is that the majority of code developed since 2012, either by engineers working directly for government or by contracted vendors developing digital services, has been published openly on github. This is a good thing, but the reality is that a vanishingly small amount of that code has ever been reused to deliver another service. What GDS has never done is foster an open source community, encouraging contributions for their platforms from other government teams or even outside of government.

Enormously complex products, such as Linux, are worked on simultaneously by contributors from dozens of different, often competing, organisations. They all work together to produce something that is far superior to anything they could have produced individually and save huge amounts of money by not duplicating effort.

Unfortunately, in government, apart from a small number of common services, such as Pay and Notify, we’re still in the model of every organisation doing its own thing, rather than seeing the incentives of working together — or even being able to. To my knowledge, GDS has never solicited external code contributions and certainly has never paid anyone to encourage or coordinate them.

So, what could be done?

Like any meaningful change to the government status quo, it’s very hard to overcome the sunk cost fallacy. Lord Maude has said recently that the Treasury is still highly reluctant to support services that span multiple organisations. Departmental digital leads are extraordinarily risk averse to data sharing or allowing API access to systems inside their firewalls. And, sadly, there just isn’t a culture in government at the moment for technology people to work together on products in the same way as there has grown to be in fields like service design.

If there was a willingness to move in the direction I think makes the most sense, I would follow these stages.

Work on opening up GOV.UK Forms. Speak to community managers at highly successful open source products, such as Linux, React or VSCode, about how they encourage and process external contributions. Encourage teams outside of GDS to take ownership of specific roadmap features to help deliver more functionality faster.

Commit to someone’s time, and therefore budget, being spent specifically on fostering the cross-gov technical community. I’ve had little sight of this since I left government but last time I discussed it with anyone, it was underdeveloped compared to other cross-gov communities ,such as service designers. Hold regular online and in-person technical meet-ups to discuss common problems and solutions, new technology and generally encourage the feeling of a community working together to solve goals across organisational boundaries.

Update the section in the Service Manual about teams that deliver the digital part of a service to add another option (rather than just change the existing list of roles). It’s frankly ridiculous that we still have front-end developers in almost every digital delivery team in 2024 implementing the same kinds of UX widgets from the Design System to collect the same kinds of data over and over again. Government should look at Team Topologies and try removing engineers from product specific digital delivery teams completely by factoring them out into platform delivery teams that work to collaboratively produce things like Forms.

Focus on AI. Partly because it’s the exciting thing du jour, and therefore more likely to get attention from senior managers, but also because there’s likely a lot of things AI can do in this space. For example, it would be very interesting to see if AI could look at the forms on Forms that are completed most quickly / accurately and use their design to provide suggestions to update forms that aren’t doing so well. AI may also be able to look at the information that’s being submitted and, from it, parse whether there are other government services that the user could or should be notifying of their circumstances and show them related information on how to do so.

Alternatively (or additionally) to displaying related information to citizen users, I would love to see Forms expanded one day to automatically (with the user’s permission) notify interested services in changes of circumstances. These would likely be based around “life events” such as getting married, having a child or moving home. Individual services would be able to register their interest in only the events that are relevant to them. This old GOV.UK roadmap post describes life events in detail. I strongly believe that, implemented well, this could have a colossal positive change in the way citizens interact with government.

Once at least some of the above are implemented, likely over several years, it’s time to think about scaling. The best way to approach this is by persuasion to begin with, rather than mandate. Hopefully, the ideas suggested above will produce enough high quality evidence to persuade decision makers and budget holders of the value of working together across organisations. However, there are other things that could also be done.

I would definitely advocate a full NAO investigation into the amount of money that could be saved by significantly cutting down the massive duplication across government of technical infrastructure, yes — also staff, but mainly the requirement of endless outsourced contracts to bring in technical teams. There’s also the possibility of calculating the huge efficiency savings made possible by enabling services to automatically respond to life event triggers, rather than having to rely on citizens speaking separately to them.

Such a report could also look into the potential savings of reducing data-entry mistakes by citizen users by better data sharing but, again, I’m planning to touch on that in my next post.

After there is a broad coalition of support, it’s time to update the Service Standard and Digital Spend Controls. Services should eventually have to justify why they are using their own front-end designers, rather than using Forms. Vendors that want to supply digital services to government need to be forced to stop paying lip-service to providing APIs, both to access the data held and drive the functionality of their systems, and be refused contracts without them.

Even if all this utopian thinking was implemented, this obviously still isn’t a panacea. As I said in my previous post, in the context of central government offering shared digital services for local authorities, having any system that draws things together into one place presents an enormously tempting platform for both denial and data theft cyber-attacks. However, we already have a large number of very skilled cyber security professionals in government as we currently need to have them duplicated in every organisation running their own digital delivery platforms. I’m sure some of them could be re-tasked to support any expansion of Forms.

The main thing to remember is that this, by necessity, has to be a slow transition. At the recent Public Digital panel on digital health records, someone said that one of the biggest issues to implementing successful digital transformation to government here in the UK is because we tend to be early adopters. We’re hamstrung by the legacy systems we bought in the 80s and I’d argue we’re now also hamstrung by the decisions made around web-based services for citizens made 12 years ago.

Such things can be overcome over time but almost certainly by persuasion, rather than by edict. Making GOV.UK Forms a massive success is the first priority — ideally by involving as many people outside of GDS as possible. That, plus a financial assessment of the current situation, are the most likely ways to hopefully move decision makers in what I personally believe is the best direction.