Putting the truck, the route, and the dispatcher inside one tablet
The previous Driver Assist was a communication device: Google Maps, a call function, and a camera. Any real change to a route meant a call and a dispatcher re-keying and pushing it by hand. I led design on the next-gen version, which was the first one actually wired into WM’s internal systems.
Lead project designer, end-to-end
1 designer, PM, platform and telematics eng
3 years (including 6-month feasibility phase)
1200×800 Android tablet, with dash mount
Dispatch, Gantt, telematics and yard systems consolidated into one in-cab surface
One continuous shift, spanning sign-in, inspection, route, exceptions, disposal, sign-out
Launched after I left WM (but some drivers asked to pass along their thanks)
The most instrumented vehicle in the fleet had the least connected app.
A WM truck is full of sensors - hopper fill, tire pressure, packer cycles, cameras (front AND curbside) and more. Dispatch had a live Gantt board, Yards had their own staging and maintenance systems, and none of it reached the driver. Likewise, nothing the driver knew reached any of their systems without human intervention.
So the existing tablet did what it could: generic Google Maps navigation, a call or message to and from dispatch, and a camera for photographing an obstruction. Every exception (a blocked container, a truck fault, a route that needed reordering) became a voice call, a dispatcher listening, and a dispatcher manually overriding something on their end. The driver was the sensor and the phone call was the API.
That gap was costing real money in ways nobody had a line item for: idle minutes on hold, exceptions logged hours late or not at all, maintenance issues that surfaced when a truck broke down rather than when a driver first noticed. My brief was the next-gen version. What that actually meant was being the first designer to treat the cab as an active part of the operational network instead of a passive and unpredictable one.
The driver was the acting integration layer. My job was to build the real one and give them their attention back.
Six months proving it was possible before I was allowed to design it.
Plenty of the team thought this couldn’t be built, and they had very valid reasons. The tablet was a locked-down Android device with real hardware limits. The data we wanted lived in four systems with four different owners, refresh rates, and failure modes. Telematics arrived on intervals, not events. Nobody had a good answer for what the app should show when the cab dropped off the network mid-route (which happens constantly).
I didn’t spend the first phase of the project designing screens. I spent it sat with platform and telematics engineers and built a map of every data source we wanted, what its real lead and lag times were, whether it could be pushed or only polled, and what it would cost to change that. Then I designed for those numbers instead of blindly for an ideal.
That map became the actual unlock. When you can say “hopper fill updates every 90 seconds, so the capacity warning is a trend and not a gauge; here’s the design that tells the truth about that,” the conversation stops being about whether it’s possible. I’d call this the most senior work I’ve done, and almost none of it shows up as design in this portfolio.
Design to the real refresh rate.
Every live value in the UI populates at the fidelity its pipeline can actually support. Nothing implies second-by-second truth that arrives on a 90-second interval.
Offline is a state, not an error.
The cab loses signal at some point on most routes. Actions queue and reconcile, the app says plainly what has and hasn’t reached dispatch, and no driver ever has to guess whether their exception was recorded.
One writeable source per fact.
Where two systems disagreed about a stop, we picked an owner rather than letting the tablet arbitrate. Boring, and it prevented a whole category of support call.
Drivers told me what was help and what was one more thing to look at.
I ran this with drivers throughout, not as a validation round at the end. Their environment is genuinely hostile to interface design: gloves on, in motion, in direct sun AND at night, in a loud cab, with a route to finish. Anything that costs attention is worse than nothing.
What came back was consistently lower-scale than what the roadmap wanted. Drivers wanted the next action to be obvious, the exception path to be fast, and for the truck to speak up before something failed. They did NOT want a dashboard. Several features I was excited about got cut because a driver looked at them and said (kindly) that they’d never look at that twice, and a tablet that asks for a second look is a tablet that gets ignored.
That fed straight into hard rules: nothing tappable under 44px and in-motion primaries at 56–76px; a type floor readable at arm’s length on a vibrating mount; every step completable in one glance without reading a paragraph; steppers instead of sliders; dictation and one-tap quick replies instead of a keyboard. Day and night palettes, because one shift spans both and previous versions were blinding drivers after 6pm.
The best feedback I got was a driver telling me a screen I’d spent two weeks on was something he'd never look at. He was right.
One shift, end to end, with the truck talking back.
The app follows the shape of the driver’s day rather than a feature list: sign in, pre-shift diagnostics, the weekly smart-truck inspection, navigation, the customer stop, exceptions, disposal, and a route-complete screen that summarizes what actually happened. Dispatch is reachable from a persistent bar on every screen after sign-in; the one thing the old tablet got right, so I kept it.
Integration shows up as context rather than unreadable data. The stop screen carries the ticket, container and access instructions that the dispatcher can see. Truck sensors surface as a tire fault or a hopper capacity warning where they affect a decision, not in a hidden diagnostics panel somewhere. Confirming a lift pushes to dispatch as it happens instead of becoming a phone call. The weekly inspection uses a 3D model of the truck with hotspots on the real geometry, so a driver reports a worn tire by touching the tire.
Color semantics are locked down hard, and it’s the discipline I’m proudest of: cyan means live truck position and nothing else, ever. Red is split between danger and notification and never borrowed for emphasis. In a cab, a color that means two things is a color that ends up meaning nothing.
Three years of concessions, made on purpose.
A multi-year integration project is a long series of things you agree to give up. Real-time everywhere became interval-plus-honest-labelling. Videos on exceptions became compressed stills, because upload from a moving truck on a weak connection is not a thing you can design around (maybe someday). Some of the deeper yard-system writes got deferred to a later phase so the route experience could ship at all.
I tracked those concessions as a living document with what we traded, why, and what it would take to get it back. That did two things: it kept the team from bringing up settled decisions every quarter, and it meant that when a constraint lifted (if a data pipeline got faster or a device got replaced), there was a written list of what to restart rather than an argument from memory.
The concession I’d defend hardest is reducing scope on the driver’s side. Every time we could have given the driver more control, I asked whether they’d actually want to carry that decision, even at 6am with a route to finish. Usually the answer was no, and the feature belonged in dispatch instead.
It launched after I left, which is the point.
I left WM before Driver Assist shipped. It launched shortly after, landed well, and the part I actually care about is hearing that drivers asked to pass along a thank-you. They were apparently annoyed to learn I’d already gone. For operational software, that’s the review that counts. Especially considering how annoyed they were at the start of the project!
It shipped without me because the work wasn’t in my head. The data map, the concession log, the color and target rules, the design-system tokens it was all built on — those were artifacts that the proceeding team could carry. Three years is long enough that any project depending on one person’s continued presence is a project that dies.
What I’d test first with real launch data: dictation accuracy against actual cab noise (it’s loud in there, y’all), whether drivers find the right inspection hotspots without being shown, and gloved-hand accuracy on the 3D model. Those are the three places I’d expect the design to still be more confident than the evidence.