Making The Supply Chain Legible

Overview

An importer with forty containers in transit has to open each carrier's own website, search the number by hand, and copy the result into a spreadsheet. Tomorrow, all of it again. This is not a monthly chore — it happens several times a day.

The platform pulls carrier data together with vessel traffic, port, terminal and rail data so that round trip disappears. My work ran from the public pages through to the panel cargo owners use — the screen where the daily work actually happens.

Problem

Each shipment on its own carrier site

Approach

One panel, plus features per company

My scope

The public pages and the user panel

---

The Challenge

This product is built for someone who is already an expert. They do not want onboarding, they want speed — and their mistakes carry real cost, because a container cleared late collects demurrage charges.

• The data existed, but scattered. Every carrier runs its own system and none of them talk to each other. The user was left to act as the integration layer.
• The spreadsheet was the default tool. With no single view, everything was assembled by hand in Excel — slow, and impossible to keep error-free.
• An arrival time is not one number. ETAs shift constantly, but showing a single figure hid that movement and let decisions rest on data that had already expired.
• No two customers worked the same way. A food importer's workflow had little in common with a freight forwarder's, and one rigid interface served both of them badly.

---

Design Decisions

Why one number was not enough

The obvious move was a column showing the estimated arrival. Talking to users made it clear they did not trust today's figure — what they wanted to know was how many times it had slipped over the past fortnight.

A three-day delay announced at once and a three-day delay accumulated across four consecutive revisions are different situations. The second one says the route itself is unreliable and next time needs rethinking. A single figure erased that distinction.

---

What We Heard From Traders

This was a team's work. Colleagues on the technical side were in closer contact with the traders, and in those meetings I was mostly listening — to people who did this job every day.

That listening made one thing plain: trading companies did not need the same things, and one fixed panel could not answer all of them. Alongside the core panel features that shipped to everyone, the team built bespoke features for a given company's particular need — and designing those solutions was part of my work.

---

Outcome

• A daily chore removed. Checking scattered carrier systems by hand left the workflow.
• Decisions on the trend, not the moment. ETA history let users judge how dependable a route was, not only where it stood today.
• One panel, plus whatever a company needed. Core features shipped to everyone, while a company's particular need was built and designed on its own.

---

My Part In It

• The public pages. Redesigning the home page, the about page and the rest of what people see before they sign up.
• The exporter and importer panel. Improving the screen where a cargo owner follows their shipments every day.
• Bespoke features for trading companies. Small and large firms did not want the same things; a solution was found and designed for each particular need, separate from the core panel.

All three rested on the same thing: understanding the business itself. I had to know how demurrage and detention are calculated and why one day's delay at clearance costs the cargo owner money — otherwise every design decision would have rested on a guess.

---

Revisiting It In 2026

Designing this again, I would move from showing status to announcing exceptions. Back then my focus was making all the data reachable. I now know that someone tracking forty shipments does not want to read forty rows — they want to know which three need them today.

• From the full list to the exception list: the default view would be shipments that have left the plan, not every shipment.
• Grades of urgency: a delay that can still be recovered and one whose penalty is already certain should not look alike.
• Prediction over reporting: early signals that a delay is likely, drawn from the same history the platform was already collecting, rather than a report that it has happened.