Extending the HMRC and GOV.UK Design System for mobile apps

Appy Days

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.

There were many differences between the web and mobile app. Including inconsistencies between individual mobile app pages

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.

The mobile app extension of the GOV.UK Design System features components that function in a much more native way. For example, using interactive rows (right) rather than traditional web text links (left)

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.

The mobile app design system comprises of a Sketch UI kit, mobile guidelines that highlight components are used and built, and companion apps for each operating system

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.

Ensuring components are accessible and work with a device’s assistive technology is considered at every stage

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.

Conclusion

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.