Four products, one delivery
Designing the Driver, Dispatcher, Business and Super Admin products for a New York last-mile platform that runs pedal-assist cargo trikes alongside cars, out of neighbourhood micro-hubs.
Product context
MetroSpeedy
MetroSpeedy is a New York last-mile delivery company. Rather than running everything out of one depot, it operates micro-hubs across its coverage area so that most drops are a mile or less — short enough to be served by pedal-assist cargo trikes as well as cars and vans, across the five boroughs and into Westchester, Long Island, New Jersey and Connecticut. Four products sit on top of a single delivery: the driver’s phone, the dispatcher’s console, the business customer’s dashboard, and internal administration.
- My role
- Senior Product Designer
- Users
- Drivers — cyclists and motorists · Dispatchers · Business customers · Internal administrators
- What I did
- End-to-end design across four connected role-based products
- Driver onboarding, vehicle verification and compliance
- Real-time task, route and exception handling
- Proof of delivery under field conditions
- Specifications, engineering collaboration and QA
Product ecosystem
A delivery changes hands four times before it is done
- Order
- Micro-hub
- Route
- Task
- Proof of delivery
- Settlement
Core complexity
Four products, one object
A delivery is a task to the driver, a queue position to the dispatcher, a promise to the business customer and a line to settle for admin. Change its state in one product and three others must already agree — there is no version of this where the driver and the dispatcher disagree about what happened.
Two vehicle classes, two legal realities
A cargo trike and a car are not variations on a theme. They carry different licensing, insurance and inspection obligations, and a rider has no policy number to give you. Compliance is not paperwork attached to a driver — it is a property of the vehicle class, and the product has to know that.
The field is hostile
One hand on the phone, the other on a load. Daylight on a screen. A basement with no signal, a lobby with no answer, and a delivery window that is already closing. Every interface decision is made against those conditions or it is made wrong.
Being offline is normal
A driver who is off shift is not a broken session. Treating disconnection as an error state punishes people for finishing work, and it teaches them to distrust the one screen they need when something is actually wrong.
Selected journeys
Onboarding a driver who might be on a bike
The same step of the same flow, under two different legal realities. A car driver is asked for make, model, year, plate, insurer, policy number, policyholder and expiry — nine required fields, because a vehicle on the road with a commercial load needs all of it. An e-bike rider is asked one question: what kind of bike.
When the plan breaks
Most of this product is the exception. A lobby with no answer, a package that will not scan, an address that turns out to be a loading bay round the back. The escalation path to a dispatcher is not a support link buried in settings — it is designed as a first-class route out of every task, because the alternative is a driver standing in the street improvising.
One screen, in depth
Offline is a state, not a failure
- 01
The driver owns the switch
Going online is a deliberate act, not a side effect of opening the app. Nobody is assigned work by accident.
- 02
Offline still shows tomorrow
Scheduled routes, their value and their time windows remain readable off shift. Planning your week should not require being on the clock.
- 03
A route carries its terms
Value, stops, window and task count sit together on the card, so accepting work is an informed decision rather than a hopeful one.
- 04
Training lives on the home screen
Not in a help centre. Safety guidance for a job done in traffic belongs where the shift starts.
Beyond the happy path
Beyond the happy path
Connection drops in basements and lifts, servers fail, and a build eventually stops being safe to run. Each of those is a designed screen with a way forward, because the person reading it is standing outside in the weather with a load and a deadline.
Design-system contribution
One task card, one status vocabulary and one escalation pattern repeat across the driver app, the dispatcher console and the business dashboard, so a delivery looks like the same object wherever you meet it. The mobile patterns were built for one-handed use in daylight before they were built for anything else.
Reflection
What I would do differently: the vehicle-class rule lives in the form, and it should have lived in a shared definition the four products read from. It worked, but every time a class changed we changed it in more than one place — which is exactly the coupling the rest of this system was designed to avoid.