Freight logistics moves billions of dollars of goods every day. The software behind it hasn't kept up.
HaulerHub came in wanting to change that. Positioned as a freight matching platform, the brand had ambition. The product didn't deliver on it yet.
I joined through Value at Void in March 2025 as project owner. The platform existed as a pre-launch concept. Core workflows had been designed, but weren't ready for real users.
The driver app and the shipment form were usability problems. Fixable, scoped, solvable.
But when I looked at the product model itself, something else stood out. HaulerHub was built on a traditional load board. Shippers post, carriers browse and bid. Passive by design.
The brand had already moved past that. Every marketing message positioned HaulerHub as a freight matching platform. The product needed to catch up to its own promise.
That gap became the lens for everything that followed.
Before touching anything, I needed to understand who I was actually designing for. Three completely different people use this platform, and their needs don't overlap much.
Shipper
Logistics or operations managers. Posting loads regularly, often the same routes. Every minute on a form is time away from running their operation.
Carrier
Fleet owners or dispatchers. Looking for the right loads for their trucks, right route, right rate. The load board gave them a list. It didn't help them decide.
Driver
On the road. They've accepted a load, they know where they're going, and the last thing they need is an app demanding their attention while they're moving.
Client work, not an internal role. Every major decision went through the client and I had to back it up when pushed back on. No live users at the start, so testing relied on potential users the client recruited.
Drivers use phones differently on the road. Uber drivers accept a trip, open maps, and don't touch the app again until arrival. The phone sits on the dashboard. Eyes stay on the road.
The existing driver app wasn't designed for that reality.
I proposed Drive Mode. A separate interface that activates once a driver departs. Stripped back to only what matters in motion.
Primary button tracks trip state. "Arrived at Pickup" becomes "Arrived at Dropoff." One tap, right state.
Chat button for urgent shipper messages. Report delay for breakdowns or traffic. Both large, one-handed.
ETA in plain text. Nothing else on screen.
The client approved it without changes in a single review.
The original flow was a dense, single-page form: ~20+ fields, no grouping, no sense of progress. High cognitive load.
I explored multiple layouts: a sparse two-column form that wasted space, a split-panel that fragmented context, a long scroll that repeated the overwhelm problem. The multi-step flow won because it chunks the 20+ fields into logical, task-based steps, pairs each step with a persistent fiscal summary for context, and uses a clear stepper to give users progress and control.
Iterations of multistep form layout
The client pushed back. Their view: one page gives users full context upfront. Fair point.
Instead of debating on opinions, I suggested testing both with real users. The client recruited 12 potential shippers. We ran both flows through Maze.
The multi-step version completed 20 to 30% faster on average, measured from time-on-task data. That ended the discussion. The redesigned flow shipped.
The redesigned form was faster. It was still a form.
I proposed an AI Copilot for load creation. A conversation instead of fields. The shipper describes the load, the Copilot asks the right follow-ups, builds the structured information alongside the chat, and presents a summary to confirm and post.
The standout moment: rate estimates. Instead of guessing, the Copilot pulls a market-based range for that lane that week.
The client approved and immediately expanded the scope. One feature proposal became a platform-wide initiative.
The co-founder wanted to move away from the load board entirely. Carriers onboard with capabilities and rate preferences. The system recommends loads to carriers, recommends carriers to shippers. Both sides can book directly.
Some on the client team felt it was too much, too fast. I showed them two things: competitors were already moving this way, and HaulerHub had been marketing itself as a matching platform from day one.
That conversation moved things forward.
What I designed:
Carrier and shipper verification using government-linked APIs to prevent fraud.
Onboarding flows where shippers build location and shipment profiles for faster future posting.
Load recommendation feed for carriers. Carrier recommendation engine for shippers.
One addition that wasn't in the brief: automated Bill of Lading generation. All the information needed was already captured in the shipment profile. I built generation into the booking confirmation step. One less platform, one less manual task.
Fully designed, client-tested, and currently being showcased to potential customers ahead of development.
None of these four things were in the original brief.
I designed the AI Copilot for one workflow. If I were starting today, I'd map the entire platform first, identify every repetitive manual task, then design the AI layer around that map. Not around individual screens. That's where the project is heading now. I'd have started there.