The seller carries the audit risk. The proof sits with everyone else.

The challenge

Vertex was exploring proof of delivery as a new use case for taXchain, an acquired platform for managing trade documentation. When a business sells goods across borders within the EU, it needs evidence that the goods arrived to support its exemption from value-added tax (VAT). Missing documents can leave the seller facing an unexpected tax bill during an audit.

The seller carries that risk, but much of the evidence sits elsewhere: buyers confirm receipt, transport companies hold delivery records, and business systems hold order and shipment information. The evidence available also depends on who arranged the transport. A delivery can be complete while the documentation needed to support it is still missing.

The challenge was to connect those separate contributions into a process people could follow. Sellers needed visibility into outstanding evidence, buyers needed a straightforward way to provide it, and auditors needed a record they could review. The people supplying the documents did not necessarily share the seller's urgency.

My contribution

I was the sole designer working with the platform's product owner and a small development team. The product owners supplied the regulatory requirements and high-level demo scenarios. My role was to work out how those scenarios would unfold for the people using the product, including what the system could handle automatically and where a person needed to act.

A delivery can be complete while its evidence is not. I started with a multi-stakeholder journey map connecting the parties and their systems, including transport companies and the seller's enterprise resource planning (ERP) system, which holds order and delivery information. Mapping the handoffs showed two things moving at different speeds: the delivery itself, and the collection of evidence that proves it. Nothing in the demo scenarios had separated them, and the separation turned out to organize the whole product.

Three roles, three views. Personas for sellers, buyers and auditors clarified their different motivations, responsibilities and information needs. Sellers needed to see which records were progressing and which were waiting for documents. Buyers needed enough shipment context to confirm receipt and understand what evidence to provide. Auditors needed to examine the documents and history together. Each interface made its role's responsibilities clear without asking anyone to navigate the whole process.

What happens when the evidence doesn't arrive. I translated the demo scenarios into six user stories and step-by-step storyboards, connecting user actions, system responses and screens: record creation, evidence submission, missing documents, follow-up requests, multiple deliveries and audit review. The missing-evidence path got the most attention: how the seller would see the gap, send another request and track the response. Buyers could handle several outstanding deliveries from one entry point.

Prototypes as the build reference. I built interactive Figma Make prototypes for the three user groups. They made the proposed experience tangible for the development team: the information each person would see, the actions available to them and the status changes that followed. Together with the storyboards, they were the concrete reference for building the conference demo.

Methods

• Requirements analysis and synthesis.
• Multi-stakeholder journey mapping across people and connected systems.
• Persona development focused on motivations and responsibilities.
• User stories and scenario storyboarding.
• Interaction design, including missing-information and recovery flows.
• Interactive prototyping in Figma Make.