The payment was never the problem

Designing ocean-terminal appointment scheduling for the world's largest terminal operator

They came to me for a payment system. An appointment payment system for ocean terminals — that was the ask.

The payment was never the problem.

When I actually dug in — interviews and observations with PMs and sales — the thing that was missing wasn't a way to pay. It was the appointment itself. The terminal had no real way to book one, and no way to categorize the different dray and trucking services so it could assign the right kind of payment to each. Payment wasn't the mountain. It was the flag you plant at the top to prove you climbed it. Once I saw that, payment became the marker of success for a workflow — the signal that everything upstream had been set up correctly — instead of the workflow itself.

That reframe changed the whole project.

Designing for the IoT truck and the clipboard in the same screen

The first thing that surprised me was the spread of technology among dray companies. On one end: high-tech fleets running IoT sensors and ELD. On the other: mom-and-pop shops still living on physical paperwork. Same terminal, same gate, wildly different operators — and the design had to serve both without condescending to either.

Digging into the Asian market specifically is where a lot of it clicked. It pushed me toward a system built around filters and specifications — enough variety that a sophisticated enterprise could slice it however they needed, and enough restraint that a two-truck operation wasn't drowning.

Dispatchers, not "users"

The people who actually lived in this thing were dispatchers. And "dispatcher" isn't one persona. Some needed to book a single appointment — a hazmat load, a reefer, something that needs attention and care. Others represented large enterprises and needed bulk everything.

So the design couldn't just have functionality. The same components had to work in a stripped-down version and scale up to functionality-on-steroids. That's the part people underestimate: this is where design and engineering stop being separate jobs. Getting the React components right — so one system could collapse down or expand up without breaking — was the whole ballgame. I was in the components with engineering, not throwing specs over a wall.

The truckers just wanted a PDF

Here's where we almost overcooked it. Shippers, LSPs, enterprise fleets — they all wanted personalization, and marrying those flows into one seamless, prioritized screen was the hardest single task. We were so deep in that complexity that we nearly built the truckers the same heavy experience.

They didn't want it. At the end of the line, a trucker needed one thing: a generated PDF with their appointment details, emailed within seconds. Done.

The office users were the opposite — for them, the appointment was the start of the data, not the end. Once a dispatcher books, that data has to branch: into finance, into manager approvals and escalations, into detention and demurrage, into all the red tape and roadblocks a terminal runs on. Same event, completely different needs on either side of it.

The bloodbath

The fight that lasted until the very end was date-driven vs. payment-driven workflow. Payment-driven had the PMs in a chokehold — it felt right to a lot of people to organize everything around the transaction.

After researching the Asian pay market, the answer split by user: a QR-code-driven approach won for trucks at the terminal, while enterprises would run a tab with the terminal or a corporate card that auto-charged at the end of the booking flow. But the real punchline is that it was never really date or payment that should drive the setup. It was the kind of load. Load type was the deciding factor the whole time. (And, surprising no one more than me, the calendar view turned out to combine with filters beautifully once we stopped treating them as rivals.)

What I'd tell you if you asked how I work

Listen to the salespeople. They will be the most honest people in the building about what's broken and what's working — especially on international products. Somehow they're the source of truth, and going to them is the fastest path I know from question to insight. It has saved me over and over.

And start with the big picture. The double diamond isn't a poster on the wall — discovery-first, ideation-driven, is exactly how "make me a payment button" turns into "you actually need an appointment system." I got to see the maximum of the constraints on this one, the full spread of filter-driven complexity, which means almost anything after it is a lighter version of a problem I've already solved.

The part I'm proud of

Honestly? I'm proud to be done arguing about calendar vs. load-filter vs. payment-driven views ever again.

But underneath the joke: years later, I believe this is one of the most-used services Blume ever rolled out — and one of the ones that needed the least change after launch. Last I heard, Europe is in the works, with potential replication for railroads here in the States. I'd love to see that one.

You design it once, all the way down, and it keeps working. That's the goal.