100% task completion on a mission-critical trade platform
Before designing a single screen, we mapped every dependency. That decision shaped everything that followed.
The platform
This was a trade logistics platform used by freight forwarders, customs agents, and traders to declare goods in transit across international borders. The service handled complex, multi-party declarations, each one containing nested data structures, conditional logic, and interdependencies that could change based on a user’s answers at any point in the journey.
The stakes were high. Errors in declarations have real consequences: delays, fines, goods held at border. The users were professionals who knew the domain, but the interface was making their expertise irrelevant by failing them at the interaction level.
We were brought in as Phase 5 of the programme: a significant redesign of the most complex parts of the service, working alongside a development team building the live product in parallel.
Before the UI: mapping the system
The first thing we did was not open a design tool. Before any wireframe, any component, any prototype, we built two artefacts that would guide every decision that followed.
The first was a service map: a landscape exploration of the entire ecosystem. Who the users were, what they needed to accomplish, how the service connected to upstream and downstream systems, what the regulatory dependencies were. This gave the whole team a shared picture of the territory before anyone started drawing paths through it.
The second was The Model: a formal diagram of every information dependency and branching condition in the service. Which questions triggered which others. Which answers changed what a user would see later. Where conditional logic meant two users completing the “same” journey might follow entirely different paths.
The Model became the guide to building an accurate, fully functional prototype. Without it, we would have been prototyping assumptions rather than the actual service. With it, every prototype screen was grounded in the real dependency structure.
This work, invisible to anyone outside the team, was the most important design work on the project.
Start with the riskiest assumption
Once we understood the system, we deliberately went to the hardest problem first.
The service required users to declare goods in grouped structures called house consignments, each one containing items, parties, documents, and routes, nested within a master declaration. One declaration could contain multiple house consignments. Each house consignment had its own internal dependencies.
This was the riskiest assumption in the service: that users could understand and navigate a deeply nested data structure while also managing complex relationship logic. If this part of the journey failed, everything built around it was compromised.
So we started here. We prototyped the house consignment journey in the first sprint, took it to research, and iterated. Starting with the hardest problem meant that when it eventually held up in testing, we had confidence the rest of the service would too.
The iteration that got to 100%
Midway through the programme, we encountered a specific problem that illustrates exactly how this kind of design work goes.
At the start of the declaration journey, after the user has answered five to seven questions, the service reaches a point of no return. The user cannot amend previously confirmed information. This is a genuine constraint of the underlying system, not a design choice. The question was: how do you communicate that to a user who has just spent ten minutes providing data?
Round one: We added a paragraph beneath the relevant heading explaining the constraint. Clear, accurate, appropriately placed. Six out of six users in testing missed it entirely. Not one person noticed.
Round two: We escalated to warning text: bold, with a prominent icon, styled to stand out from the surrounding content. Five out of six users missed it. One noticed. One.
Round three: We replaced it with a full notification banner, the kind used for high-priority information, styled in an experimental blue that stood outside the normal palette. Six out of six users saw it. Task completion: 100%.
The lesson was precise: the design failed twice before it succeeded. Not because the information was wrong, but because the visual weight wasn’t earning the attention the content needed. Focusing on the macro interaction; the gestalt of the page rather than an individual element, gave us the solution.
This is what iteration grounded in research looks like. Not opinion, not preference, not gut feel. Data, then change, then test again.
Rigour as standard
Two things we established as standards across the prototype work.
Validation in prototypes. The instinct on many teams is to skip validation: it’s extra work, and prototypes are supposed to be quick. We pushed back on this. A prototype without validation cannot accurately test branching logic; without branching, you’re not testing the service, you’re testing a simplified version of it. We implemented a four-level validation framework: branching logic, data passing between pages, conditional display logic, and proper error handling. The result was a prototype that behaved like the real service, which meant research findings were trustworthy.
A/B testing on dashboards. For the save-and-retrieve functionality, we built multiple dashboard variants and created a dedicated research landing page to test them. Users navigated to whichever variant they were assigned. The results informed a design decision that would have otherwise been made on instinct.
The complexity of routes
The routes sub-journey was the final major challenge, and in some ways the most technically demanding prototype work of the project.
The journey involved selecting and configuring customs routes: where the goods enter, where they exit, via which intermediary points. The options were not linear. Different combinations of route type, transport mode, and border crossing points created a decision tree with dozens of valid paths, each producing different subsequent screens.
We modelled this dependency tree first (see above), then built the prototype routing logic using conditional arrays and nested if/else statements in the route configuration. When the prototype was working accurately, we took it to research. When research confirmed it held up, we handed the logic over to the development team as a reference implementation.
Two designers and a developer pair-programmed the routing logic together in a recorded session that became a reference resource for other teams working on similar problems.
Outcome
The declaration journey: the most complex, dependency-heavy, multi-party journey in the service, achieved a 100% task completion rate in user research.
The service map and dependency model became team-wide reference documents, consulted throughout the programme. The validation framework was adopted by other prototype teams. The pair-programming session recording was shared across the design community.
The work ran from landscape mapping in April 2022 through to completion in September 2022: five months from first principles to a tested, research-validated prototype of a mission-critical system.