Digital transformation in HMRC
For nearly 4 years, I was the sole content specialist in a large user-centred design team. We were tasked by the Valuation Office Agency (VOA) – a subsidiary of HMRC – to digitise a suite of paper and PDF forms that had barely changed in over 30 years. (View a PDF version in a new window.)
I loved this project. It showed how a team of consultants and client staff could grow together, learn from each other, and create a highly regarded service that outperformed the well-established mechanism it replaces.
What the VOA is, and what it does
The VOA is a branch of HMRC. They provide local authorities in England and Wales with valuations for all their non-domestic properties. This is how business rates are calculated.
All non-domestic properties are divided into 36 categories of use. Every 3 years, the VOA issues every non-domestic property with a form of return (FOR) corresponding to its category of use. FORs ask for information about the business or organisation operating from a non-domestic property, including their trading receipts, and details of how they use the property.
About the project
The client initially wanted to develop digital versions of all 36 categories of FOR. However, given the complexity of the project, we concentrated our focus on the 10 most-used forms.
My team took the project through the discovery, alpha, and private beta phases of the Government Digital Service (GDS) agile delivery system.
The users
The journeys we designed were for:
-
publicans, restaurateurs and cafe operators
-
hoteliers
-
petrol station operators
-
campsite and caravan park operators
-
holiday-let and temporary self-catering accommodation operators
-
renewable energy generators
We also had a journey which covered smaller groups of niche organisations including, but not limited to, car parks, amusements arcades, safari parks and charitable trust destinations.
The team
The core user-centred design (UCD) team comprised:
-
me
-
interaction designer
-
service designer
-
2 user researchers
We also had a product owner, a scrum master, a project manager, a client subject-matter expert (SME), and an analytics lead.
During discovery and alpha we had 2 business analysts. And our team grew to include 4 developers and 2 testers once we started to build our first forms.
How I approached the task
I initially performed a content audit of the original forms, highlighting confusing terms, unclear instructions, and any questions we could potentially remove. I then compared my results with the user research conducted during discovery to add to the list of problematic content.
From there, I conducted language workshops with SMEs for each form to improve my understanding of the terminology. During these workshops, we were able to co-write alternative content and remove unnecessary questions.
Although the forms contained questions specific to each category of use, there were common questions across all the forms.
To make life simpler for the developers, I wanted reuse as much content as possible, and make the overall form structure broadly similar. So I divided each forms questions into 6 shared subgroups, and created a standard introductory section for all 10 forms.
The answers from the introductory section separate the users of any form into 2 distinct user groups. Then, the form surfaces questions relevant to the respective user group.
We also introduced qualifying questions within each user group's journey to further reduce the amount of questions they were asked. This improved the user experience by removing irrelevant questions and reducing the completion time. It also lowered the drop-out rate
The challenges
We encountered initial push-back from SMEs when we wanted to simplify the language and remove some of the content. However, after research proved many users failed to understand some of the jargon in the existing forms, the SMEs agreed test alternative content.
After early user testing, we found we had to create a new component as the GDS library could not accommodate our users' requirements. This was not a straightforward process and ensuring it was accessible required great teamwork from us, in collaboration with the HMRC accessibility team. See my GOV.UK case study for the full story.
Each standalone form is a large service, with some totalling over 100 screens. As we developed and tested one form at a time, any shared iterations we applied through findings in later testing had to be applied to earlier forms, where applicable. This required considerable attention to detail, an amenable interaction designer, and very understanding developers.
I also had to manage the translation of over 20,000 words into Welsh. This involved liaising with the HMRC Welsh translation team, the interaction designer, and the developers and testers. The service has not been tested in Welsh yet, but it is ready to do so during public beta.
The results
In private beta, each form comfortably beat the completion rate set by the control versions – the old paper or PDF forms. Users who tested earlier and later iterations remarked on how much easier the forms were to use. And we had successful submissions from people using adaptive software such as screen readers, magnifiers, and speech recognition software.
