Pelorus: freight forwarding platform

The brief

One order. Fifteen steps. Seven parties. No shared system.

QuayConnect manages end-to-end coastal freight across New Zealand — wine, glass, industrial cargo — coordinating seven or more parties per shipment. I joined mid-project after discovery was complete, took over full design ownership, and built the order management experience and the component library that an engineering team of eight worked from.

The problem

Every order was tracked across clipboards, whiteboards, and phone calls with no single version of truth. Miss a contracted port window and the shipment waits. With seven parties involved — each carrying legal liability at the handoff point — timing failures had contractual consequences, not just operational ones.

What I designed

An order management platform built around two zones: a persistent Overview showing macro context (locations, dates, containers), and Action and Track below for task management. Status as the primary design language — a coordinator should be able to glance at an order and know exactly where it is and what requires attention without reading anything. A component library in InVision that let eight engineers build features in parallel without visual divergence.

Results

The domain in 30 seconds

Fifteen steps. Four different truck drivers. Two warehouses. One port. One shipping company. Customs. And this is when everything goes right.

The stages aren’t arbitrary — each boundary is a legal handoff. Liability transfers from one party to the next at a specific moment, driven by contract. This turns out to be useful for product design: the same structure that governs the logistics also governs the IA. The tab structure — Packing, Shipping, and Delivery — follows the domain’s handoff boundaries rather than being an arbitrary design choice.

My role

I joined mid-project, after discovery was complete. I spent the first weeks working through the discovery findings and early design decisions with the existing designer — reviewing what had been built, understanding what was fixed and what was still open. I kept most of the early direction. The navigation structure I later changed, based on testing.

The one view that had to show everything

The coordinator’s problem wasn’t that the process was complex — they understood it deeply. At any moment, they needed to know: where is this order in the chain, and what do I need to do right now?

The problem was that the information was everywhere and nowhere.

I designed the order page around two zones: an Overview at the top (static context — locations, dates, containers) and Action and Track below (dynamic task management — what’s booked, what’s active, what’s complete). The Overview never disappears. Whatever a coordinator is doing in the task section, they always have the macro state visible above.

One early attempt used a scaled timeline to show the full order at a glance — placing packing, shipping, and delivery proportionally across a horizontal axis. It didn’t work: packing takes days, shipping takes weeks, and at that ratio the shipping section scaled to an unusable sliver. The timeline became a progress indicator instead — showing upcoming locations and flagging issues — separate from the task sections. The constraint made the design cleaner.

Status was the design language

The status model drove the visual language: partially booked orders showed empty service tiles that could be clicked to fill in. Fully booked but inactive orders showed all tiles filled but grayed out. Active orders shifted focus from booking to tracking — the interface changed its mode. Completed orders closed the record.

This wasn’t decoration — the colour, icon, and badge system was how a coordinator could glance at an order and know exactly where it was and what required their attention, without reading anything. Booking also didn’t happen all at once: a coordinator might enter shipping contract details one morning and packing details the following afternoon. Each service was managed individually, so the interface had to support partial completion without losing state.

One insight that changed the navigation

The original design assumed coordinators would jump between orders frequently — sidebar navigation, quick access to the order list.

User testing with shipping coordinators revealed the opposite: they work on one order at a time, deliberately.

Removing the sidebar and moving to top navigation freed horizontal space for timelines, task detail, and the container grid — information that was previously squeezed. It was a simple finding with a meaningful consequence.

Designing for expert users

The primary users are coordinators working at desks or warehouse tablets. I made the deliberate call to design for desktop and tablet first (1024px and above) and defer mobile to a later phase. Getting the core coordinator experience right, with the information density the role required, was the first problem. Contractor-facing mobile interfaces were planned for phase two.

Weekly feedback sessions and moderated usability testing with shipping coordinators surfaced three changes: the container grid for simultaneous packing and transport updates (an edge case where the linear task sequence broke down), a reordering of sub-tasks to match users’ mental models, and explicit prompts for the SLI document that the interface had implied would auto-generate.

The status vocabulary was doing the most work. The booking → active → complete model made sense for a clean sequential order — real orders don’t move sequentially. Packing and transport overlap, containers sometimes go out of sequence, services get booked mid-process.

I noticed this pattern in testing and treated it as an edge case. In hindsight it was a signal about the underlying model.

Final designs

Reflection

The most consequential gap in this case study is measurement. The before state existed — clipboards and phone calls — and the after state exists. What I don’t have is a number connecting them. I’d build in measurement from the start on V2 — time to complete an order handoff, error rates caught by status flags, container update time.

I’d spend more time in the port observing real orders before designing the status system — not after. Joining after discovery was complete also meant inheriting decisions without the reasoning behind them, and I spent real time reconstructing rationale that good documentation would have saved. Since this project, I keep a short decision record for the calls that shaped the design direction — not for the client, for whoever works on the product next.