https://dataingovernment.blog.gov.uk/registered-traveller-service-assessment/
Registered Traveller – Service Assessment
E-passport gates are a secure and convenient self-service alternative to the conventional border control process. The registered traveller scheme will provide scheme members the facility to use the e-passport gates where they have made an online application prior to travel.
https://www.gov.uk/transformation/apply-registered-traveller
Department:
Home Office
Date of Assessment:
13/12/2013
Moving to:
Private Beta
Result:
Met
Lead Assessor:
A. Greenway
Service Manager:
J. Brady
Digital Leader:
M. Parsons
Assessment report
The Registered Traveller service was seeking permission to continue development as it moves from Alpha to Private Beta.
Outcome of service assessment
After reviewing the assessment report, the Government Digital Service (GDS) have concluded Registered Traveller has shown sufficient progress and evidence of meeting the pre-April 2014 criteria and should proceed to Private Beta. However, there are number of areas for the team to make significant progress on before the service will be ready to launch as a public beta on GOV.UK.
Recommendations
The Registered Traveller service has clearly made some real steps forward from the initial pilot phase, and both the service and caseworker tool are strong platforms for the development of a good service. Although the points that follow are largely focused on improvements for the beta, GDS want to recognise here that a lot of positive things have happened already.
1. The service is meeting user needs has done extensive user testing with real users.
The alpha service has had some user testing, but relatively little formal work at this stage. For a beta, GDS would expect the service and caseworking tool to have been tested end-to-end with a much larger sample of representative users. The team’s addition of a user testing expert is a good step in the right direction. More testing is essential for underpinning the project’s approach to other areas where there is more to do for beta, such as analysis, assisted digital approaches, performance benchmarks, and iteration based on user feedback.
The look and feel of the service was good for an alpha, though some of the content was jargon heavy and very long. GDS would expect the team to look at this issue as part of their user testing, and point to that evidence when working with policy colleagues to ensure that user experience rather than business norms informs the language used in the service and the caseworking tool.
Both the service and caseworking tool should ensure sufficient accessibility testing is carried out.
Before it launches as a public beta, the service should make provision for carrying out A/B testing on the live service.
2. The service can be iteratively improved on a very frequent basis
The Registered Traveller service is aware that it has capability gaps in web ops and technical testing that will need to be addressed. The current management structure has allowed the team to flourish without being encumbered by excessive governance and process. However, GDS would encourage the team to ensure that the Service Manager role in particular is kept under review as the service expands and becomes operational - the role will be a challenging and increasingly technical one, and having continuity from build phases through to operational service will be important.
The Registered Traveller service should conduct some analysis on the technical changes they may need to accommodate in the future and ensure they have the systems / capability to act on them.
The Registered Traveller service should push strongly to make as much of the service and caseworking tool’s code open, or provide a very strong justification why specific areas should not be.
The Registered Traveller service needs to ensure it has the analytical tools and user research data to feed into the iterative development process; this is there at an early stage, but GDS would expect it to be much more extensive by public beta.
3. The service has taken appropriate action based on findings to ensure the service is safe.
It’s unclear what IL-level system will ultimately be: GDS recommend starting these conversations early, especially because retention policy isn’t yet known. This is not a blocker now but needs to be addressed for the beta.
From the assessment it seems the system is reliant on load balancing for distributing load and recovering from errors - the Registered Traveller service need to better plan for loss of components or total loss of connectivity. This is not a blocker now but needs to be addressed for the beta.
The use of email to connect systems is fragile and should be looked at before public beta. It’s also a single point of failure that’s subject to trivial denial of service if the email address was to be discovered.
The team need to have a robust plan for dealing with contingency, particularly in terms of email. The current process flow is reliant on relatively fragile email steps, and the team must have fail-safes to cover dataloss, etc.
4. KPIs, Assisted Digital, etc
The Registered Traveller service must establish performance targets / benchmarks, using (as a minimum) the four KPIs set out in the service standard.
We understand Registered Traveller’s view is that there is little requirement for assisted digital provision because the service is aimed at users from overseas. GDS recommend further analysis working with GDS and on the basis of user testing, as assisted digital provision may enable more people to register.
At end of the new service, the user receives confirmation, reference number, email and PDF of application. The team needs to ensure there is an incentive for users to go through to the 'transaction done' page on GOV.UK, to ensure user satisfaction and transaction completion data can be captured.
Registered Traveller mentioned difficulties of distinguishing between those who drop out because they are ineligible for the scheme, and those who drop out for other reasons. A solution to consider is separating eligibility from the transaction itself, so that only eligible users can start a transaction. Eligibility criteria could be contained in a separate smart answer, although there are possible problems with tying the smart answer to the service catalogue.
The Registered Traveller service should develop a method of calculating cost per transaction, covering the cost of receiving applications, through the validation process, up to accepting a traveller onto the scheme.
Next Steps
This service has been given approval to launch as a Private Beta service.
