Extending the HMRC and GOV.UK Design System for mobile apps
I joined the mobile app team at HMRC Digital in April 2018 as an interaction and product designer. Before joining, I didn’t even realise there was a mobile app. But I was aware of the great work, and awards won, creating the GOV.UK Design System designed to keep everything across government consistent. Except for the app, but that was about to change.
The main users of the HMRC app, use the app to check their personal tax and tax credit accounts. They can update details, spot and fix errors, without having to call HMRC contact centres. So ensuring clarity and consistency is important.
But, when I joined the team I learned the design and user experience of the mobile app was less standardised than the web. Knowing what design or interaction patterns to use was difficult because of the differences between GOV.UK and native mobile operating system patterns. In some cases, there were differences between individual app pages.
The GOV.UK Design System
The GOV.UK Design System and HMRC design patterns were designed to keep everything consistent across government. They were mobile responsive so we had those as a guide but they weren’t designed for native mobile.
We were looking to build a more native mobile app experience. To reduce noise and provide the same detail and functionality making it easier and quicker to update your information. The app was an opportunity to improve the user experience that responsiveness doesn’t always solve. It’s at this point we decided we needed to extend the GOV.UK Design System to accommodate the mobile app.
Getting in sync
Starting with some initial work the prior app team had done, we audited the patterns in the app and those on the web. Where we could, we created similar patterns to GOV.UK and where we needed to, created new native ones.
The app was an opportunity to improve the user experience that responsiveness doesn’t always solve.
With the GOV.UK Design System you are able to design and build using a prototyping kit with all the styling and components built into it. But, we didn’t have that for native mobile. We also didn’t have a method for getting designs from Sketch to Android and iOS. What it meant was that we were going to need a design UI kit, another for Android and iOS developers, and some way of keeping everyone in sync.
We already use Invision for prototyping user journeys in the app and we could easily publish from Sketch to Invision with Craft. So using what we already had, we created and published a mobile set of guidelines everyone could refer to. Developers could use Invision Inspect to reference any specific details. And we could share what we were doing across the rest of the organisation.
Thorough and inclusive
To ensure we could test that each component in the design system worked as expected, we created companion apps to run alongside the guidelines. Using these, we could test components on devices, independent of the main app. This ensured our users were not affected, as new components were not pulled into the main app until we had thoroughly tested them.
Being government we need to make sure the app is accessible to everyone. That means designing, developing and testing design patterns and components work with a phone’s assistive technologies at every step of the journey. This new way of working is much more streamlined and means we can design, build and test much more quickly and robustly. Also, if we make a change it updates across the whole app ensuring a consistent user experience.
We talk more
We released version 1.0 of the mobile app design system at the end of November 2018. Since then we have implemented it across Tax Credits, Help to Save and most recently Pay As You Earn. We’re still ironing things out, learning and improving as we go but the new process and way of working seem to be working:
- We schedule a weekly meeting between design, development and testing to talk about anything happening cross-team that might impact the components or design system.
- There is a strict process for adding or modifying components and a sign-off process to follow which includes checking-in with other disciplines.
- We also made everyone in the team accountable for the way things look and function, with designers and developers pairing when designing and creating new components.
- We also spend a lot of time speaking to our users to understand what they need, what works and what doesn’t.
We could sum it up by saying, we talk more.
We are constantly building, evaluating and working hard to make things better. Things will change. This will be one of many extensions of the Design System. But the process of involving and talking to each other more will help us scale and extend it well into the future.
If you have experienced similar problems it’d be great to hear how you and your teams solved them. Feel free to reach out on Twitter @iammarcbelle
An edited version of this article was originally published on the HMRC Digital blog.