ORU - blog header

How CYB’s multidisciplinary approach built new services in Government

Following the launch of services for the FCDO’s Overseas Registration Unit, CYB’s team explains how success was built on research, design and open source technology
Picture of cyb-logo

Caution Your Blast

Team

24 Oct 2023

The partnership of Caution Your Blast Ltd (CYB) and the Foreign, Commonwealth and Development Office (FCDO) has seen us work together on the digital transformation of UK Government digital services - everything from e-Apostille, which is changing the face of the legalisation industry, to Emergency Travel Documents that help Brits abroad who’ve lost their passports. 

Our latest successful service launch centred on the digitising of paper services for the Overseas Registration Unit (ORU) – the place where British nationals go to officially register a birth or death that happens abroad. CYB helped to build new online services to make the process easier and quicker for users. 

Three members of the CYB team write about how our multidisciplinary approach – using research, design and open source technology - led to a successful project. 

How research ensured value for money – Sarah Hill, User Researcher

Starting this work, we did what we always do - took our lead from the CYB research philosophy to help decide the best course of action. To begin, we evaluated the business problem to solve. At first glance, we had to improve a cumbersome paper-based form and turn it into a digital service. However, through some business analysis we quickly uncovered how low volume this service really is - last year there were around 2,500 births and 500 deaths registered abroad - and working through the traditional full Agile software development processes would have been inefficient and not cost-effective for the FCDO. 

Further to this, the problem we were solving was a well-trodden path - CYB has digitised countless government services, taking unusable paper forms and turning them into exceptional digital services. This meant that the business problem was more nuanced than we originally thought; how might we produce a low-volume digital service in the most efficient and cost-effective way?

We had a plethora of data that we brought together including survey responses and verbatim quotes, which meant we could reduce the cost of development by leveraging our pre-existing insights to understand the problem for users (high problem clarity). We knew the most cost-effective way to solve this problem was a digital service (medium solution availability) - however, the specific ORU form questions became our riskiest solution. For instance, what questions should we ask to determine a definitive list of documents someone needed to support their application? What this meant was that the quickest way to tackle our research question was to jump straight into prototyping a digital form (generative research). 

By jumping into prototyping our solution, we could do two things at once: 

  1. gather more context from previous users

  2. simultaneously test the most ORU-specific questions in our prototype

This sped up the research design process tremendously, allowing us to uncover more user needs, and importantly progress our solution at the same time. 

A further key to success was the team's engagement in the user research. First hand observations gave the team a quick awareness of any usability problems. Setting up an effective research cadence also allowed for fast learning and iteration. Each round of research involved a prototype design freeze - keeping the team aligned and ensuring clarity over research objectives to maximise the usefulness of the sessions. At the same time it reduced potential bottlenecks from research - with one version of the prototype frozen for testing, design and development could continue on areas outside the research focus. 

How previous prototyping led to efficiency - Alvin Chan, Service Designer

In 6 months, we built 2 new digital services that allow British nationals to register a birth or death abroad. It meant we had to be really efficient. We built prototypes that were ready to be user tested in a short timespan. We utilised the same tools that produced the Prove Your Eligibility services, which also include tried and tested design patterns that were tested well by British nationals. This saved us significant time and costs as we did not need to build a prototype from scratch and user test any new interactions for the service. 

This also meant: 

  • there was a regular cycle between service design and user research

  • prototypes were developed every sprint

  • user testing of the prototype for the next sprint would follow naturally, and so on.

We uncovered lots of valuable user feedback which informed our design iterations, all to make it more user-friendly and straightforward for people to use.

We reviewed what information and documents were required from the old services, and questioned the possibility of removing them, to create services that are as light and compact to build, but also for users to use. We worked closely with caseworker staff to challenge ourselves and see what can be removed. As a result, we hope to reduce application delays as some requirements are now no longer needed.

The key benefit is that we can scale what we built for the first prototype, and apply it for the second service prototype as people go through a very similar online form filling process. This is a proven method for low-volume paper services to be digitalised in the future with the level of detail required for larger services.

The advantages of using our own open source tech - Luke Zigler, Full Stack Developer 

When working with a government body, it’s really important to think about how we can ensure other departments can benefit from the work we do. With this in mind, we find ourselves time and again turning to open source technologies to integrate and develop on. By using these technologies, not only do we make our lives easier by having a good base to work from, but we can also pay forward any improvements we make to other users. This project presented us with a perfect opportunity to do just that, giving us the chance to use the XGovFormBuilder, one of our very own open source projects.

For those who haven’t heard of the XGovFormBuilder before, it’s a form prototyping and building tool created to help government departments to develop online forms for their services that can be used by the public. The form builder took a lot of the headaches out of prototyping, allowing dev, service design, and user research to work closely with one another, taking the ambiguity out of what could be done technically and giving realistic expectations of what we could achieve. This saved us from having to deal with potential weeks of syncing between the team, and back and forth while trying to align on the implementation.

With other projects, we’ve had more room to add extra features than in this one. However, this project gave us the chance to see the limits of what the form builder can do. Due to the nature of the service, registering a birth abroad can become very complicated when trying to prove that your child is eligible for the service. Previously the onus has been put on the user to parse a long list of documents to work out whether their child is eligible, and what documents they need to provide. This isn’t only a painful user experience, but also prone to error. However, with the flexibility afforded to us by the form builder, we’ve been able to finetune this process, so that the system does all the thinking for the user.

That’s not to say we weren’t able to make some much anticipated improvements to the form builder; the odd bug fix here and there were possible, with the headline upgrade being a brand new submission queue system. This system is completely optional to enable, but allows services to capture the user’s submission, and process that data in parallel. Not only does this create a failsafe in the event your back office logic fails, keeping it safe for later, but it also means the user gets to experience a smooth end-to-end journey without being worried by system failures that don’t affect them.

As always, we’ll continue trying to improve the open source systems we’ve developed, and there are some key learnings we gained from how the form builder performed on this project to keep us moving forward to a more efficient, easier to use, and more flexible product for services to use far into the future.