Native apps

[christopherthomasdesign]

What

Native mobile apps for government – things like the GOV.UK ID Check app and the HMRC app.

Use this space to share things like:

• any broad design principles you've used when working on apps
• things you've learnt from testing mobile apps with users
• how you've adapted GOV.UK styles to an app context
• any components or patterns that are specific to mobile app context (for example, switching between apps and the web)
• how you think different government apps should relate to one another (for example, naming, scope, icons)

These findings could eventually lead to producing some guidance about designing apps "for GOV.UK".

Why

There are a few UK government apps out there, and they use slightly different approaches. We've also heard from different teams asking if there's any guidance out there for designing government apps. It'd be good to share more of what we've learnt to bring a more consistent user experience to them.

CDDO have committed to creating a mobile app strategy as part of their 2022–25 roadmap for digital and data. This is at a very early stage at the time of writing (March 2023), and we don't know what shape it will take. But anything we gather here can be contributed to that strategy to make sure it reflects the knowledge and experience of teams working on apps.

Examples

• there are 4 central government apps in the Apple app store at the moment: GOV.UK ID Check; HMRC; EU Exit: ID Document Check; UK Immigration: ID Check (we've heard of a few other teams working on apps too)
• the team working on GOV.UK ID Check app created a pattern library for it, we could look into sharing that work

Related links

• the Service Manual is the main existing guidance on building an app, last updated in May 2019

[jenbutongit]

Apple has extensive documentation on building apps for iOS (or other apple platforms). https://developer.apple.com/design/human-interface-guidelines/guidelines/overview. There are also accessibility/usability guidelines, things like making sure a button's hitbox is >44pt x 44pt so it's easier to tap. Some of these will apply to android (like the button), but some will be apple specific. Also some docs (official apple docs seem to be outdated) https://www.kodeco.com/6827616-ios-accessibility-getting-started on how to use the Accessibility Inspector.

In terms of switching from web to app or app to web, there will be a way to do this in both platforms. https://developer.apple.com/documentation/xcode/supporting-universal-links-in-your-app this is more technical documentation since there are security considerations especially if you are transferring any data between app <-> web at this point.

Although it may be slightly disconcerting using the exact same UI for both platforms, using a framework like flutter or react native will reduce some design/development cost. There is still a possibility that additional platform specific code to write, in which case you still need an iOS and Android developer, but there is less duplication. Serving an app which is mostly webframes (like the NHS app) is usually ok too when you want to dedupe work.

[frankieroberto]

Should apps have animated transitions between views? This is common for native apps (eg default Notes app on iPhone) but not common on the web.

[stevenjmesser]

Has anyone experimented with Web Push notifications for Web Apps on iOS and iPadOS?

[drenton]

So timely. Ontario beginning to work on an app strategy.

Some early strategic principles/thoughts

(not totally sure where this is going, so maybe more scratch pad... so would welcome some feedback 🙏)

1. Apps are not a replacement for website capability, they are a difference of kind, not degree—targeted and focused to very specific needs (how do we avoid the desire to turn the website into an app)??
2. An experience designed specifically for use outside of the work and home setting i.e. on the go — in the community, while shopping, while in the car, in a park, at the border etc. where ease of use through apps vastly exceeds the best mobile web experience
3. Government apps should be looked at as additive, unleashing unimagined potential to save time and improve the lives of people in Ontario.

Other considerations/thoughts

• Domain appropriateness - where is there sufficient domain speciality to make a unique app valuable vs general purposes ones for Individuals or businesses i.e. parks, benefits recipients, post-secondary students, healthcare etc. an initial strategy that identifies domain opportunities - Ontario has only one app published right now (for roads/drivers)
• Needs that are appropriate for apps and that are not necessary device feature dependent (i.e. only achievable via an app), but focused on the unique app user behaviour that come with mobile devices i.e. higher conversion for push notification and more trust with app notifications vs email or sms or phone calls etc.
• Naming patterns and icon patterns (how to avoid branding problems/conflicts)
• Design system updated for app context. Our experience building apps used in the pandemic (vaccine verification) demonstrated that we're off the mark design wise when we attempt to apply design system patterns geared towards web
• Official publishing accounts (legitimacy issues) - should we have one or multiple?
• Requires a full-feature set of online services; apps should add more value not be just a duplicate of what you can do online

[jenbutongit]

Should apps have animated transitions between views? This is common for native apps (eg default Notes app on iPhone) but not common on the web.

@frankieroberto not necessarily for iOS. It depends on the type of navigation or action. In the case of the notes app you describe, when you navigate to a note, it's adding a new view to the navigation stack (imagine a stack of papers). When you hit back in the top left corner, you "pop" the view from the stack. You'd want to use this if there is a root view, something a user can eventually return back to. Given you're using SwiftUI or UIKit (out of the box UI classes) you do not have to add any additional animations, they come as the default (but you can change it) Similarly, you may want to use sheet actions (see adding a new contact) for short lived actions.

There is also tab navigation which typically doesn't animate anymore. But if the user can slide their thumb to move across the tabs, you might want to animate it as if they were dragging the views (although not required).

[aislingbrock]

Hi everyone! I am a Senior Interaction Designer on the HMRC Mobile App team. The HMRC Mobile App has been around in its current form since 2016 so we've done a lot of work in this space. The app is available on both iOS and Android (we noticed only the Apple App Store is mentioned in the original post!). We have dedicated development teams for each platform that work closely together to ensure a consistent experience across platforms.

On the design side, have a design system that takes the GDS design system and marries it with both the Apple Human Interface Guidelines and the Android Material Design guidelines. This system has not only been used to create the HMRC Mobile App but has also been used to create internal proof-of-concept apps.

To answer some things I've spotted above:

• We try to keep animations subtle for accessibility reasons. Of course, there are system controls that can help with this. But generally speaking, we don't use transitions between screens. We do use some subtle animations on data visualisation elements (like charts that fill in to show individual pieces before becoming static).
• We are currently in the process of exploring push notifications from the web to help with multifactor authentication.
• We're also looking at establishing criteria for what makes a good app candidate and what doesn't, based on our experience and the different areas we've been asked to explore over the years.
• Some of these guidelines touch upon what is mentioned, for example, we are not a carbon copy of the web. We are a tool to help users in a more timely sense. So they can find what they need to do now, take action, and feel involved and in control of their taxes.
• We specialise in microtransactions, not long-winding user journeys. Users check in often to make sure their data seems "correct."
• We are also putting emphasis on actions that occur while on the go. As well as giving users the freedom to access their data and port it to wherever else they may find a use for it.

Some of our recent findings that we've been really interested in is how apps fit within the cost of living crisis, especially with users on lower or variable incomes. We're finding fewer households have desktop or laptop computers as they come at a higher cost. Broadband is also increasing in cost. Whereas smartphones can be bought for less and mobile data in the UK isn't too expensive (certainly not as expensive as in Canada -- I'm Canadian, and moving to the UK has probably saved me hundreds of dollars in mobile data costs over the last 10 years haha). With the initial download and subsequent use of our app using overall less data than the web, we can see clear cost benefits to some of our users.

We're also big sticklers for accessibility. There's a lot to be said for how built-in accessibility tools on smart devices have changed the game in allowing users to customise their device environment and access information in a way that isn't as simple on desktop PCs which often require 3rd party software and websites which are tricky to override. We design our apps so these system settings persist within the app, and so the app works seamlessly with VoiceOver and TalkBack.

Also perhaps interestingly for our Canadian pals, we're in the process of providing the app in both English and Welsh! Since I am Canadian, one of my resources when looking at languages was to look for Canadian apps in both English and French. I didn't come across many which was likely either because I don't have access to all Canadian apps on the UK app store, or because Canadian bilingualism is so prevalent that there are standalone French language apps. So it's been interesting to look at bilingual (or potentially multilanguage) apps over the last few months.

As you can see, we could chat apps all day, and we have been waving this flag and hoping for updated guidance for quite some time! It will be nice to move past the argument of "should apps exist at all" which so often derails conversations about the work we have been doing! We really welcome further conversation and to share more of our knowledge.

We're on the x-gov Slack channel, or you can find me here, and I can put you in contact with one of our many other app experts who will be MORE THAN 'APPY to help. :)

[frankieroberto]

@jenbutongit thanks for the detailed explanation!

My question was partly motivated by the observation that, where a native app is mainly a wrapper for a web view, there's often no animations when following links, even if they're designed to look like native-style navigation. This kinda bugs me (although it took me a while to work out why these apps felt weird), but I’m not sure if this is an issue worth addressing or not?

I guess it comes down to whether or not to use native views or web views... 🤔

[mattmachell]

This is interesting. Does it indicate a change in strategy and roll back the intent of the classic blog post we're not appy ?

A lot of what I see in gov space mobile apps could easily just be a progressive web app, as they are just webviews in app wrappers. That is to say they aren't really doing anything that necessitates low level native api access, higher performance graphics, deep OS integration or any of the reasons you'd really want to use an app and thereby bind yourself to app-store policies and update cycles.

I guess I'm wondering on the intent and the user need you're looking to solve with this and what's driving it?

[querkmachine]

@mattmachell Not an area I'm involved in, so opinions my own: I don't think this is a change in strategy, as (at least in GDS) our intended use cases seem to be limited to places low/native-level API access is needed.

The most high-profile at the moment might be the planned One Login app, which will support biometric and NFC-based identity verification methods. Doing these purely in the web browser is currently either impractical, if not impossible.

The Web NFC specification is still a community draft, only available in Chromium on Android devices, and—to my knowledge—only supports the NDEF protocol, which isn't the same as the one typically used on identity documents like passports.

Biometric authentication has technically been possible on mobile browsers for some time, however have only recently become available to the 'mainstream' with the addition of Passkeys support in iOS 16.

As far as I know, there is no intention for apps to replace online equivalents or become the sole means of accessing government services—they're either being used as 'shortcuts' for services that are very frequently used (as the HMRC app is) or they're stopgaps where, unfortunately, the browser support just isn't there yet.

[jenbutongit]

@jenbutongit thanks for the detailed explanation!

My question was partly motivated by the observation that, where a native app is mainly a wrapper for a web view, there's often no animations when following links, even if they're designed to look like native-style navigation. This kinda bugs me (although it took me a while to work out why these apps felt weird), but I’m not sure if this is an issue worth addressing or not?

I guess it comes down to whether or not to use native views or web views... 🤔

Loading spinner is fairly standard procedure for native apps, but I concur, on a phone's browser you at least have some indication like a progress bar or spinner whilst the request is made but is often not implemented for apps-that-are-just-webviews-with-native-sprinkles. For tab navigation there aren't usually loading spinners but since it's native/some data stored on device, it feels more responsive when loading a page/tab, then the rest is loaded in via skeleton components or loading spinner.

I imagine most of this comes down to expertise in web development vs app development. If it's easier/cheaper for you to implement as web view, you probably don't have much choice.

To echo @querkmachine's sentiment, it's worth considering whether a web shortcut is fine or if you do actually need lower level app integration. in the case you do need a native app, you probably do just want them to go into the app, do the action, and then send them back to their browser.

In the cases that the native app ends up being really small, and doesn't really need any persistence, I wonder if app clips would be better? https://developer.apple.com/app-clips/ (Android have an equivalent also).

[stevenjmesser]

Hi @mattmachell, Tom’s blog post was written for that moment in time, the intent being that a focus on web standards and service design would lead to better government services. He noted that on Twitter and he also mentioned that things have since improved.

Blog posts aren’t recommended for publishing essential information or policy, that happens on GOV.‌UK. So you’ll have to keep an eye on CDDO’s latest documents and the aforementioned guidance on building an app in the Service Manual for changes in strategy. But as we said above, we’d like anything that our community has learned to feed into that strategy, so we’re collecting insights.

To be explicit, I don’t think anyone is saying that we should ignore web standards and focus on apps only.

[stevenjmesser]

I wanted to add Digital Identity's architectural decision record around cross-platform versus full native, as it has some good notes on user experience, accessibility and performance.

They have another repo for mobile accessibility too.

[frankieroberto]

I wanted to add Digital Identity's architectural decision record around cross-platform versus full native, as it has some good notes on user experience, accessibility and performance.

This link isn't public, unfortunately. Could you check with the team whether they'd be happy to copy and paste it here?

[christopherthomasdesign]

Chat with HMRC app team, 26/06/23

We had a great catch up last week with several of the HMRC app team. We shared our work in this space so far, got feedback on it, and learned more about their experiences designing a government app. Here are a few key principles and learnings they shared.

Visual design

• The team chose to use system fonts rather than GDS Transport, the same as the GOV.UK ID Check app.
• They were questioned for that choice in a service assessment. This is an angle we hadn’t thought about when it comes to the potential value of Design System guidance on app design.
• Have to support portrait and landscape, as well as rotating the device whilst in use – you need to build and test for this
• The team are starting to think more about tablet and big phones too, that middle screen size space has a small but growing proportion of users
• As with the GOV.UK ID Check app, the team talked about how they’re moving away from a strict adherence to GOV.UK web patterns and more towards native ones
• Marc Belle shared a couple of useful blog posts that outline the design approach in more detail
• Making mobile apps accessible
• Extending the HMRC and GOV.UK Design System for mobile apps

User behaviour

• You can’t ever be sure what version of the app someone is using – some people don’t have auto updates turned on
• About 1/3 of users turn off notifications, and if you spam them they often turn off notifications forever
• The team uses some principles for designing good notifications, they should be “relevant, personal, actionable and timely”
• Users periodically delete go through the apps on their phone and delete the ones they don’t need, so it’s important that your app has something useful for them when they check back in

Content

• You need to structure content differently on mobile apps, you need even less of it than we use on GOV.UK
• The approach to content is even more minimal than on GOV.UK – it’s not a content platform, people don’t go to the HMRC app to read about stuff, and GOV.UK has the infrastructure in place to handle that better
• Moving to a more native-led design approach to apps mean using more buttons and fewer links, and this means having to restructure a lot of existing content to make it work better in an app context
• Keeping the web and app in sync is very difficult, so it’s a good idea to minimise duplication in content

Team processes

• It’s important to be recognised as a government app as it’s good for user trust; it also means your developer account is waived, and can help expedite app releases in certain circumstances
• The team uses an ‘app consideration criteria’ framework to determine whether a feature is a good idea to be included in the app, to make sure they provide clear value

Links to HMRC’s app pattern libraries

• https://github.com/hmrc/ios-components
• https://github.com/hmrc/ios-swiftui-components
• https://github.com/hmrc/android-components

[dkindnes]

I'm at the early stages of looking at how the Scottish Government Design System can advise / be used for native apps so have found this thread very helpful!

One question I had been pondering was whether a design system that has been built for responsive web sites should be used for native apps. Based on the above it seems like the current consensus is that it is better to maintain a separate resource that isn't linked but that tries to use the same design language of the design system in conjunction with established patterns provided by Apple and Android?

If this app pattern library is intended to be used by various teams should it be maintained by a central group?