Ocean freight runs on annual fixed-price contracts that take months to negotiate. When the market moves, the contracts stop working, and the supply chain breaks.
Index-linked contracts solve this by tying rates to a market index, so pricing moves with the market instead of being locked in at the wrong moment. The mechanism works. The problem is that it's complex, unfamiliar to most of the industry, and built on commercial judgement calls that customers need to feel confident making.
My job was to design a product that made those judgement calls navigable rather than intimidating, and turn indexing from a niche capability into something customers across the market would adopt.
Add image: Index-linked vs fixed-rate pricing over time
Index-linked contracts move with the market. Fixed-rate contracts often don't.
Research & Discovery
I led discovery with the people closest to the problem: customer success managers, who spend the most time explaining indexing, and freight forwarders, who use the Simulator to validate the approach with their own customers. We also analysed how existing index-linked contracts in market were configured to understand which parameters customers were really using.
One insight kept surfacing: customers trusted Xeneta's data, but not always the mechanics behind it. They believed the benchmarks were accurate. They struggled to understand how an indexed price would actually behave over time, what triggered a rate adjustment, or how to defend the mechanism to their own stakeholders.
That reframed the work. Transparency mattered more than automation. The product needed to make complex pricing logic explainable, not hide it.
Add image: Research artefact, workshop output, or customer co-creation session
Customers trusted the data. The mechanics were the gap.
From research to product strategy
The workshops surfaced a more fundamental question than how to design any single screen. Customers were entering the world of index-linked contracts from completely different starting points. Some wanted to test the idea before committing. Some had already signed contracts externally and needed somewhere to operationalise them. Some were already running indexed contracts using Xeneta data and needed to monitor them.
I synthesised the research into a product architecture that mapped these journeys end to end: who the personas were, where they came in, and how the surfaces needed to connect. This became the artefact I used to align product, commercial, and engineering on what we were actually building and in what order.
Two decisions came out of it. The first was to launch a free, standalone simulator as the front door. Letting customers backtest the idea without commitment was the lowest-friction way to build understanding, and the simulator could prove value before any contract was on the table. The second was to design the simulator and the live contract manager as one connected system, so the trust built in simulation could carry into operation rather than being lost at handover.
The simulator is the surface this case study focuses on, and the one that won the award. It's also the surface that opened the door to everything else.
Add image: Product architecture diagram from workshop synthesis, showing personas, entry points, and four-stage product flow
A product architecture mapped from workshop research, showing how different customers enter the indexing journey and where the surfaces needed to connect.
Design Decisions
How trust gets built
I ran a workshop with one of the largest logistics service providers in the world, a company that already uses Xeneta's data and sells index-linked contracts to its own customers. The goal was to understand how they actually pitch and configure these contracts in the real world.
The most useful thing we learned had nothing to do with the product. Their sales teams don't sell indexing by handing customers a finished contract. They walk customers through the choices: which index to reference, how aggressive a discount to take, how often to re-rate, where to set the floor. The deliberate act of making those choices, together, is what gets the customer to sign. It's how trust gets built.
That gave me a clear principle for the simulator. The product should feel like the sales conversation, not skip past it. The user owns the decisions. The product brings the data, the historical context, and the ability to test what those decisions would actually mean. Configuration is where confidence is built. The visualisation and backtesting are where it pays off.
Add image: Rule configuration screen
Add image: Historical performance view
The user configures. The product shows them what their choices would have meant.
Progressive disclosure under commercial pressure
A new feature needed to be added to a setup flow that was already dense with configuration. The pressure was to surface it early, give it weight, make it findable.
I designed the opposite. The feature appears only after the user has configured the corridors that make it relevant, at which point the system can surface a real signal rather than ask the user to reason about a theoretical one. Recommendations sit collapsed by default. The user retains authority over the values throughout.
The same principle shaped the wider setup experience. Essential parameters sit on the surface. Advanced configuration is available but never demanded. New users can move quickly. Experienced users get the depth they need without the rest of the product getting in their way.
Add image: Configuration section showing contextual signal and collapsed recommendation panel
The system surfaces a signal. The user makes the call.
Prototyping in code, not slides
I built functional prototypes in code rather than relying on static mockups for stakeholder and customer reviews. It changed how the work landed.
Customers could interact with the work in sessions instead of imagining it, which produced sharper feedback. Engineering had something concrete to align against, which surfaced technical realities earlier and prevented scope from drifting late. Several decisions, including which features to defer, came out of conversations that wouldn't have happened over a Figma file.
Add image: Customer co-creation session or working prototype screenshot
Functional prototypes meant customers could use the work, not just look at it.
Outcome
Since launch, the Simulator has run 1,500+ simulations across 660+ users at 250+ customer companies, with sustained monthly engagement and adoption across every part of the freight market it was designed for.
The work won a Ship Technology Excellence Award and was a UX Nordic Awards finalist. Indexing has moved from a side bet to one of Xeneta's strategic surfaces, with the 2026 roadmap extending the Simulator into futures and derivatives so customers can hedge their contracts as well as model them.
The bigger shift was positioning. Indexing helped move Xeneta from a benchmarking tool toward a strategic procurement platform. The product question I started with was whether design could make this mechanism trustworthy enough for customers to adopt. The usage data says it could.
Add chart: Simulations over time, or stat block with headline numbers
Trust is a UX problem. In enterprise products, especially financial ones, transparency is more valuable than simplification. Customers making commercial decisions don't want a black box. They want visibility, confidence, and the ability to defend the result to someone else.
The best product research happens where the product isn't. Watching how a sales team actually sells indexing taught me more about how the simulator needed to feel than any usability test could have. Domain authority belongs with the user, and the product's job is to bring the data, the context, and the patience to let them work it out.