Prove your right to work - beta
The report from the beta assessment for Home Office's Prove your right to work service on 2 March 2018.
| From: | Central Digital and Data Office |
| Assessment date: | 02 March 2018 |
| Stage: | Beta |
| Result: | Met |
| Service provider: | Home Office |
The service met the Standard because:
- There is a strong, capable and empowered team developing a user-centric service in an agile way, at pace.
- Although detailed behavioural research started was limited early in development, the team had built a robust evidence base that was actively informing their development and design choices.
- Sound, well-proven technology choices within a well-established service portfolio (Home Office Immigration platform) have resulted in a robust, yet flexible foundation to build on during the public Beta phase.
About the service
Description
The service enables employers to meet their legal obligations to employ staff permitted to work in the UK.
Service users
The users of this service are migrants to the UK, who will use the service to prove to employers that they are able to work in the UK. A parallel service enables employers to check that their workers are legally employable.
Detail
User needs
The team have looked to conduct usability testing in private beta, but have faced a number of challenges around timescales and technical availability of the service under development. Much of the challenge seems to have been around encouraging and enabling participation in the private beta following changes in timescale.
Before the full private beta began the team conducted usability testing with a prototype of the service with representative users of the migrant facing part of the service. Gaining participation from users with access needs in this space can be challenging. However, the team have clearly thought about the need for including users with access needs by conducting usability testing with proxy users and commissioning an in house accessibility audit. What was not fully clear from the presentation was the extent to which attempts were made to recruit migrant or employer users with access needs before this decision was made.
The team were able to report digital inclusion metrics which demonstrated employee / applicant users had been recruited from the assisted digital range of the inclusion scale. This was not the case with the employers who had been recruited into private beta participation.
The way users have been found for research currently risks bias towards companies with an awareness and understanding of the service. Although the team were able to speak convincingly about the efforts to raise awareness of the service and the reasons for recruiting via this route, there will remain employers who are not engaged with government and who will need to be included in future research for this research to be considered representative.
The service manager will need to ensure there is continued engagement with this service as the team begin work on the related ‘right to rent’ service. In particular there is a need as the service becomes mandatory to ensure that it is usable by all users, including those with a current preference for a physical object. Significant care will be required before any decision to remove the physical ‘Biometric Residence Permit’, due to these strongly held concerns, particularly with users with low digital skills. There is a clearly identified user need for the physical card at present, and without strong evidence that this need can be mitigated for vulnerable, low-digital skill users, it should be retained.
Given the last minute aspect of this work some changes were still being made in the run up to the assessment itself. However, encouragingly decisions seem to have been made at the appropriate level on the basis of evidence gathered from user research. The team spoke convincingly about this and gave numerous examples of design changes being made and to be made and an approach that was informed by user needs.
Team
The team at the assessment demonstrated excellent knowledge and awareness of their service users and their needs. Key specialisms are all represented, including developers and researchers, designers and analysts. They are working to recruit additional civil servants to the team as the relatively low number of permanent staff is a concern for the long-term sustainability of the team. This will be a particular consideration as development matures and the potential for starting other products or services, such as ‘right to rent’.
They are demonstrably working in an agile way, largely co-located, with some team members working remotely from Sheffield. The team have iterated their ways of working, introducing a greater emphasis on kanban from a more traditional Scrum approach.
The panel were particularly impressed by the strong Product Manager and Service Owner combination, who combine high levels of domain and digital specialist knowledge to good effect. They are clearly empowered to take appropriate design decisions, supported by proportionate governance from a steering group with good representation from key Home Office stakeholders.
Technology
The service team have selected a proven technology stack and have well-developed continuous integration and devops processes. They use a task tracking system to enter, prioritise and see the progression of stories clearly from user research into production and the team works together well to achieve this on an ongoing 2 week sprint cadence.
Though the team have made advancements, deployments do cause a small amount of downtime for users. This is an issue that the team are progressing; the service team are working with their platform service team and the cloud hosting provider to move towards the use of techniques such as blue-green deployments to ensure zero downtime deployments.
The ‘check RTW’ and ‘prove to employer’ digital services and the team benefit from and share an underlying immigration portfolio technology (IPT) platform operated as a programme that delivers expertise and technology services, such as the Person Centric Data Platform, to this and other citizen status check projects. The team demonstrated that this does not hamper the team’s ability to iterate based on evidence and they continue to have the flexibility they need to evolve their service as well as being able to themselves contribute improvements to the underlying IPT Services platform that may benefit the whole portfolio.
Health monitoring, alerting of any issues and having clear lines of responsibility and escalation for issues are well known and the service team have rightly given this some considerable attention. The team are well placed in terms of support as well as build, hosting and monitoring solutions to roll out the beta to a wider audience.
The nature of the relationship between the service team and the underlying IPT Service platform and the access they require to the expertise marshalled at the portfolio level means that there are potential tensions between the service team and their need to access portfolio level expertise, such as Security and legal/privacy teams. The regular access that the team has to the Portfolio Design Authority and the examples of those interactions that the service team were able to demonstrate show that they are handling this potential contention issue well. The service team explained how they arrived at their current choices over authentication in consultation with security experts and they demonstrated a good awareness of the associated risks and that the SIRO and security team consider the risks to be sufficiently mitigated at the current level of functionality offered by the service within the current level of private beta rollout. As this project is part of a wider immigration related programme it would be advisable to include consultation with other government departments on the broader topic of national identity management. The increased roll out of a public beta would bring with it greater visibility and risk. More analysis of potential misuse cases at the employer may highlight the need to have greater controls over how the claimed identity is tied to the real-world identity, not just the permit number. Further consultation with legal and privacy experts might bring greater clarity to the issue of whether the current controls sufficiently protect the user under applicable data protection law. The team are considering ways to enhance identity assurance and this should be prioritised before the service is rolled out to a wider public or any increase in service functionality is deployed.
The team have acted on their wish to share their source code to the wider community. They do publish to a public repository. However, to date this is restricted to UI code as there may be some restrictions in terms of security concerns preventing them from sharing some of the code. Additionally the team does not yet have a defined way of accepting contributions or responding to comments on their code from the wider community. A recommendation was to push for improvements on both these issues and the service team seemed very willing to act on this.
GOV.UK Notify is already used by the service and the service team have plans to further extend the use of this common government platform. The team had previously considered use of GOV.UK Verify but decided that it wasn’t a good fit with the user group they were dealing with, foreign nationals. Reuse and learning lessons across the portfolio has been a strong point for this service team as they are among the first to use the person centric data platform and were able to make recommendations to the data team. They were also key to bringing changes to the underlying status checking engine.
The service team is able to test in like for like environments and employs a range of automated testing (unit, non-/functional, ATs and Accessibility testing). They have improved their capability to test against realistic data.
The underlying IPT platform does provide the service team with high SLAs for availability and resilience. The team have also developed plans for if the service goes offline in terms of continuing to provide a service to users. They have a service unavailable page and during a ‘bedding-in period’ the service will run in parallel with the existing BRP status check service, giving users a full-back option. The service team accept that they could do more to flesh out their service continuity plans for these scenarios.
Design
The scope of the MVPs for beta roll out has been well considered, and the team has a good plan for how additional features will be added, and how both services should integrate with GOV.UK content. The content audit raised some concerns about title clashes with current content - Check if someone can work in the UK’, they have already done a lot of content analysis and are aware of these issues themselves, and what they might be able to do about them. They have also spotted gaps in the mainstream guidance targeting employees, and have drafted and tested this guidance already. They will be iterating and testing further and have a plan to join up with other content redesign work across the Home Office.
The team will also be participating in the cross gov service community around employing people and working towards including their services within step by step navigation, and have already got some ideas for how this might apply to their services. It’s really great that they have thought so much about the end to end user journeys that involve their services, and what and how they might be improved.
The design of both services has gone through many iterations despite the relatively condensed time they have had to test it, and has now been updated to better follow both the internal patterns from the Home Office’s design team, and cross government patterns.
The team have worked hard to find a balance between usability and security, and in particular have managed to work with policy to reduce or take out questions that users found difficult to answer. For example they discovered that nationality information isn’t needed by employers and so wasn’t needed in the employer view of someone’s visa status. They will also be able to introduce more functionality such as the “manage share history” options when they introduce 2 factor authentication.
The services are easy for digital savvy users to get through, and the team have a good support model in place for helping low digital users through the service, although they are aware from user research how unlikely it is that low digital users are to use the online service at all. This research raises concerns around BRP cards being retired in favour of digital only services, as the team has very strong evidence that this would cause low digital users a lot of issues. This is something that needs careful consideration with the drive to convert more services to digital and potentially remove their physical counterparts - that digital by default doesn’t mean 100% digital.
Overall the team impressed by the pragmatic approach to scoping their MVPs for Beta, and the amount of thought and iteration that has gone into the content and interaction design in such a short period of time.
Analytics
The team presented a robust and well-considered approach to measuring the success of the service, measuring not just the mandatory KPIs but also considering additional considerations such as transaction speed and impact on the underlying system.
They are combining evidence from their Analytics service with offline data from their Assisted Digital provider, and qualitative feedback from their Beta survey. Overall their approach appeared well-considered and likely to provide valuable insight to inform further iterations.
Recommendations
To pass the next assessment, the service team must:
- Exercise significant care to include a wider range of users, particularly with low digital skills, in ongoing user research, to ensure that the service meets their needs.
- Ensure that the strong evidence of preference for a physical card that the team have found is taken into account before any decision is taken to remove or replace it. Removing the card without effective mitigation could have a significant impact on vulnerable users.
- Take appropriate steps to ensure the team is actively working in the open, including removing existing corporate barriers to releasing back-end code (with suitable security precautions), and enable contributions from outside the team (again, with appropriate checks in place).
- Address outstanding issues identified in the service content review, and continue to improve the wider service journey, particularly entry points from GOV.UK pages, and the interaction with related services from Home Office or other government departments.
-
The panel are concerned about the security and privacy risks identified in the service, which must be resolved before it goes into public Beta. The team explained that they were considering ways to improve their identity assurance, and this work should be progressed before release to a wider public audience. This work is being carried out by the team in parallel to the service going into public beta including the following actions towards meeting point 7:
- Further analysis of potential misuse cases at the employer, and consider additional controls over how the claimed identity is tied to the real-world identity, not just the permit number.
- Further consultation with legal and privacy experts to ensure the user is sufficiently protected under applicable data protection law.
- Demonstrating progress against these critical concerns in a ‘technology session’ with representatives from Home Office, GDS Consulting Technical Architects, and if possible representatives from NCSC to address wider ‘national identity management’ issues.
The service team should also:
- Participate in the cross gov service community around ‘employing people’ and working towards including their services within step by step navigation
- Reduce the impact on users when updates are deployed, removing downtime wherever possible.
- Further develop the existing plans for service unavailability, to ensure that where the service is unavailable, there is a clear understanding for users in the event of unexpected downtime.
Next Steps
You should follow the recommendations made in this report before arranging your next assessment.
This service now has permission to launch on a GOV.UK service domain. These instructions explain how to set up your *.service.gov.uk domain.
Submit feedback
Submit feedback about your assessment.
Get advice and guidance
The team can get advice and guidance on the next stage of development by:
- searching the Government Service Design Manual
- asking the cross-government slack community
- contacting the Service Assessment team