We’re building a new interface for civil servants to publish content on GOV.UK. We aim to make it easier to create and manage useful content. You can learn more about why we’re doing this in our last post on data-informed publishing.

In January we launched Content Publisher as a beta with 4 partner teams at the Nuclear Decommissioning Authority, HM Land Registry, the Department for Work and Pensions and the Department of Health and Social Care. Our first publisher was the Land Registry’s Gavin Curry. He told us he’s delighted to be involved and is looking forward to seeing Content Publisher grow.

In March we also started working with the Competition and Markets Authority, the Ministry of Housing, Communities and Local Government, and Public Health England.

Our beta partners are using the new interface to publish news stories, and are providing us with feedback and data to help us expand and iterate. We’re adding features nearly every week. So far, our users seem happy and we’ve not had any nasty surprises yet.

Our approach

Content Publisher needs to be easy to support, iterate, and expand. Making it easy to iterate is also helping us test and improve it quickly.

To design the interactions, we’ve used the GOV.UK Design System. This gives us well-tested components to build up our interface. It’s a shortcut to wisdom. We have been feeding our results back and making improvements and additions to the Design System.

We’re using the GOV.UK prototyping toolkit to build working interfaces for early user research and to run design crits. This helps us check we’re on the right path.

Once features are built, we’re testing them with civil servants around the UK. We’re asking the users of our beta to provide feedback, and to complete a diary study about their experience. 

Within the team, we’ve also been running scenario test sessions. These involve the whole team roleplaying the workflows of a government content team. It helps everyone better understand our users’ needs, the work that takes place before and after our app is used, and the state of our product.

We’ve also made use of the GDS empathy lab. This lets our team simulate and experience a variety of different accessibility needs and assistive technologies. We’re reviewing our designs with an accessibility adviser and we’re doing research with publishers with accessibility needs. We’re committed to making sure Content Publisher works for everyone.

People using empathy lab accessibility tech

Trying out assistive technology in the empathy lab.

How we’re updating Content Publisher

The words in Content Publisher, the labels, hint text, and guidance, are managed through YML text files on GitHub. This makes it simple for content designers to update in-app publishing guidance with minimal developer time needed. It also helps us test and iterate quickly.

We have analytics in place to track user behaviour in Content Publisher. We’re using a tag manager tool to set this up. This lets our performance analyst expand and optimise our tracking, again with minimal developer time. This data helps us improve our interface designs. However, we respect our users’ privacy. All our tracking is anonymised, GDPR-compliant, and we support the ‘do not track’ option.

We’ve built the options to insert media blocks like videos or contact data in a way that allows us to easily expand the range of inserts. Each insert has a dedicated menu to help publishers with that type of content. This modular approach should help future teams add new features.

Letting users know what’s changing

We’re releasing a lot of updates to Content Publisher. When we deploy code, we hide the changes from users, and then reveal features when they’re complete and tested, and we’re ready to communicate them to our users.

A change note feed is built into the app so we can notify users about things which may affect their work. We need to make sure everyone who publishes knows about the latest features, guidance, or site design improvements.

Training users

To expand our beta test and eventually roll out Content Publisher, we’ll need to train users. We’re working with the Content Community to develop new online learning courses. This will make it easier to add users and for publishers to refresh their skills.

Computer screen showing GOV.UK writing course

Using data to make content better

Now we’re in beta, we’re getting plenty of feedback and data from our users in partner teams. It’s going well so we’re looking to expand our beta. We’re looking at which document types to support next, and how to involve more users.

We’re also starting to look at how we can make use of all the performance and quality data the Content Data team have pulled together. They’re building an interface to give publishers better access to all that data.

We want to provide publishers with the most useful information right in the editing interface where they can act upon it. We aim to help government react to problem content, and to continuously improve important content.

Try Content Publisher

If you work in government and you’re interested in working with us to help build the tools to help you publish good content, please get in touch: content-publisher-beta@digital.cabinet-office.gov.uk

We’re also going to be showing Content Publisher at ConCon8 on 2 May. If you’re lucky enough to be going, you can try it out and talk to some of our beta users.

Ben is a content designer on GOV.UK. You can follow him on Twitter.

Original source – Inside GOV.UK

Comments closed