Improving GOV.UK Publishing

We’ve been working with the Government Digital Service to improve their publishing service

GOV.UK is the official website for UK government information and services. It provides a single, trustworthy place to go for services like tax, passports, and driving licenses. Replacing separate departmental websites when it was launched in 2012, it makes life easier for people using public services.

The GOV.UK Publishing Service is the mechanism by which content reaches the GOV.UK website from across government. It’s used by content designers in the central GOV.UK team and individual government departments, to get information live. Together, several thousand civil servants manage GOV.UK content.

The platform has multiple publishing applications that feed content through a publishing pipeline to the GOV.UK site, which itself consists of a number of front-end applications. dxw is working with the Government Digital Service (GDS) to iterate the service – to make it more efficient, less prone to data issues and enable it to support more channels (not just the website).

Here’s a couple of things we’re helping with.

Modernising the data flow: the Publishing API

The Publishing API is the central “brain” of the platform. It receives content from the publishing applications and prepares it for the front-end applications that render different types of content.

From a content store to on-the-fly generation

GDS is moving away from using a content store that holds pre-packaged content ahead of publishing, to a system where content is generated “on-the-fly” at the time the request is made. The aim is to resolve current data synchronization issues and reduce the need for corrective work in the background. 

One of the main causes of data issues in the system is making sure linked content is up-to-date. GOV.UK pages often display information from other pages via ‘links’. For example, the ministers page uses links to get the names of ministers, their roles, their images, and the departments they belong to, all of which come from other GOV.UK pages.  Any changes to the source or linked content means all the related items need updating. 

The move to on-the-fly content generation means the processes via which this is done – link expansion and dependency resolution – will all happen at request time.

Supporting multi-channel use

While the content store is focused on feeding the website, the new approach is designed to support smaller blocks of data that can meet the needs of different channels like mobile applications, chatbots, and future AI chat functionality (as and when that happens).

This multi-channel support is enabled through GraphQL, which allows more flexible data queries. Users can select specific data fields and retrieve just the information they need, rather than receiving a single, large data block intended for a webpage.

Content block manager 

Centralising shared bits of content

At the moment, updating facts on GOV.UK that exist in multiple places –  like pension or tax rates – is a time consuming process. Every page update requires a publishing process, including peer review and fact-checking by subject matter experts.

Work is underway to build and test a “content block manager” which acts as a central store of these facts that can be embedded on different pages. Doing this means an update can be made once then filter out across the GOV.UK estate, streamlining the process.

The application works by using reusable snippets of information. Each snippet has an embed code which content designers can insert into GOV.UK pages. When a page is published, the embed code is replaced with the current value. If the value changes, the system finds all pages using that block, updates the value and republishes them automatically.

When someone updates a block, they can:

This approach has already been trialled for basic state pension data. It took 7 minutes to update 4 pages, something that would have taken about 40 minutes in the past. A time saving of over 80%.

Adding structure and scale

We’re currently exploring other fact types, starting with contact details and tax. In future, as with the Publishing API, the same content blocks could be used to update multiple government channels.

The team is now also working with information architecture colleagues to add more structure and meaning to the content blocks. For example, defining a tax rate not just as a percentage, but with an associated threshold and name as well.