One road, two cockpits.
Connecting field actions with admin visibility on one shared load state.
A driver mobile app and a super admin dashboard for a working logistics operation — load assignment, start/end load actions, POD upload, live tracking, admin queues, and urgent overrides. One load state, rendered two very different ways: one-thumb simple in the cab, full-board deep in the control room.
Project snapshot.
A driver mobile app and a super admin web dashboard built on one shared load state.
Field users in cabs and at docks; desk users monitoring the whole board at once.
One-thumb actions on mobile; density, queues, and overrides on the web.
Product design across both surfaces, plus the status model that keeps them honest.
One status language, with explicit states through the ambiguous middle of every load.
Field work and control-room work in one product.
Drivers use the product on the road — one thumb, bad lighting, gloves, spotty attention. Every extra tap or ambiguous label costs real time at a dock. Operations admins sit at a desk monitoring many loads at once, where the cost of a bad interface is missed exceptions and phone calls that should never have been necessary.
This was a working operation, not a greenfield concept. The design had to map to how dispatchers and drivers already communicated — then remove the ambiguity, not add ceremony. Three things sat at the core: live status, document verification, and sanctioned urgent overrides.
- 01Live tracking — every load's position and ETA had to stay current and trustworthy
- 02Multiple actors — drivers, dispatchers, and admins acting on the same load object
- 03Time-sensitive decisions — a late reaction to an off-plan load costs money by the hour
- 04Document verification — a load is not billable until its POD is legible and approved
- 05Exception handling — breakdowns and reassignments needed sanctioned paths, not workarounds
- 06Mobile + web coordination — two surfaces that had to agree on one load state at all times
The problem was not visual polish. It was operational clarity.
A driver parked at a dock does not want a dashboard — they want one obvious next action, readable in glare, tappable with one thumb. The operations team needs the opposite: density, exception visibility, document verification, and the power to intervene without losing the rest of the board.
The core design problem was not any single screen. It was making sure both sides of the system were always looking at the same load state — expressed simply on mobile, and in full operational detail on the web.
Orientation speed
A driver at a dock and an admin scanning forty loads both need their next action in seconds — not after a search.
Information density
The same load had to render as a single-action card on a phone and a dense, filterable row on the web — without diverging.
Handoff clarity
When a load passes from driver to admin — POD upload into verification — ownership had to be explicit, never assumed.
Both cockpits, end to end.
I owned product design across both surfaces — the driver's phone and the admin's board — plus the status model that kept them honest with each other. The work ran from workflow mapping through flows, screens, states, and dev-ready handoff.
- 01Designed driver app workflows end to end
- 02Designed super admin dashboard concepts
- 03Created flows for start/end load actions
- 04Designed POD upload and verification experiences
- 05Structured live tracking and status visibility
- 06Designed admin queues and urgent action patterns
- 07Defined the shared load status model across surfaces
- 08Used dummy/NDA-safe data where required
Understanding the workflow before redesigning the interface.
Before drawing screens, I mapped the life of a load across both surfaces — who owns it at every step, and where it stalls. Two steps carried most of the friction, and both sat at the handoff between field and office.
- POD photos arrived illegible with no re-request path
- Uploads landed detached from their loads in a shared inbox
- Progress questions were handled by phone call, not the product
- Urgent loads sorted like normal rows in the queue
- No visible trail when admins overrode a load
Key UX challenges.
Different needs for drivers and admins
Drivers need one obvious action; admins need forty loads at a glance. Neither could be a stripped or bloated version of the other — each surface had to earn its own shape.
Live operational status visibility
Where is every load, right now? Status had to be current, trustworthy, and readable without opening each record — because a status nobody trusts becomes a phone call.
Document upload and verification
POD photos taken at a dock had to arrive legible, attached to the right load, and reviewable in a queue — not an inbox — because unverified paperwork stalls billing.
Urgent override states
When a load goes off-plan, admins need a sanctioned intervention path with a clear trail. Silent edits that rewrite history erode trust in the whole record.
Mobile simplicity vs admin detail
The same load object had to render as a single-action card on a phone and a dense, filterable row on the web — diverging renderings would mean diverging truths.
Reducing ambiguity around load progress
"Where is my load?" calls were the symptom. The cause was a status model too loose for anyone to trust on its own — fixing the model mattered more than any screen.
Key design decisions.
Each decision traded surface-level flexibility for operational clarity — the pattern that mattered most in this domain.
Keep driver actions minimal and step-based
Drivers were hunting through screens for the right button while parked at docks — every extra tap cost real time.
The load renders as a stepper — accept, start, in transit, end + POD — with exactly one thumb-sized primary action per step. Everything secondary moved behind the current step.
The app stopped being a place to search and started asking for the next thing the operation needed.
Make admin status visibility central
Admins reconstructed load positions from calls and messages — the board could not answer "where is everything" on its own.
Live tracking and load status on one board: a route map showing progress, backed by a table where every load reads at a glance.
Status became something the screen shows, not something admins ask for — with off-plan loads visually louder than healthy ones.
Treat POD verification as a dedicated workflow
POD uploads were buried inside load records — illegible photos got quietly accepted, and billing stalled on paperwork nobody could find.
A two-sided flow: guided capture at the end of the driver's trip, feeding a dedicated verification queue where every document is awaiting review, approved, or rejected with a re-request back to the driver.
A load is not financially done until the paperwork agrees it is — nothing legible gets lost, and nothing illegible gets silently accepted.
Use clear exception and urgent states
Urgent loads sorted like everything else, and admin fixes silently rewrote load history — severity was invisible until someone scrolled to it.
Urgent loads got a distinct visual register, pinned above normal sorting. Overrides became a first-class action — reassign or force-close, but only through a flow that captures a reason.
Admins triage by severity, not scroll position — and every intervention leaves a visible trail on the record.
Override rule: reason required, dispatcher confirmation, action logged on the load timeline. No silent edits.
Different contexts, different UIs — one status model
Making the driver app a small dashboard or the dashboard a big app would have failed both users at once.
Each surface designed for its context — one load and one action on the phone; the whole board with filters, queues, and drill-downs on the web — over a shared status model with the same states, names, and colors.
A driver tapping "End load" and an admin watching the queue always agree on what just happened.
From ambiguous progress to operational clarity.
The clearest way to show the shift is the operations queue — the screen admins live in all day.
A flat, undifferentiated list. Progress lived in people's heads, urgent loads sorted like everything else, and POD status was invisible until someone asked.
One status language, exceptions pinned first, POD state visible in the queue itself. The board answers "where is everything" before anyone has to ask.
Core screens.
Five screens carry most of the operation — two on the driver's phone, three on the admin's board. All recreated here with dummy data.
One action rule: exactly one primary button per step, sized for a thumb, readable in glare. Secondary detail folds behind the current step.
Geofence gate: "Mark arrival" stays disabled until the location check passes — no accidental early arrivals.
Audit trail: every state change lists its actor, reason, and timestamp — interventions are visible, never silent.
Designed as a system, not isolated screens.
The goal was reusable patterns, not one-off screens. The components that carry operational meaning — status pills, steppers, queue rows, document states — were built once and reused across both surfaces, so the phone and the board always speak the same language.
It also made implementation guidance clearer: mobile components sized for thumbs and glare, admin components for density and scanning, and every piece handed to development with its states already resolved.
Dev-ready handoff.
The flows shipped as structured Figma files with states resolved and status names matched to the data model — so the build conversation was about sequencing, not interpretation.
Stepper states: done, active, blocked, skipped. Primary action disabled until geofence check passes. Offline copy variant linked.
Exception pattern: urgent rows pin above sort, keep position on refresh, and expose one action — open override panel.
POD queue: reject requires a reason; re-request notifies the driver and re-opens the upload step on the same load.
Where it landed.
The work shipped to development as a structured, state-complete set of flows. The honest measure at this stage is workflow quality: both sides of the operation now share one status language, and the ambiguous middle of every load's life has explicit, designed states.
Clearer operational workflows
Mobile and admin interfaces now describe the same operation in the same language — one status model rendered two ways.
Visibility into load progress
Load progress and document status read directly from the board, replacing the phone calls that used to carry them.
Better coordination between roles
Drivers and operations teams work against explicit handoffs — POD capture into verification, exceptions into logged overrides.
Build-ready product flows
Structured, state-complete flows and components shipped to development with annotations, states, and naming resolved.
What I would improve next.
Field products are only proven in the field. Given another cycle, this is where I would push.
- 01Field usability testing with drivers — in cabs and at docks, not in a conference room
- 02Offline and poor-connectivity states for the driver app
- 03More edge states for overrides — partial deliveries, mid-route reassignment
- 04Accessibility review tuned for glare, gloves, and one-handed reach
- 05Deeper analytics on how exceptions actually get handled