HMRC

In Discovery, we created a problem statment which defined the current challenges to exporters we intended to solve, and the resulting positive outcomes such as:

• Understanding licence and commodity code rules before declaring goods to export - less delays in export of goods
• Legally compliant paperwork through increased compliance - less concern about audits
• Completing declarations quickly - happy customers who pay for goods more quickly
• Understanding issues with declarations - problems are solved more quickly, meaning less delays and happier customers
• Understanding why their goods have been held at a port - again problems are understood and resolved more quickly, which is better for both exporters and port authorities dealing with consignments

At the start of Discovery, we spent some time to benchmark the current service ('NESWeb', pictured below) for making export declarations out of the UK. We found a number of barriers to trade.
For example, businesses needed to create their own 'how to' guides in order to perform basic tasks due to the complexity of the UI, and the ambiguity of the Content Design.

We also found that the service timed out very quickly, losing all the user's inputted data, and that key functionality such as goods licencing, error prevention, and error recovery was very problematic.
Users would often receive emails with blank titles and DAT file includes. These contained error codes which had to be looked up on GOV.UK in order to translate the nature of a problem with their declaration. In effect, users often ended up phoning the National Clearance Hub in Manchester to understand and resolve the issue.

In a Brexit scenario, with a huge increase in the number of export declarations due to the UK moving away from a frictionless borders arrangement, the implications of these inefficiences are substantial.

We also conducted contextual enquiries at numerous Freight Forwarders - firms needed self-produced user manuals and tariff reference guides to use existing HMRC export declaration service.

The photo below is from a contextual enquiry at Dental firm in Barnsley - traders and businesses often use 3rd party software due to the complexity and poor user experience of existing HMRC export declaration service. This is a barrier to trade for SME's in particular, because such firms often have tight profit margins while 3rd party software licences can be expensive.

During Discovery, we mapped out the findings from the research sessions together in order to understand the end to end processes involved in exporting goods out of the UK.

Our role here was to turn the researching findings into visual assets for the team which could be easily understood and told the story of the user's everyday processes.

Towards the end of Discovery, we conducted a number of workshops to understand the themes, taxonomy and information architecture of the service. This included affinity mapping, card sorting and mind-mapping.

This mind-map represents the typical outputs from such sessions, and helped formalise the MVP vision at the end of Discovery. See 'MVP user flow' below.

We created primary, secondary and served personas based on our research findings. These formed the basis of the user needs, as described below.

Our research undercovered user needs for each persona, the primary global needs being:

• I need to know how much it will cost me to export my goods around the world
• I need to export my goods to my customers quickly and as cheap as possible
• I need to understand what to do and who to go to, to make an export
• I need help with understanding what documentation I need to get
• I need to understand how to submit an export declaration correctly

Discovery exit experience map - this image is blurred for security purposes.

Discovery exit MVP user flow

Iteration 1: Complex and long. Started with 'one thing per page' approach. This resulted in a 64-page export declaration user journey with multiple routing options. We also saw inefficient repetitive looping through long sections if, for example, users wished to add multiple kinds of goods to their declarations.

This image is blurred for security purposes.

Iteration 3: Reduced complexity and number of pages. We moved to 'one theme per page' approach and utilised a new 'Add to a List' pattern.

This pattern had been discussed as part of the HMRC Working Patterns Group. It allowed us to take a more system design orientated approach by creating short, independent lists of key items within a declaration which could be quickly skipped or repeated.
This reduced the time taken to complete a declaration, which is a key user need for the service.

This image is also blurred for security purposes.

Sketches don't need to be perfect, but they do need to rapidly communicate different approaches within pages and interactions to facilitate mutual understanding and agreement.

A trader's dashboard page with tabbed tabular data displaying recently created export declarations.

A trader adding a list of consignors within an export declaration.

Combination of contextual enquiries into 3rd party software solutions, their export processes and of course scenario-based testing of design hypotheses within prototype iterations;
Hypothesise, test, learn, iterate.

The 'Get an EORI number' service is now live on GOV.UK.
This service allows importers and exporters to register with HMRC's Customs department in order to start moving goods in and out of the EU.

These traders may have increased costs and delays if they do not get an EORI number. For example, if HMRC cannot clear their goods, they may have to pay storage fees.

As-is service map - sketched with team and refined in Photoshop

Experience map with high-level user needs and personas

Personas

User testing analysis

Start page prototype