In the continuing series on lessons learned within the Transformation Programme Richard Milner, Transformation Lead in GDS, looks at the ups and downs of delivering Registered Traveller as a digital by default service.
Registered Traveller is a way for frequent travellers coming to the UK to easily apply to use e-passport gates, cutting their time queuing at airports. A thing that sounds simple on the face of it but far from simple in practice.
The good stuff
First the things that have gone well. One of Registered Traveller’s top achievements has been the promotion of putting user needs and user-centered design first, whilst also remaining compatible with Border Force's mandate of securing the UK border. Security and usability are often seen as opposing forces - one is often sacrificed at the expense of the other - but the team designed a service which has satisfied both concerns. In our feedback users have said they find it very easy to sign up and use the service, all while the system’s interfaces and backend case-working have met the stringent security requirements of the Home Office.
Initially the team’s solution designs were blocked at a security review. This forced a significant redesign of several components, which unsurprisingly slowed down delivery. To pass the review and deliver effectively against security needs, we embedded a security expert within the team for one or two days every week. This allowed designs and solutions to be reviewed, adjusted and tested iteratively. We discovered the importance of getting frequent advice from our security people, and getting them to collaborate directly with the team. Our lesson learned in this case? Don’t save your security reviews until the end!
Changing policy was a whole different challenge. The service’s initial eligibility criteria were set back in April 2013, and the pilot service was open to very limited numbers, in order to test its viability. Even once the service had proved its worth it took a long time to get agreement to remove some of the restrictions and expand it. This obviously caused frustration for many potential users who had heard of the service but were excluded from joining. Hopefully those frustrations are gone now the service is live.
While some policy changes were expected, unanticipated policy changes have also been a challenge. The team were asked if they could open up the service to diplomats from selected countries. Because of the team’s agile approach to delivery they were able to do a rapid re-prioritisation of work to accommodate these changes. Happily they were put into the live service quickly and effectively.
One final significant achievement worth mentioning are the terms and conditions. A dry subject perhaps, aptly demonstrated by the first draft which was a lengthy and typically legalese-sounding wall of text. The team’s business representatives worked closely with the GDS content team to rewrite the Ts&Cs and the results were good. They became something much more concise and understandable, and hopefully something people will really read. If only all terms and conditions could be so tidy!
So what are our main lessons learned? Work security in from the beginning, stay flexible to change, and simple is usually best. By sticking to this we’ve received great user feedback, and the team feel energised from knowing we are delivering an excellent service. Hopefully you’ll agree that our results with Registered Traveller show this approach can work.
You can find the Registered Traveller service here.