Kargo
2025
Kargo
Kargo is a confidential company project. No screens are shown here — this case study focuses on the thinking behind the design, not the visuals.
Overview
Replacing a phone call with a glance
Before Kargo, knowing whether a truck was available today meant calling someone and asking. I designed the system that replaced that phone call with a screen — one that had to be faster than picking up the phone, or nobody would use it. That constraint shaped almost every decision in this project, from how availability is grouped to why posting a load works by voice instead of a form.
The Impact
The core workflow — checking availability and posting a truck or load — went from a phone call and manual tracking to something visible and postable in seconds, directly from the homepage. Supporting tools (map-based search, radius search, productivity tracking, in-platform onboarding) extended that same system rather than sitting apart from it.
The problem
Speed was the real competitor — not another app
The obvious framing for this project was "digitize a manual process." The harder, truer problem was that the manual process — a phone call — was already fast for the people doing it. Dispatchers and admins didn't need a system that was merely more organized than a spreadsheet; they needed one that didn't feel slower than picking up the phone. Any screen, form, or extra tap was a real cost, because the alternative wasn't "no system," it was "call someone."
That reframing changed what I was actually designing for. It wasn't "digitize availability tracking" — it was "make checking and posting availability faster than a phone call, while still producing clean, structured data the business could search, filter, and report on later."
Getting to the real requirement
Mapping the phone call, not just the data
Before designing screens, I walked through what a phone call actually did: it answered "what's available right now," it let someone describe a truck or load in plain language, and it happened without any menus or fields. Any digital version that asked people to fill out a multi-field form first would already have lost against that.
That's what led to two decisions that shaped everything downstream:
Availability had to be grouped by time, not just listed — "available now" versus "available later," because that's the actual question a phone call answers.
Posting couldn't start with a form. A form is slower than talking. So the entry point for posting a truck or load became a speak-to-text flow — describe it like you would over the phone, and let the system extract the fields.
The core workflow: homepage → post → confirm
The decision
I centered the entire homepage around two numbers — trucks available today, loads available today — with the two primary actions, Post a Truck and Post a Load, directly beneath them. Everything else on the homepage, including a live feed of what other admins had just posted, exists to support that one loop: check availability, post, see it reflected immediately.
Why not a dashboard with more metrics up front?
Early on, there was a pull toward surfacing more — regional breakdowns, more detailed stats — right on the homepage. I pushed back on that. The homepage's only job was answering "what do I have today," fast. Anything that competed with those two numbers for attention was moved to the Loads and Trucks pages instead, where someone arrives already intending to dig deeper.
Posting by voice, not by form
The speak-to-text flow lets an admin describe a truck or load out loud — like telling a short story — and the system maps that into structured fields (origin, destination, type, availability window). The tradeoff I had to design around: voice input is faster but less precise, so the flow includes a confirmation step showing the extracted fields before submission, rather than trusting the parse blindly. That one screen — quick to scan, easy to correct — was what made speed and accuracy coexist instead of competing.
Supporting the core loop
Once the central "check and post" loop was solid, everything else was designed to extend it rather than compete with it:
Loads & Trucks pages — total and today's counts, a Post CTA, and search/filter, with every listing grouped by available now versus available later — the same time-based grouping from the homepage, applied at scale.
US map view — clicking a state surfaces truck count and type there. This existed because "where are my trucks" is a geography question first, and a filtered list answers it slower than a map does.
Radius 360 — search by state, city, and a 60 or 250-mile radius. This came directly from a gap the map couldn't solve: availability near a specific point (a pickup or delivery location) rather than within an entire state.
Employee trends & productivity — daily, weekly, and monthly breakdowns of who posted what, plus a company-wide annual view. This was the one part of the system built for a different audience (leadership, not dispatchers), so it deliberately looks and reads differently — denser, more report-like, since speed wasn't the constraint here, clarity over time was.
SignPro — template-based onboarding for carriers and customers, built into the platform instead of routed through a separate e-signature tool, so onboarding didn't require leaving the system that already had the relevant data.
What I'd flag as the real risk in this design
Designing for clarity, confidence, and everyday financial workflows
Speak-to-text parsing is only as good as its confirmation step. If I had leaned only on "voice in, data out" without the correction screen, small mis-transcriptions would have silently created bad listings — invisible errors that undermine trust in the whole system. The confirmation step exists specifically to catch that, and if I were extending this today, I'd want a lightweight way to flag low-confidence extractions for a second look, rather than treating every voice post as equally reliable.
