Document Checking Service App Alpha Assessment
The report for the Digital Sign On Document Checking App alpha reassessment on the 17 May 2022
Service description
The Document Checking App and Web service will provide an optional route for users of the HMRC service to digitally prove their identity using official documents and face matching, starting with a UK driving licence. This will enable them to access Government Gateway services via a Government Gateway account. There will be a web and app element and users will pass from the HMRC Government Gateway web pages into GDS pages and then into the GDS mobile app, before returning to Government Gateway pages.
Later in our roadmap, this service will be available through GOV.UK Accounts and GOV.UK Sign-In as part of One Login for Government. It is a GaaP-like service in many respects.
Service users
For private beta this service will be for:
-
UK Driving Licence holders who want to access a service provided via Government Gateway, and who want to prove their identity with digital face matching via an app
-
These users will also have a mobile (iOS or Android)
1. Understand users and their needs
Decision
The service met point 1 of the Standard.
What the team has done well
The panel was impressed that:
- the team is building on research done across the digital identity programme
- research and experiences from other, similar services, particularly the home office, has informed the team’s understanding of their users
- both previous research and the research on the new service is considered
- an understanding of the breadth of the services’ users, in particular those who might face barriers when trying to use the service, was at the heart of the team’s approach to research and had clearly informed the decisions they made.
- as far as possible, research had been designed to test realistic end-to-end journeys
What the team needs to explore
Before their next assessment, the team needs to:
- consider how they are going to fully test the underpinning assumptions relating to the decision to build an app. This seems to be centred on the effectiveness of NFC in providing more robust identity verification - it involves directly taking the information from a passport chip and so is both more reliable and easier for the user. While the team has used existing research and experience from other services and countries to inform this decision, it would benefit from additional review in the context of this service. The team has done some excellent research on the driving licence journey, but without testing their assumptions about the passport / NFC journey it remains unclear that such a journey would meet the needs of their users
2. Solve a whole problem for users
Decision
The service met point 2 of the Standard.
What the team has done well
The panel was impressed that:
- the team is working ‘hand in hand’ with HMRC, sharing deep dives and testing each other’s screens
- the team is using learnings from Verify and insights from other parts of their wider team, for example from the DBS work
What the team needs to explore
Before their next assessment, the team needs to:
- consider how they can demonstrate how the product works in the context of the end to end service it is operating in more visibly
3. Provide a joined-up experience across all channels
Decision
The service conditionally met, subject to caveats on activity to be completed before entering private beta, point 3 of the Standard.
What the team has done well
The panel was impressed that:
- the team is focused on creating a product that will work across government services, even though the initial consuming service is just HMRC
- the team is designing to help people trust the service - for example, having users go through the triage screen in all circumstances, before transitioning to the app
- the design has moved away from iOS and Android default patterns, such as having all pre-download information on one screen, instead introducing one concept per page which works better for their users
- the team has tested whether users need content explicitly calling out the move between web and app, and between consuming service and the identity service
What the team needs to explore
Before entering private beta, the team needs to:
- test a high-fidelity prototype starting in the consuming service, moving to the web identity service, then into the app and back to the consuming service - while the panel understands that transitions between the DBS service and the web identity service have been designed and tested by another team, this is a different consuming service (HMRC), with a brand new element in the middle (the app), so there may be new pain points to discover
- explore and address, or feed back to the web identity team about, any confusion that might be caused for screen reader users by a URL change when transitioning to and from the consuming service
4. Make the service simple to use
Decision
The service conditionally met, subject to caveats on activity to be completed before entering private beta, point 4 of the Standard.
What the team has done well
The panel was impressed that:
- the service will recognise what device a user is using, and will not present the app as an option if it’s not an appropriate device
- users will be given a link to the specific app rather than instructions on how to use the app store
- the content designer is engaging the GDS user centred design community in naming the app, giving clear criteria the name must meet
- the team takes their work to design crits
What the team needs to explore
Before entering private beta, the team needs to:
- design and test error messages
- select an app name and test it with users - the current intentions for the app mean that the name does not need to be findable in the same way as other service names, but as the team clearly explained, it still needs to be meaningful, not misleading as to the app’s purpose, and not easily confused with other products
- check how the content flows not just within the app, but when transitioning to and from the app, and transitioning to and from this specific consuming service
- get a 2i done on all content (possibly due to technical conventions in the app, a very odd phrase has crept in: The “GOV.UK Sign In” Wants to Use “GOV.UK” to Sign In)
5. Make sure everyone can use the service
Decision
The service conditionally met, subject to caveats on activity to be completed before entering private beta, point 5 of the Standard.
What the team has done well
The panel was impressed that:
- the wider team is working on a range of ways for people to prove their identity, including knowledge-based questions for people who don’t have, or can’t use, photographic ID
- avoidance of bias in biometric checking was one of the top criteria when choosing a vendor
- the team is planning on getting some independent testing done to assure or reveal any issues around bias in the biometric checks
- the team has considered a wide range of ways in which people could be excluded and is looking at each bit of the app design in detail through that lens
- the team have scheduled independent accessibility testing
- the designs allow users to leave and change route throughout
What the team needs to explore
Before entering private beta, the team needs to:
- design the screens associated with the ‘unhappy path’ parts of the journey, and test these paths with users
- check that there’s adequate contrast between the black text and grey background on the app modals
Before their next assessment, the team needs to:
- continue to explore and address known and potential accessibility pain points, such as reliance on colour (‘follow the guidelines until the white frame turns green’)
6. Have a multidisciplinary team
Decision
The service met point 6 of the Standard.
What the team has done well
The panel was impressed that:
- the team have all the expected roles in place (although the panel noted that in some roles the amount of time available for this service appears limited)
What the team needs to explore
Before their next assessment, the team needs to:
- check that they have enough content design resource for the content designer to be fully involved in each bit of design work from the start - not adding in copy later in the process
- consider how they will ensure continuity of knowledge and as the service develops with a primarily contract team
7. Use agile ways of working
Decision
The service met point 7 of the Standard.
What the team has done well
The panel was impressed that:
- the team are working in an agile way with a range of ceremonies and techniques
- the team are working as part of the wider programme and have appropriate governance arrangements in place
- the team have access to all the appropriate tools
- the team are working closely with the team in which the product will be use initially
8. Iterate and improve frequently
Decision
The service met point 8 of the Standard.
What the team has done well
The panel was impressed that:
-
designs have been tested and iterated to improve usability
-
the team have considered future areas to consider and focus on as they continue to build the service including key areas of focus to improve take up
What the team needs to explore
Before their next assessment, the team needs to:
- ensure they continue to iterate and learn and address the key areas they have identified as needing further exploration
9. Create a secure service which protects users’ privacy
Decision
The service met point 9 of the Standard.
What the team has done well
The panel was impressed that:
- the threat modelling is sound and makes uses of NCSC scenarios for criminal journey planning
- the security team has been involved since the beginning and worked in an embedded way with the service team
- there is no transfer of PII through the service until required
- the team proactively thought about security issues in SMS-based OTP authentication
What the team needs to explore
Before their next assessment, the team needs to:
- provide assurance that the security aspects of this component of the wider digital identity service are aligned with this service
10. Define what success looks like and publish performance data
Decision
The service met point 10 of the Standard.
What the team has done well
The panel was impressed that:
- the team have developed a clear and comprehensive performance framework
- the team have considered the varying KPIs dependent on the service the product sits within
What the team needs to explore
Before their next assessment, the team needs to:
- continue with their planned approach to implement the framework and start gathering and analysing the data and using this to inform the ongoing development and monitoring of the service
11. Choose the right tools and technology
Decision
The service met point 11 of the Standard, within the constraints given. The service team, having been given the development of a “native app” as a mandate, made good technology choices within that mandate.
What the team has done well
The panel was impressed that:
- the team presented a clear, modern architecture based on cloud components, with technology selected in alignment with the rest of the programme
- the architecture team at HMRC was engaged throughout the Alpha
- the team has taken into account how to grow technical capability
What the team needs to explore
Before their next assessment, the team needs to:
- make sure that the technical approach is not limited to apps and considers other user journeys
- reflect on whether a “mobile web” version would be able to serve the same purpose, at least for this part of the service where no hardware capabilities are exploited
12. Make new source code open
Decision
The service did not meet point 12 of the Standard.
What the team has done well
The panel was impressed that:
- the team has been operating on an open source basis, working collaboratively on GitHub, even if not immediately releasing the code
What the team needs to explore
Before their next assessment, the team needs to:
- release the source code
- make sure that they have the resources to develop a service of this prominence -the panel were concerned that the reason provided for not releasing the code immediately is that the team is too small
13. Use and contribute to open standards, common components and patterns
Decision
The service met point 13 of the Standard.
What the team has done well
The panel was impressed that:
- the team displayed a good understanding of accessibility, security, and identity standards
- the team displayed a good understanding of downstream standards requirements
- the team has taken evidence-based components and patterns from the GOV.UK design system as its starting point, replicating for app use where possible
- the team plans to feed back their findings and any new components to the design system team
What the team needs to explore
Before their next assessment, the team needs to:
- consider whether in the ongoing development of the service, there are opportunities for component sharing and reuse
- identify where the service has deviated from standard components and content patterns and ensure there is a validated technical or user need to do have done so (for example using a bulleted list in hint text, or centralising the text on the app home screen and in modals, or the capitalisation in modals)
14. Operate a reliable service
Decision
The service met point 14 of the Standard.
What the team has done well
The panel was impressed that:
- the team is influencing the building of a GDS DevOps capability
What the team needs to explore
Before their next assessment, the team needs to:
- describe what assessment of performance they’ve made and how to keep the service performing well