In my last post I discussed the FCO’s legalisation service and our plans to build a new digital service. So what have we done so far?
After getting our spending controls approval, we used the Digital Services Framework to find development resources and appointed Informed Solutions to work with us.
For development we’ve been following the agile scrum framework, with a daily standup conducted over the phone, and have rotated the sprint review and planning meetings between our respective team offices in Milton Keynes, London and Altrincham. We are normally all in the same place for 1 or 2 days per week, and are using Jira to manage the technical work on the project. We’ve also started using the useful Jira Capture plugin to record test sessions and easily annotate and post screenshots directly to a ticket, capturing all the environment variables automatically. At the end of each sprint we are sharing our code in the open on the FCO github account.
Technically, the team have been evaluating a few options for how to build the product, and settled on an architecture of loosely coupled microservices in conjunction with a message queue. After some deliberation, the service will be built using the node.js web application framework and a PostgreSQL relational database. As the FCO has some existing code written in node.js, this decision will limit technical proliferation and simplify maintenance. We also agreed some design principles set out by our technical architect Matt, which helped guide these kind of decisions:
- Adopt open modular architecture allowing components and services to be swapped in or out thus avoiding vendor lock-in
- Actively identify opportunities for reuse of code within FCO and wider government
- Use open source technologies as standard and release all developed code under the GNU General Public Licence into a publicly visible GitHub repository
- Adopt common development, configuration and release pipeline tooling in line with other FCO services where applicable
- Develop code using a Progressive Enhancement approach to ensure an appropriate and usable experience for all users of the service
To gain a deeper understanding of the nitty gritty of the legalisation service, at the outset we kicked off a series of internal workshops. We began by mapping out the rules of which document formats can be legalised, which formats are accepted, and whether they need to be certified by a notary. In another workshop we looked at the postal options – which postal addresses should be used depending on the country of origin, which despatch options are available based on the return address, and whether any of these options could or should change. We then moved on to exploring what is the minimal, essential information the user needs to know by the end of the transaction. We also looked at what the key differences are between the services offered and, even, what those services should be called.
In parallel, we began prototyping designs for the postal and premium business services, using the GOV.UK frontend toolkit. This toolkit allows us to quickly iterate, test and validate designs, without building too much code which will be thrown away. To illustrate this, to date we have built three versions of our service choice page, three versions of the final confirmation page and are now up to our seventeenth variant of our document checking service – the trickiest part of the service from a design perspective, which required lots of exploration. It has proven fast and easy to knock out a few versions for discussion in one day, and even the less technical members of the team (ahem!) have been able to update copy directly and build a couple of variants. As ever, being able to try a working prototype in a browser quickly gives you a feel for whether the solution is worth pursuing, more effectively than a mockup will. Consequently, several of the variants saw the light for just 1 or 2 hours – failing fast, before much time was invested in them.
A key focus of the alpha phase is to understand your users’ needs and validate your direction, so we have thrown ourselves into a wide range of user research, building on the foundation set during the discovery phase. By the time we were ready for our alpha assessment after 7 weeks we had racked up the following numbers:
- 3 focus groups with 15 people
- 25 interviews
- 479 respondents to our customer survey about modernisation of the service
- 174 legalisation respondents in the quarterly consular transactional survey
- 5 remote usability tests with 24 people
- 2 pop up usability tests with 13 people, at our counters in London and Milton Keynes
- 2 card sorting tests with 37 people
- 1,125 individual responses analysed from the anonymous feedback collected on the existing GOV.UK legalisation pages
We also looked at the Google Analytics data for the existing pages on GOV.UK, to understand the browsers used and the paths taken. Currently 68% of the traffic is from desktop users, with 22% accessing the pages on a mobile phone and 10% on a tablet. And without going into too much detail, when looking at search referrals it became clear that not everyone who visits the legalisation pages is interested in legalising documents.
All the research has given us crucial insights into the user needs of all our different customer groups – the postal users, premium service users, and Milton Keynes drop off service users; the first-timers and the regulars; the individual applicants, business employees and notaries. We have been very encouraged by initial feedback on our work, especially from the notaries and business users who had signalled very clearly the need for speed and simplicity, without which they would not be likely to adopt the service. We have also been able to make clearly guided decisions on what not to do, such as requiring all users to enter the name of the signatory on their document, or mandating details about the country of use. We need the digital service to help not hinder, and meet user needs not just business needs, and are on track for that so far.
Follow Mark at @markbarlow