Geoff Bell

Project Overview

In 2020, the UK government announced plans to reform the alcohol duty system, with origins dating back to 1643 Excise Ordinance levied by the government in the English Civil War, the current system was viewed as extremely complicated and outdated. As part of this reform, a new digital service was planned to help simplify the current method for registering and being approved for producing alcohol, as well as declaring and paying alcohol duty.

Discovery

Starting in August 2022, the digital service began with a discovery phase, working in an agile multi-functional team, including developers, a user researcher, performance analyst, delivery manager and product manager. The discovery phase involved workshops with stakeholders to understand business requirements, as well as some preliminary user research sessions to understand users of the current service. This helped identify pain points and user needs.

Working as part of this team, we began to formulate some ideas of how the service could work to fulfil both the business requirements and the needs of the users.

Alpha

During the Alpha phase, I designed a user flow and then built a prototype using the GOV.UK Prototype Kit in order to test our hypotheses with users. Due to another project being funded, registeration for approvals was removed from my team's scope.

We then began to delve in to the returns journey for users. The returns journey was designed to make things as simply as possible for users, relying on the data we had of the alcohol type that they would be approved to produce, we could populate the service dynamically, so that only relevant options were available to them.

As per the business requirements, we designed the user flow and prototype so that users would report each individual ABV% (alcohol by volume) of the alcohol they were producing. i.e. if a user produced two beers at 4.5% and 5.4%, they would need to report the volumes produced individually rather than combined, despite the tax rate being the same.

The service would ask the user to input the ABV of the product they were reporting and based on this and their approval type, would work out the relevant tax rates that could be applicable and present these back to the user to select the correct one. Once the user had selected the correct one and inputted the production volume, the service would then work out the total of pure alcohol and multiple this by the applicable tax rate, meaning that the user didn't need to do any of the calculations.

Initial research showed that this was fairly straight forward for the users that we had tested with, however, it became apparent that larger producers may be required to input hundreds of lines of data reporting this way. An API was discussed but this wasn't deemed to be viable at this point in time. The team discussed other ways we could try and mitigate the amount of data needed and a file upload option was discussed.

Testing of the file upload showed that it met the needs of the larger producers and allowed them to input large quantities of data into the service a lot faster than inputting it individually, however, they would still need to do a lot of work on their side to ensure the file they uploaded was correct.

We recommended changing the way that users were required to report to a simpler method and this was fed back to the business, but it was decided that the individual ABVs were what the business wanted to capture at this point.

Beta

After entering the Beta phase of the project, stakeholders from the policy team asked the digital team for further feedback regarding the reporting of indiviudal ABVs and seemed open to changing the reporting requirements. From the evidence we had collected, we knew that we could simplify the journey for users.

With the go-ahead from the Policy team, I was able to quickly iterate a simplified design and get this in the prototype to enable some high-level user research. The feedback received was positive and favoured the new approach over the previous one. Presenting this to stakeholders across the business, we were able to get buy-in across the board and proceeded to implement the new process. Asking users to group together their alcohol within the relevant tax bandings meant there was less repetition nad that users could complete the journey a lot faster.

There were also some other areas of the journey that we were able to get changed based on user research findings: the spoilt and spirits production sections were also streamlined, with problematic data items dropped to enable users to complete these sections much faster as well.

Entering Private Beta, we were confident that users would be able to successfully complete the journey. Initial sessions were completed as a 'hand-holding' session, with a team member available to help assist users if there were any issues. A few technical issues were encountered and resolved, but ultimately during the course of Private Beta, all users were able to complete their returns and make a payment successfully, with the average time decreasing as we progressed through the course of Private Beta.

Feedback & learnings

This project was quite a complex one, especially because of the intricacies of alcohol duty and the tax rates involved, however, it was an enjoyable project where I was able to iterate my designs frequently based on the research findings and user feedback. I was also able to improve my presenting skills by taking part in fortnightly 'Show & Tells' where the digital team presented to stakeholders the work that we'd completed during that sprint. As part of working within government, assessments are completed at the end of each project phase, it was in these that I was able to provide the rationale for my design decisions, which were backed up by evidence.