Designing the new HMRC mobile experience
The problem
The UK has some of the most complex tax rules in the world.
One of the main issues for taxpayers is knowing when they need to do something and what they need to do.
Long waiting times in the phone lines when they face an issue, it’s also a problem.
A group of heavy Government services users (people on benefits, childcare support or other services such as Help to Save) for who continually checking the website is time-consuming.
The project
As part of the digital transformation, HMRC decided to update its app. At the time, it was just a tax calculator for Pay As You Earn (PAYE) users.
- They removed the tax calculator completely, so existing users were outraged.
- The design wasn’t consistent with the Government Design System (GDS).
- The navigation lacked scalability, a problem if you want to support a growing environment of Government services.
- There was no comprehensive research, design, and testing process, so the team didn’t collect any user feedback before the releases.
- Because of the lack of input during the design stages, the team spent a lot of time fighting fires after each release, with internal stakeholders, users, etc. With all the time and the stress for the team members that are involved.
My Role
I joined the team in October 2016 and worked with them for three months. During that time, I focused on:
- Setting up a more User Centred Design (UCD) approach.
- Understand the user needs and how the app could help them.
- Improve the app’s scalability and navigation.
- Create a design language for the app consistent with existing GDS for web services.
- Streamline the team processes from the ideation stage to the handover to the development teams.
Getting the users input
Using the feedback from the app stores
When I joined the team, they had already released the first version of the app without usability testing.
The lack of testing caused negative feedback in the Apple and Google stores and pressure from internal stakeholders.
I collected a random sample of the comments in both places and, using affinity walls, categorised them with help from some team members.
We concluded that the main pain point for our users was the removal of the tax calculator functionality that existed previously.
Most users didn’t want to use other apps because they didn’t trust the outcomes as much as one backed by HM Revenue & Customs.
After the success of this approach, the team agreed to do it regularly after each major release.
Testing in a fast development environment and no users
I found a reactive environment more than a proactive one.
The team was continually working on fixing problems with past releases, and the scope for the next one was in a constant state of flux.
It wasn’t easy to plan research and recruit users in that environment as I never knew what I would test next week.
Instead of a time-consuming planning and recruitment approach, I decided to book one day a week to go out to town and do some guerrilla testing of whatever we were working on at the time, aiming to get at least three users every week.
I discussed with the team and the stakeholders what we wanted to get from each research round during the week and created a high-level discussion guide.
Card sorting to improve the scalability and navigation
I needed to get a better understanding of what existed in the app at the time. For that purpose, I extracted all the pieces of content in the app into a spreadsheet.
After having the content inventory, I created 50–60 cards and ran five card sorting sessions with users working in pairs.
With the outcome of these sessions, I created a cluster tree that helped me make it more intuitive and easy to navigate the app.
Consistency in a multi-channel environment
HM Revenue & Customs app was the first one of it’s kind. As part of the work required, there was a need for a new design language.
The main complaint from the internal stakeholders was about its inconsistency with the rest of the Government services.
The problem with it was that the Government Design System was meant for web apps, not mobile ones, and demanded a new approach.
Working with the developers for the different platforms (OSX, Android and Windows), we defined a structure for the essential elements of the new design system for mobile apps.
I also created an assets library inspired by the Government Design System in Sketch to help other designers create consistent services in the future.
I updated the assets library regularly with the feedback collected from users in the guerrilla testing.
Making life easier for users
After I did all the foundational work, it became time to get hands-on with the new app to help users understand when and how they needed to interact with HM Revenue & Customs.
We worked with other teams who had researched the type of heavy users we aimed for and created a calendar of life events.
We run formative research with users to review and update the map and understand the main problems when dealing with their taxes or benefits.
The main problems were:
- Users in Tax Free Childcare needed to know when to top up their account and allocate payments to their childcare providers.
- Users didn’t want to enter data that was already known to HM Revenue & Customs.
- Users needed to know their current tax code when switching jobs (the tax code could change from time to time, and a wrong one involved they got taxed more).
- Users didn’t want to call the phone lines for help because of the waiting times and the difficulty to get through to the right person.
- Users needed to know in advance when they needed to interact with HM Revenue & Customs (Such as pay a tax, update their details for a benefit) so they didn’t get fined.
- Most users on benefits didn’t own a desktop or even a tablet, so all this needed to be done quickly using a mobile phone.
With this feedback in mind, I created a low fidelity proof of concept to give our stakeholders a glimpse of our approach and be sure that the team was aligned with their view.
Then, I prototyped some ideas and did some guerrilla testing to get users feedback.
The timeline functionality, where users were notified about: things they currently needed to do, things they would need to do soon and a historical of the latest interactions with HM Revenue & Customs was welcome by all of them.
The idea of reusing the existing tax submissions and benefits claims and the information hold by HM Revenue & Customs to pre-populate future ones also was viewed as a great time-saver as in a lot of cases most of the information rarely changed between periods.
But probably the most welcome idea was the messaging service inside the app, as it would avoid users having to wait on the phonelines or keeping their web browser window open while they waited for the customer service staff to respond.
I also started working on the possibility of allowing users in Tax Credits to move to it’s replacement, Universal Credits and starting doing some research with users around their experience doing it
By then, seeing that the project was on track again, the client asked me to move to another service that was struggling.
