Putting the truck, the route, and the dispatcher inside one tablet
The previous Driver Assist was a communication device: Google Maps, a call button, and a camera. Any real change to a route meant a phone call and a dispatcher re-keying 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. Dispatch had a live Gantt board. Yards had their own staging and maintenance systems. None of it reached the driver, and nothing the driver knew reached any of it.
So the existing tablet did what it could: generic Google Maps navigation, a call or message to 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 part of the operational network instead of the end of it.
The driver was the 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 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 spent the first phase of the project not designing screens. I 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 against those numbers instead of against 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 looks like design in a portfolio.
Design to the real refresh rate.
Every live value in the UI is drawn 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 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 landed.
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 narrower than what the roadmap wanted. Drivers wanted the next action obvious, the exception path fast, and 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.
The best feedback I got was a driver telling me a screen I’d spent two weeks on was one more thing to look at. He was right.
One shift, end to end, with the truck talking back.
The app follows the shape of the 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 closes out what actually happened. Dispatch is reachable from a persistent bar on every screen after sign-in — the one thing the old tablet got right, kept.
Integration shows up as context rather than data. The stop screen carries the ticket, container and access instructions the dispatcher can see. Truck sensors surface as a tire fault or a hopper capacity warning where they affect a decision, not in a diagnostics panel. 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.
Colour 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 colour that means two things is a colour that means nothing.
Three years of concessions, made on purpose.
A multi-year integration project is a long series of things you agreed to give up. Real-time everywhere became interval-plus-honest-labelling. Rich media on exceptions became compressed stills, because upload from a moving truck on a weak connection is not a thing you can design around. 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 re-litigating settled decisions every quarter, and it meant that when a constraint lifted — a pipeline got faster, a device got replaced — there was a written list of what to reclaim rather than an argument from memory.
The concession I’d defend hardest is scope on the driver’s side. Every time we could have given the driver more control, I asked whether they’d want to carry that decision 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 moved on before Driver Assist shipped. It launched shortly after, landed well, and the part I actually care about is that drivers asked to pass along a thank-you — and were apparently annoyed to learn I’d already gone. For operational software, that’s the review that counts.
It shipped without me because the work wasn’t in my head. The data map, the concession log, the colour and target rules, the design-system tokens it was all built on — those were artifacts the 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, whether drivers find the inspection hotspots without being shown, and glove accuracy on the 3D model. Those are the three places I’d expect the design to be more confident than the evidence.