Blog post: From Word to a form builder - how we turned more than 150 Word forms into digital forms

Heledd Quaeck, Phil Rookyard and Samantha Evans share an overview of how the Digital Team has turned more than 150 Word forms into digital forms.

In 2019, we had 184 Word and PDF application forms on our website. Whether someone needed to apply for something, change something, get advice, or send us information, their experience would be the same: find the form, download it, save it, complete it and either send it by post or email it, then wait for a reply. Sometimes they had to complete four separate forms for one task, such as applying for a waste permit.

The problems

Accessibility

None of the Word forms were accessible. Our team wanted everyone who needed to use our services to be able to do so. As a public sector body, we must do this under the Public Sector Bodies Accessibility Regulations 2018 (PSBAR).

Welsh and English

Many forms were available in English only. We wanted to make sure Welsh speakers could complete a Welsh language form if they wanted to. We must do this under the Welsh Language Act.

Findability

The Word forms were difficult to find on our website. This was partly a problem of content and information architecture (designed around NRW’s needs, instead of users). But, also, because forms were attached to the bottom of the page in ‘related documents’.  

They often had names that worked for the organisation but not for users, like 'application form Part A'. Our team wanted to change that.

Lack of version control

Version control was a problem. When NRW updated a form and attached a new copy to a page, this did not prevent regular users from reusing a copy they had saved on their desktop. This meant they often sent teams the ‘wrong’ application. This resulted in administrative burden and delays for teams and applicants.

Usability

People also found Word forms difficult - sometimes impossible - to use.

The organisation had tried to address this by giving users instructions on how to use the paper forms.

People simply expected more from us as an organisation, as one user exclaimed in on-page feedback 'Word forms?!'.

How we began

Support from the organisation

Through the organisation's board structure, we raised the issue of non-compliance with PSBAR. This gave us the organisation’s backing to start work on making our forms accessible, albeit as a time-bound piece of work.

We were allocated policy and technical staff for a time, to ensure the forms remained factually accurate, and gaining three extra staff in our team to help us.

We hoped that through this process, we would also be able to make the forms better.

Choosing a form builder

We’d already ruled out paying £750 to create just one 'accessible PDF form' - as well as being cost prohibitive, we knew it wouldn’t solve all users’ problems.

We explored what tools were available for us to easily create accessible and secure forms. This was before GOV.UK had stated to tackle its long tail of PDFs by creating a form builder.

We ruled out:

Umbraco forms – despite being integrated with our CMS, was only suitable (at the time) for smaller, enquiry or feedback forms

another third-party form builder, which claimed to be accessible - but would take months to get through security approvals

Making the most of the tools we have

We noticed some government agencies using SmartSurvey as a form builder. It was something we’d already had approval for surveys and was one of the most GDPR and Cyber essentials-approved survey software out there.

Importantly, the software:

has page and question logic so we can design forms that routed users through a path, meaning they don't see questions irrelevant to them
can be bilingual (Welsh and English)
is accessible
allows us to use a variety of question types: multiple choice, text answers, file upload
can be branded so that users don't feel interrupted when they move from it to our website
allows users to save their progress and return to it later
can be printed for completion, or as a completed form
allows us to set mandatory questions
allows us to use merge codes to pull data previously entered (useful for ‘check your answers’ type pages and email triggers)

Now we had a form builder, we could get started on our journey of transferring forms from word and PDFs, into more accessible and usable web forms.

Auditing all Word or PDF forms on our website

We audited the site, compiling a list of all forms in PDF or Word. There was no easy way to do this as the documents weren’t saved in one ‘forms’ place in the media library, so we worked through each page of our website. On our spreadsheet we included:

type of document (Excel or Word)
link to document in our CMS
service: purpose of the form, from the perspective of the user (many forms were called internal names)
content designer responsible for each form
number of downloads in year – to help us prioritise the work

Prioritising work

The digital team met regularly to discuss:

the complexity of each form
what content work we would need to do around it
how realistic we felt it was to try to digitise and improve at the same time

We shared the work amongst ourselves by the business area we were each most familiar with. 

Working with the organisation

We worked with subject experts, sharing mock-ups until we were satisfied we had done at least enough for users to provide the information we needed, and to understand what would happen for them next. 

Where we were able to, we made improvements to forms and content. For example, we worked with the flood permit team to merge several application forms into one so people could more easily apply for a permit.

Some teams were reluctant to explore changes to form content or structure because their forms had been signed off by a committee or board. In these cases, we created a digital form that closely matched the layout of the paper form. We intended to go back to these to improve them, and as we learned more about how users were using them.

Moving to more user-centred design

As knowledge of the purpose of our roles in digital has grown, there has been more openness to working in a user-centred way. We’ve been able to focus on some design work, doing what we know works best for users and aiming to improve the customer journey wider than just the form.

This has included delivery of forms and content based on user research for people wanting to:

With only one user researcher in our organisation, it’s not possible to do in-depth user research for every form. Instead, we use colleagues’ subject knowledge, desk research and digital best practice, to design and iterate with feedback from users, for example:

What we’ve delivered

We’ve now created 116 digital forms, removing around 150 Word forms from the website. 

The forms are:

available to users in both Welsh and English
usable on any device
WCAG 2.2 compliant
easier to find, with titles that make sense to the user

Users are linked to a confirmation page at the end of their form. They also receive a confirmation email so they better understand what happens next.

We have not digitised some forms due to their complexity and low volume of transactions.

What hasn’t work so well

Due to workload demands on our team, it's been difficult to revisit many of the forms that we knew needed more work. Coupled with this, it's sometimes been hard to get time with subject matter experts outside of the early ‘time-bound’ accessibility work. The role of a digital team is still not that well understood, so we’re often navigating tricky conversations around who is responsible for what.

What we learned in the process

99% of the time you cannot lift and shift a form designed for paper or a PDF.
Most forms are designed around business process and ways of working which could be simplified and streamlined.
(Almost) no form is an island. They are part of a service, along with supporting content that also needs to be redesigned, linked together or often deleted.
It takes time and energy for our team to explain what we’re doing and why.
Even the simplest form takes a lot of thinking and design time to work out the logic, order and need for questions.
It took a lot of trial and error to see what logic and features were available to handle the different questions, especially with some of our very complex forms.
We can have fewer digital forms than paper forms, as shared in our previous blog post how turning six long forms into one helps our users
Having a form builder that our content designers can design, test and iterate without depending on a developer is essential with the volume of content we have across our services.
Pair writing or trio writing with colleagues in our translation team helps improve the usability of both languages – we'd love to do more.
We need more content design specialists to keep iterating forms as, previously, changes to the paper/word forms would be done by someone else (or no one).
We took on too much in starting to review so many forms at the same time, but we’d already started to drum up support and had a limited time to do the ‘accessibility work’.
As a small team, context switching from waste, to bats, to flood to tree felling and - many other things in between - takes its toll. But, on the flip side, it has helps us identify common patterns across services and find ways to standardise and improve our approach.
Without the regulatory stick of the PSBAR we would not have made a fraction of the progress we have made.

Next steps

The early accessibility work helped us talk more about users and their needs. We made relationships with teams across NRW which we have been able to build on. There are more colleagues that have been on service design and agile training, which is helping.

NRW now has a permit reform group which identifies areas for improvement. We are working closely with them to improve online services, starting with species licensing.

In the Digital Team, we’re focusing on standardising form and content patterns. We need a common way of asking for address, for example, or a standard approach to using start pages. We are working towards consistency of user experience across services.

We are also exploring components like GOV.UK Notify and GOV.UK Pay. We’ve experimented with tying these into several form journeys and have demonstrated what’s possible in show and tells.

A big and positive change for us is starting to work more closely with colleagues in IT, data and GIS colleagues to start exploring how we can better integrate data between platforms. We’re open to exploring whether we stick with Smart Survey long term, or other options which allow us to easily create and manage forms.

Over the next year, we hope we’ll be able to look at one service end to end, which may help change and influence what platforms and components we need to manage services in future.