A remote GDS alpha phase for the Department for Transport

The Road Freight Statistics team carry out surveys throughout the year to understand how hauliers move goods around, both within the UK and internationally.

There’s just one problem. Data collection is currently 100% offline, via paper-based letters and surveys.

Survey response rates look positive on the face of it (around 90% - it’s actually mandatory to complete the survey if you’re randomly selected to receive it). But in reality, far fewer of the completed surveys contain usable data, for reasons varying from incomplete or incorrectly filled out forms, to illegible handwriting.

At the same time, hauliers themselves not only find the process frustrating and time consuming, they don’t really have a clear understanding of why they’re being asked to return the data in the first place.

DfT undertook a Discovery phase in 2019 with Lagom Strategy which surfaced these issues and recommended the development of a digital service to simplify and improve the process for survey respondents, whilst also ensuring a marked improvement in the quality of data captured.

At the start of this year, we partnered with Lagom to progress the project through the next GDS phase, ‘Alpha’.

We came together as a multidisciplinary team of ten, spread across half as many locations. We ran the Alpha phase in sprints over an eight week period, focusing our effort on the single riskiest assumption of transitioning the Road Freight surveys to a digital service: that we’d improve the experience for the primary users, namely survey respondents.

The starting point for our work was to map the ‘as-is’ paper forms into a service blueprint that we could use to identify the pain points and opportunities for improvement. With this in place, we could begin the work of remodelling the end-to-end process using GDS design system patterns.

Alpha is all about trying out ideas, testing them with users, iterating - and most importantly not being afraid to throw things away if they don’t work! It’s a helpful method for incrementally shaping an effective solution, without the risk of becoming wedded to a particular approach.

To illustrate the point, our team made an early assumption (based on Discovery insights) that we could simplify the process if we allowed users to submit basic data - such as their business details - ahead of the date-specific survey window when they’d have to record their journey and cargo data. After prototyping it in the first sprint, we tested this concept of a ‘pre survey’ with users and quickly found that they were confused about why they were being asked for so much information ahead of the specific survey dates. Gaining this clear insight at an early stage allowed us to adapt quickly without having wasted time following a rabbit hole.

Using GOV.UK patterns enabled us to quickly create realistic prototypes which we were able to begin testing with users during the first sprint. Their feedback quickly revealed subtle design challenges in the digital workflow.

For example, on the paper forms it is easy for a user to leave a section blank if the questions don’t apply to them, and this is something the digital workflow also needs to allow. Unfortunately, it is just as easy for users to leave a section blank by mistake, and we need to prevent this from happening. Surprisingly, user testing showed that users preferred there to be an additional step where they could actively decide whether the detail in the next question was relevant to them or not - and if not skip to the next step of the survey.

We also identified opportunities to streamline the survey steps by dynamically adapting forms based on data already captured. For example, we can omit a question about trailers if we already know that the vehicle being driven can’t physically carry one.

Testing showed that in some cases, such as when specifying ‘cargo type’, users preferred to see all the available options as a single list of radio buttons on a longer page, rather than in a ‘neater’ dropdown form component. We also wanted to control the entry of information such as ‘shipping port’ by presenting a list of options to choose from rather than allowing free text entry, but in this case there are far too many to list out in full, so we created a new autosuggest component (which doesn’t exist in the GDS patterns).

One of the key advantages of moving to a digital service is the opportunity to exercise more control over the way data is entered to improve data quality. We had to strike a careful balance between putting sufficient validation in place to ensure accurate data entry, and not going too far - making the system feel stubborn and frustrating to use.

We worked on ideas for ‘soft’ validation that would give users helpful prompts: for example, by suggesting that a response might be incorrect. In this way we can encourage users to ‘sense check’ their answers without preventing them from proceeding to the next step or submitting their survey.

So, for example, by calculating the likely minimum and maximum possible distances for a journey between two postcode locations, the system can highlight an answer falling outside this range as a possible error. This is an easy way to catch and correct a possible typo, without limiting the user’s ability to record an unusual but legitimate value.

We’ve identified many ways in which a new digital service will improve the experience for hauliers, making the process quicker and easier for them whilst also ensuring more accurate and complete data capture. But the ultimate beneficiaries will be the teams who support users, process data and carry out statistical analysis in the Department for Transport, and we can potentially go even further for them by applying technologies like Machine Learning to automate even more of the process. This is particularly promising in relation to the categorisation of goods, which is currently coded to an EU mandated standard, called Eurostat. In the final sprint of Alpha, we carried out tests using sample data sets and were able to show that implementing this technology as part of the digital service would provide enough accuracy to ultimately reduce costs of staff time spent on manual categorisation.

Alpha was fast paced, but coming up for air after three sprints of design, development and user research to prepare for the assessment at the end of the 8 weeks was a great opportunity to reflect back over the work we’d done. In preparing for the assessment (which we passed!), we had to think critically about the insight we’d gained from testing and whether we’d validated our work enough to defend our solution. This in turn helped us develop a sense of what the priorities should be for the move into the Beta phase, and we’ll look forward to seeing how things evolve.