Apply for a Veteran’s ID Card alpha assessment
The report for the Apply for a Veteran’s ID Card alpha assessment on 03 October 2022
Service Standard assessment report
Apply for a Veteran’s ID Card
| From: | CDIO Assurance, Cabinet Office |
| Assessment date: | 03/10/2022 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | Office for Veterans’ Affairs (OVA) |
###
Service description
The Apply for a veteran’s ID card service will allow users and providers of beneficial services to veterans to confirm that someone has served in the UK armed forces in a one-off, simple process, so veterans can access the services they are entitled to.
The service allows a veteran to:
- request a physical veteran’s ID card
- request a digital veteran’s ID card
- sign up to a mailing list for veterans
Service users
This service is for UK armed forces veterans. The current solution is for those who left prior to 2018.
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 has included a wide range of participants (48+) in their user research including veterans and the third-party service / support providers (such as charities). This research informed the full design process from overarching service design to individual feature iterations
- the team has chosen the appropriate methods to answer their research question, and could clearly describe how they elicited detailed insight from users
- the team had mapped the end-to-end service and individual processes based on user research, resulting in a clear picture of the processes within the service
- they sought to identify and involve users in their ‘normal environment’ such as through veterans drop-in centres which helped them include a broader user base
- the team identified user persona gaps within their Alpha research that should be explored in their Beta approach
What the team needs to explore
As they move into Private Beta, the team needs to:
- review its relationship with their participant recruitment agency. The team highlighted that this had been challenging during the Alpha phase as the agency had failed to provide participants with minimal notice leading to fewer session than planned. The agency also struggled to identify users with assistive technology needs
- involve users that would complete the service with “a helper” such as a family member or third-party support. This will help them ensure that their service can be completed by the full spectrum of their user base and uncover potential issues for the “helpers”
- refine its user research plan for Beta with clear themes and priorities so that they can sustain their research cadence beyond Alpha
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 has considered the end-to-end user journey and felt fully empowered to iterate their service designs around feedback from the user research. This remained closely tied to their initial problem statement and research on the problem space. It included research beyond the primary service scope such as how third-parties would use the veteran ID card
- they have developed personas around their user research and are iterating these as research continues. This includes users with low digital confidence and accessibility needs
What the team needs to explore
As they move into Private Beta, the team needs to:
- conduct research with veterans that left service after 2018 and so already have the existing ID cards. This should focus on any pain points in the existing service such as how they use their veteran ID cards. This will help ensure any changes are made before they launch the new digital service and increase the circulation of veterans’ ID cards
- increase the amount of research with “back office users” such as those that need to verify veteran status when it cannot be done automatically. The team has taken a prudent approach to prioritise the needs of veterans and in Beta they should expand this activity to those civil servants that will use the internal sides of the service (such as case management)
3. Provide a joined-up experience across all channels
Decision
The service met point 3 of the Standard.
What the team has done well
The panel was impressed that:
- the team has engaged third-party service providers, including charities and local authorities, to understand their needs for identifying veterans. This has also highlighted opportunities for them to expand their service/support offerings if they have confidence verifying veteran status
- they have considered the assisted digital journey comprehensively, including engaging third parties that could provide this support such as charities
- they have investigated a fully offline route for users that cannot use the online route, either due to digital capability or lack of identity documentation. This includes having a more robust process design and plan than would usually be expected at an Alpha stage. They have also engaged some of the third party providers that would support this
- the team has ensured that the offline route meets similar standards and guidelines to the digital journey, such as alignment to Good Practice Guide 45 guidance on checking identity
What the team needs to explore
As they move into Private Beta, the team needs to:
- test the offline stages of their journey, such as ID card production and postage, to ensure they meet user needs and expectations. The team has ambitious targets for veterans receiving their physical ID cards which needs to be supported by a reliable customer service function
- test their service with the operations teams at the Ministry of Defence (MoD) to understand how they will interact with applicants if there is a problem with their application
- further ensure that policy makers (Cabinet Office and MoD) are invited to attend user research sessions and involved in prioritising design decisions
4. Make the service simple to use
Decision
The service met point 4 of the Standard.
What the team has done well
The panel was impressed that:
- the team has adopted the GOV.UK Design System and are reusing common components where possible so that users are confident the service is legitimate
- the team has iterated the interaction designs and content to ensure they are intuitive and aligned to user needs. This includes persuading government stakeholders to adapt how they describe the service to empathise with veteran needs, such as transitioning away from “verify you are a veteran” to “apply for a veteran’s ID card”
- they have identified user groups that may need extra support to complete the service and how this could be provided. They have also investigated some of the specific barriers that could impact users, such as a higher proportion of low digital confidence users correlating with more elderly users
- the service is designed to minimise manual identity verification and avoid data re-entry. By default, the service will verify veteran status automatically by matching Digital Identity attributes against existing veteran data sets. Where a user’s veteran status cannot be verified online they will be automatically be transferred for manual verification without the user having to complete additional steps
- the team has designed the service with multiple entry points in mind, including GOV.UK and support services for veterans
- the team gave multiple examples of iterating content to make the service as intuitive and stress-free as possible
What the team needs to explore
As they move into Private Beta, the team needs to:
- consider how they will support users that lack the identity documents needed to complete the Digital Identity stages of the journey
- do more usability testing of the end-to-end journey including the Digital Identity journey. The team highlighted that this is where users were currently more likely to struggle but, as Digital Identity is also in its Beta stage, is being rapidly iterated and improved
5. Make sure everyone can use the service
Decision
The service did not meet point 5 of the Standard.
What the team has done well
The panel was impressed that:
- the team has sought to include a diverse pool of participants through online recruitment and a participant recruitment agency. Unfortunately the agency has failed to deliver briefs on multiple occasions during Alpha but this is being reviewed for Beta
- they have attended veteran “drop in” events in person to include users that would not be as digitally active and therefore less likely to be recruited through the other channels
- they are monitoring the demographics of participants to ensure that participants in their research are broadly proportionate to the demographics of the veteran population
- the team is also using their ‘participant screener’ to identify users with additional needs so that this is being captured in research feedback
- the team has been working closely with GDS Digital Identity team to share insights around inclusion which has shaped the service
What the team needs to explore
As they move into Private Beta, the team needs to:
- conduct further research with users that have accessibility and assistive technology needs to ensure that they can complete the journey and access any additional help needed. This is part of the team’s research plan and they have referred to building a participant pool including these user types. It is likely that the team would have addressed this sufficiently had they not been disappointed by their participant recruitment agency
- do more research with users that lack the required identity documents to complete the online journey. Their Discovery phase research highlighted that veterans are less likely to have comprehensive identity documentation than the general population. While this will still be the minority of users it could become a significant number overall
- involve “back office users” in their research so that the full user journey is designed to be simple and inclusive
- continue to understand and design for the lower end of the digital inclusion scale and for users who need support to prove their identity
- make sure that users who can not prove their identity are supported or have relevant guidance until the vouching journey is developed
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 service has had a multidisciplinary team for Alpha with a balance of civil servants and supplier staff. This team included most of the core roles set out in the service manual, including two user researchers due to the large and complex user base
- the team has considered what additional roles are needed for Beta, including Design and Technical Architecture, and how they intend to appoint these
- policy colleagues from the Office for Veterans’ Affairs (OVA) have been closely involved in the Discovery and Alpha journey and will continue to be throughout Beta. This also includes appointing a service owner from OVA with responsibility for the whole service (beyond the digital component)
What the team needs to explore
As they move into Private Beta, the team needs to:
- establish a sustainable team and resourcing model with MoD that will continue throughout the service lifecycle. After Alpha there will be significant changes in the team to transition to primarily MoD staff. Changing the majority of the team between Alpha and Beta comes with its challenges but the team has ensured continuity of some key roles (including Service Owner, Product Manager and Delivery Manager)
- refine its approach to knowledge transfer as it transitions from the Alpha team to the Beta team. The team detailed a comprehensive documentation approach but this needs to be complimented with collaborative handover between team individuals so that the knowledge and experiences of the Discovery and Alpha are not lost
- allow time for some inevitable re-work due to transitioning teams (particularly around research and design) as decisions have to be revisited and reconsidered by new team members
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 has adopted agile practices with an iterative and user-centred approach. This includes a “scrumban” approach with two week sprints to iterate the service design. They have adopted a combination of tools to support remote collaboration and worked together effectively during Alpha
- the team has worked in an agile way to iterate their service design throughout the Alpha phase
- the team does regular Show & Tell sessions that are open to their stakeholders and well attended. These have been successful at increasing awareness of their service alongside a ‘weekly note’ to share their progress
What the team needs to explore
As they move into Private Beta, the team needs to:
- review their ways of working as the team expands and changes during the transition to Beta. As this will include the departure of their delivery partner supplier and the onboarding of MoD colleagues it will likely require significant changes to their ways of working
- ensure new members of the team joining in Beta are familiar with agile working and have had appropriate training as it could be a significant change from their conventional ways of working
- review their governance to ensure it provides robust scrutiny and challenge to the team without becoming overbearing. The team has been able to sustain a ‘light touch’ governance structure for Alpha due to close relationships with senior leaders. However, Private Beta will require a more formal governance approach particularly as MoD take greater responsibility for delivery and management of the service
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:
- the team iterated prototypes rapidly during the Alpha phase based on user research. This allowed them to discount ideas and correct assumptions about user needs tased on feedback
- the team considered and tested alternatives to creating a new digital service, including those that were instinctively unappealing, to ensure they were taking the right approach to meeting user needs. For example, they investigated options for expanding and improving users’ existing ‘workaround’ arrangements for getting proof of veteran status from the MoD
- the team is improving internal practices by using retrospective meetings to constructively review their processes and improve
What the team needs to explore
As they move into Private Beta, the team needs to:
- continue to iterate design ideas throughout the Beta phase to design the service based on user needs and feedback
- review how they are engaging with the Digital Identity team to align roadmaps. This service is very dependent on the Digital Identity service and its roadmap so the team needs to monitor their progress closely. This should also include refining their channels for sharing user feedback and contributing to prioritisation decisions
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 service design has taken Privacy by Design as principle throughout the design process
- the team has engaged with the Cabinet Office Data Protection and Compliance Team throughout the process to date
- the team is making use of the access authentication models provided by GOV.UK Digital ID service
- there is an intention to implement controls to limit potential exploitation of the service to extract data
What the team needs to explore
As they move into Private Beta, the team needs to:
- engage with key stakeholders to ensure that a Senior Responsible Officer (SRO) within MoD is identified and that the Data Protection Office (DPO) is engaged to address risks they identify
- engage with the MoD’s Information Assurance team to ensure that they are content with the design and the technology to allow for a smooth transition
- ensure that the Data Protection Impact Assessment (DPIA) for Beta is complete to continue the good work so far on data protection processes
- consider potential opportunities for misuse of veterans ID cards for fraudulent purposes and how this could be detected. The team highlighted that there has been no known fraud in the existing (less secure) arrangement so this is not currently a major concern for them. However, creating this service could increase this risk as it will increase awareness of the services / support available to veterans. The team must consider this and ensure that remaining risks are within tolerance for both Cabinet Office and MoD
- detail who the potential threat actors are for their service and how these risks will be mitigated. This should cover both service security and fraud risks
- engage with Government Security Group (GSG), Cabinet Office CDIO Cyber Security Team and / or The National Cyber Security Centre (NCSC) on a security review
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 has developed a comprehensive performance framework covering the end-to-end service, including offline stages. These are directly linked to the outcomes and user needs for the service. This also includes baselining existing performance data to compare the progress of the new digital service
- they have identified key metrics for the service, including identifying how the mandatory key performance indicators will be measured and used
- there is a plan to add a performance analyst to the team in Beta, likely drawn from MoD staff
- the team intends to use their standard technologies for performance data including Google Analytics, Data Studio and service management information data
What the team needs to explore
As they move into Private Beta, the team needs to:
- consider how they will monitor if the service is “solving the whole problem for users” beyond issuing a veteran ID card. For example, this could include collecting data on how ID cards are being used to access services / support. The team has some early ideas for this, such as comparing against issuing veteran railcards, which they will develop in Beta
- use performance data to inform iterations of the service design, including identifying trends in user behaviour and fixing problems
- establish internal data quality standards and controls to ensure the performance data they use and share is suitable for decision making
11. Choose the right tools and technology
Decision
The service met point 11 of the Standard.
What the team has done well
The panel was impressed that:
- the team has modelled their architecture and tooling around the use of zero-trust principles
- the team has made extensive use of GOV.UK platform services
- there is an explicit acknowledgement of the need to maintain data isolation between processes and stakeholders
What the team needs to explore
As they move into Private Beta, the team needs to:
- engage with MoD on DevSecOps hosting platform (currently in Private Beta) to ensure tested resilience and availability requirements match the needs of the service
- make sure wider non-functional requirements for the service are well defined and tested
- ensure their data refresh processes maintain the security and data integrity
- monitor their service performance to ensure they achieve the target of a minimum of 60 per cent of applications being auto-matched
12. Make new source code open
Decision
The service met point 12 of the Standard.
What the team has done well
The panel was impressed that:
- the team is working in the open and publishing their code on GitHub where possible. This does not include their matching algorithm to reduce risk of fraud
- the team has made use of open-source software and frameworks for both frontend components and the probabilistic matching tool (Splink)
What the team needs to explore
As they move into Private Beta, the team needs to:
- ensure ancillary services (including monitoring and CI/CD) continue to make use of open source tooling
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 is using a range of common Government as a Platform components including the Design System, GOV.UK Notify, GOV.UK Digital ID and Splink
- they are using the OpenID Connect open standard (authentication)
What the team needs to explore
As they move into Private Beta, the team needs to:
- ensure that production components developed in Beta continues to comply with the preference for open standards and patterns
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 has planned for the long-term support of the service and will transition the service delivery to MoD teams
- they have identified the additional roles needed in Beta to provide adequate support and will scale this as the service progresses
What the team needs to explore
As they move into Private Beta, the team needs to:
- make sure they avoid a potentially onerous administrative overhead relating to technology stack, and they have an appropriately skilled team in place to manage the environment
- validate that their planned strategy for printing physical ID cards can meet their expectations and has the capacity to handle potential volumes
- ensure there is a robust data refresh process to support automated matching
Updates to this page
Published 18 November 2022