Improving a lengthy form

A service designer in my work recently reached out to the content community. They had recently began a new piece of work which involved taking a very outdated PDF form, and drastically improving it.

They lacked a content designer on the project, and therefore wanted to find out what we would do in this scenario. They assumed a content audit would be required.

After I took a look at the form, I knew that a review of all data fields was needed first.

Understand where the information goes

If I was tackling this piece of work, initially I’d ask the Subject Matter Expert (SME) some questions about integrated systems.

  • Does the information collected in this service, go to another system?
  • How does this service interact with other systems?
  • What are the fields used in the other systems?

Answers to these questions may limit what can be changed in the service.

Review what’s being asked

Next I’d find out what information we absolutely need to collect, to make the service work. We should only capture the information we need the answer to.

What questions do users struggle to answer? Is it because they don’t know what the answer is, or they don’t know what the question means? It may help the user to:

  • give them answers to choose from
  • provide guidance on where to find this information
  • restructure the question

I would only show a user the questions that they need to see (avoid ‘if yes, then’). This reduces cognitive burden and time spent on the service, improving the user experience.

Locate any related content

I would find out if the service has a related website, FAQ, or other content. I would plan for any content changes on these platforms, for consistency.

This is when I’d complete a content audit, to gain scope on all related content. It can also help improve Search Engine Optimisation (SEO).

Assess the language used

Does the client have an established service manual? If not, I’d create the content in line with GDS patterns. This is the gold standard for designing inclusive, accessible services.

Who are the users of this form and what sort of wording do they use to communicate? Even experts in their field prefer simple language.

I would avoid language like ‘shown above’ or ‘shown below’. This does not make sense for someone with a visual impairment, using assistive technology.

GOV.UK aims for a reading age of 9-11 years old. So, I’d write using short words, and short sentences. This also makes content easier to understand for people who do not have English as their first language.

Review accessibility

PDFs are not accessible (for screen reader users, for example).

HTML is the most accessible and inclusive platform for content. It also ensures the content is easy to keep up to date, as it’s one source of truth.

Why GOV.UK content should be published in HTML and not PDF

To make the service as inclusive as possible, I’d prioritise also having a paper copy of this form. This means those who are perhaps not digitally literate, can still provide the information they need to. But I’d keep it very simple and easy to use.

Test the content

And finally, I’d test, test, test, test. As much as I can.

I’d test with participants that require assistive technology. I’d test with participants who do not have English as their first language.

I would test with the minimum volume of content first. And build on the content from there, to meet user needs identified from research.

I presented these steps to my colleague that needed advice, to help them improve the inclusivity and accessibility of this form.

Leave a comment

Your email address will not be published. Required fields are marked *