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

Inside the order

Before Pelorus: each of the seven parties tracked their piece of the order separately — phone calls, whiteboard notes, and separate tracking across every party. No one had a complete view. The platform’s job was to become the single place where the full order existed, visible to every party involved.

The domain in 30 seconds

A wine shipment from Nelson to Auckland: the vineyard packs pallets. Truck 1 arrives, loads, moves to the warehouse. The warehouse unpacks. Truck 2 picks up a container from the port, arrives at the warehouse. Goods are packed. Container dropped at the port — within the correct window, with the correct documentation. Container loads onto ship. Ship sails. Ship arrives in Auckland, container offloaded. Truck 3 picks up the container, drops at the destination warehouse. Unpacked. Truck 4 picks up the palletised goods. Delivered.

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.

After taking over full design responsibility, I owned IA, all page structures, navigation, usability testing, and the design system — a component library in InVision that a team of eight engineers worked from. Creating and managing that system was what allowed parallel feature development across an agile team without visual divergence.

The one view that had to show everything

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

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.

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.

Impact

Before Pelorus: clipboards, whiteboard notes, and phone calls across seven parties, with no single version of the order state. Pelorus replaced that with a single shared platform — one source of truth for every party involved in every active order.

Major freight clients running all cargo through Pelorus. QuayConnect making the platform a core selling point to clients. V2 now being commissioned for wider commercial access — the strongest signal that the product works.

Final designs

Reflection

The most consequential gap in this case study is measurement. I don’t have a metric for how much faster order coordination became, how many errors were caught by the system that would have caused detention fees, or how many manual status updates were eliminated per day. The before state existed — clipboards and phone calls — and the after state exists. What I don’t have is a number connecting them.

V2 being commissioned and built is validation that the product worked. 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 — so the case for the product is quantified, not just qualitative.

I’d spend more time in the port observing real orders before designing the status system — not after. The overlap between packing and transport that surfaced in testing was something I would have caught earlier with more observation time in the operational environment. In hindsight I treated it as an edge case to route around; it was actually a signal about whether the underlying status model was right.

Joining after discovery was complete meant inheriting decisions without the reasoning behind them. Some were right, some I changed — but I spent real time figuring out which was which before I could move forward confidently. The time spent reconstructing the rationale for decisions that were already made is time 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.