Clear Fleet
A dispatcher-first fleet operations platform for last-mile delivery teams
Role
Solo UI / UX Designer
Duration
4 Weeks
Platform
Web, IOS, Marketing Site
Tools
Figma, Framer, Claude
[The Problem]
The Challenge
Dispatchers running a 20-100 vehicle delivery fleet have no way to see what's happening across their fleet in real time so they default to calling drivers directly, dozens of times a shift, just to stay informed.
Why this matters
Business Problem
Every minute a dispatcher spends manually gathering status updates by phone is a minute not spent preventing the next failure.
Delayed reactions to breakdowns and failed deliveries directly cost the business - missed SLAs, unhappy customers, and drivers left without support mid-shift.
User Problem
A dispatcher's job is fundamentally. about awareness knowing where every vehicle is, what's going wrong, and what needs their attention right now.
Without a live system, awareness only exists in the dispatcher's head, rebuilt manually, call by call, all shift long
Research Note
This case study is informed by secondary research and industry sources. Verifiable claims are cited, while unsupported data has been removed or softened.
Key Pain Points
No Live Visibility
Dispatchers only learn about delivery issues after customers report them.
Reactive Communication
Status updates depend on repeated phone calls throughout the day.
Slow Exception Handling
Breakdowns, wrong addresses, and delays are difficult to prioritize and resolve quickly.
Fragmented Operations
Fleet information is scattered across calls, messages, and manual tracking.
Our Goal
Create a dispatcher-first platform that brings real-time visibility, prioritizes exceptions, and reduces the need for manual coordination.
[Research & Discovery]
Understanding the dispatcher's real bottleneck before designing anything
Secondary research
Reviewed logistics and dispatch-operations sources to understand how routes get assigned, how failures get caught, and where communication overhead concentrates.
Systems & object mapping
[Competitor Audit]
Existing fleet platforms track vehicles.
Almost none are built around resolving exceptions.
I reviewed how established fleet products handle visibility, alerts, and delivery issues to identify where a dispatcher-first workflow could create a clearer advantage.
*Based on public product documentation, not hands-on trials*
LocoNav
Competitor Audit
CORE FOCUS
Real-time GPS tracking, driver safety scoring, compliance
EXCEPTION HANDLING
Geofence + behavior alerts — reactive, safety-focused
Gap: no route-vs-safety split
Fleetx
Competitor Audit
CORE FOCUS
Route risk prediction, single-dashboard driver monitoring
EXCEPTION HANDLING
Deviation + stop alerts — flagged, not resolved in-app
Gap: alerts don't resolve into action
Track-POD
Competitor Audit
CORE FOCUS
Live map tracking, electronic proof of delivery
EXCEPTION HANDLING
Delivery confirmation — no visible reassignment workflow
Gap: no prioritized issue queue
DESIGN
OPPORTUNITY
[I.A. Flow]
[Key Design Descisions]
Two decisions that shaped the final product
When is a breakdown actually resolved?
Problem
A breakdown exception needs to close eventually, but what actually counts as "closed"?
Options Considered
A. Auto-close once all stops reassigned
B. Manual close only, dispatcher decides
C. Two independent states, both required
Decision
Option C. Route status and driver safety status track independently. Both must be true to close.
Trade Off
One extra manual step for the dispatcher — a "confirm driver safe" tap that a fully automatic system wouldn't require.
Why It Won
Option A let a dispatcher mark a stranded driver "handled" just by reassigning their stops. That's a real safety gap, not a UX nitpick.
Zone mismatch warning — block or inform?
Problem
Assigning a stop to a driver outside its zone is sometimes wrong, sometimes a deliberate call. How should the system react?
Options Considered
A. Confirmation modal, blocks until dismissed
B. Inline warning, no blocking
C. No warning at all
Decision
Option B. A small inline flag next to the mismatched driver -visible, never blocking.
Trade Off
Less dramatic than a modal - a rushed dispatcher could miss it entirely, since nothing forces them to stop and look.
Why It Won
Zone mismatches are routine, not rare. A modal seen 10+ times a shift stops being read, alert fatigue makes it worse than no warning at all.
[From Structure To Screen]
[Design System]
The reusable kit built from that identity
[Brand Identity]
Reliable. Fast. No-nonsense.
TYPEFACE
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz 1234567890
[Impact]
This is a concept project. Rather than invent usage stats, here's what the process itself proved, and what's still a hypothesis.
Proven In Process
A real safety gap caught and fixed, an early version could mark a stranded driver "handled" just by reassigning their stops. Rebuilt into two independent states before it shipped.
Proven In Process
Every screen cross-checked against every other, real data contradictions (timestamps, exception counts, frozen driver progress) caught before a single line of code.
Proven In Process
An unsupported stat pulled from the landing page rather than left uncredited, replaced with a number that's actually citable.
PROJECTED, NOT MEASURED
If the visibility hypothesis holds: ~40% fewer dispatcher calls, sub-2-minute response to a new exception, and a completion rate sitting above the 90% industry-healthy benchmark. These are the targets the system was architected around, worth validating with real users, not claiming as results.