Next Trucking · Operations Platform
Redesigning drayage operations around exceptions, not tasks
I led design for Next’s dispatching and operations system in the drayage business — moving containers between ports and warehouses on margins thin enough that a single idle day erases the profit. The counterintuitive part of the job: the company was automating, so my work wasn’t making operators faster at using screens. It was removing the screens, and designing what remains when only the hard cases need a human.
- Role
- Lead Product Designer — core operations product
- Team
- Design · PM · platform engineering
- Duration
- Oct 2021 – 2023
- Platform
- Web · internal ops + carrier-facing
$5
loss reduction per container from earlier exception catches*
+25%
dispatch throughput per operator after automation*
1
shared design system — new ops tooling shipped in weeks, not quarters*
* Loss reduction = avoided demurrage and detention fees per container, measured against the pre-exception-queue baseline. Throughput = shipments handled per operator per shift.
The problem: every container has a meter running
Drayage punishes slowness with fees. A container that sits at the port past its free days accrues demurrage; a chassis held too long accrues detention; a missed warehouse appointment cascades into both. Operators were managing this with spreadsheets, tribal knowledge, and a dispatch tool that treated every shipment as equally urgent — which in practice meant the expensive problems surfaced when the invoice arrived, weeks later.
Meanwhile the engineering org was automating matching and dispatch. That created a real design question with no precedent in the existing product: if the system assigns most loads itself, what is the operator’s screen even for? Making them faster at a job that was disappearing would have been wasted work.
The thesis: design for exceptions, automate the rest
The thesis I aligned the team around: in an automating operation, design’s value moves from task efficiency to exception management. The product should do nothing visible when things go well, and become extremely good at three moments — detecting that a shipment is drifting toward a fee, explaining why, and making the human intervention fast and auditable. Fewer screens, but the remaining ones carry money.
Three design decisions that carried the numbers
A prioritized exception queue, ranked by cost at risk
We considered the classic ops dashboard — charts, statuses, a map. We killed it: dashboards make people feel informed while the demurrage clock runs. We shipped a queue instead, ranked by dollars at risk and time to fee, each row carrying its reason and one primary action. This is what the $5-per-container figure traces to — fees got caught while they were still avoidable, not reported after they landed.
Automation got an audit trail instead of a control panel
Ops leads initially wanted approval steps on automated dispatch — understandable, and we said no. Approval queues would have rebuilt the bottleneck automation just removed. The compromise that settled the disagreement was data: we ran both paths and measured. Auto-dispatch with a full audit trail (what the system decided, when, on what basis) matched approval-flow quality while cutting handling steps — that’s the +25% throughput. Trust came from legibility, not from a human rubber stamp.
Bulk actions replaced per-shipment ceremony
The remaining human work clustered — the same fix applied across twenty shipments hit by one vessel delay. We rebuilt the table layer around selection and bulk mutation with preview-before-apply, because confidence at the moment of a 20-row change is what makes operators actually use it instead of falling back to one-at-a-time.
Building the design system that made it shippable
None of this ships fast on a fractured UI foundation. I initiated and led the unified design system adopted across Next’s web and mobile products — tables, forms, status grammar, and the dense data components ops tools live on — built with engineering as a shared library rather than a Figma artifact. The payoff wasn’t consistency for its own sake; it’s that the exception queue and bulk tooling above went from design to production in weeks, on components that already existed.
Outcomes: less interface, more margin
The exception queue turned fee avoidance from an invoice-time discovery into a daily operating practice — about $5 saved per container against the prior baseline*, which in container volume terms is real money on drayage margins. Throughput per operator rose roughly 25% as automated dispatch with audit trails replaced per-shipment handling.
The quieter outcome: the “less UI” thesis became how the product org evaluated new work. Feature proposals started getting asked “does this need a screen, or a rule?” — a question that didn’t exist before. That reframing outlived any single release I shipped there.
“Does this need a screen, or a rule?”
What I took with me
Removing UI is a design deliverable
The strongest work I did here doesn’t screenshot well — it’s the screens that no longer exist. I had to learn to document absence as rigorously as I’d document a redesign, or the work was invisible in reviews.
Operators don’t resist automation, they resist opacity
Every fight about auto-dispatch was actually about legibility. Once the system showed its reasoning and offered an override, the approval-step debate evaporated. I now reach for audit trails before permission gates by default.
Win the argument with a measured pilot, not a deck
The approval-flow disagreement with ops leadership could have burned a quarter in meetings. Running both paths and letting the numbers settle it was faster and left no resentment. I’ve reused that move on every contested decision since — including at OKX.