← All work

Professional · 2022

World Oil driver app

A ticketing and delivery tool used by drivers moving petroleum products across California and the western US — rebuilt around the way the job is actually done, on a phone, beside a truck.

Client
World Oil — petroleum products, recycling and environmental services
Role
Information architecture, user flows and personas, UX consistency, UX inspection and audit
Users
Drivers, dispatch
Way of working
Agile, alongside product and engineering
Platform
Tablet and mobile
Year
2022
World Oil app: a timestamped status rail down the left listing scheduled, arrived at pickup, depart from pickup, arrived at delivery and depart from delivery, beside a route map with pickup and delivery pins and a summary bar showing 50 minutes and 49 kilometres
The working screen. Where the driver is in the job, permanently on the left; where they're going, on the right.

The client

World Oil recycles, produces and transports petroleum products, and provides environmental services across California and the western United States. Their end-to-end services depend on drivers completing tickets accurately in the field.

The goal set for the engagement was direct: build effective solutions and apply them to the real problems in the World Oil product, rather than produce a concept.

UX challenges

  • The product had accumulated usability problems across the driver flow.
  • User feedback said the flow was unintuitive — the order of steps didn't match the order of the work.
  • The interface predated the current design patterns and did not hold up on the screens drivers actually carry.
The tool is used standing beside a truck, not sitting at a desk.

The journey

done standing by a truck, not at a desklog inpick ticketconfirm loadpickupdeliverone-way door — confirm first
Mapped to the shape of a delivery rather than the shape of the database.

A load has five moments that matter to everyone downstream: scheduled, arrived at pickup, departed pickup, arrived at delivery, departed delivery. Those five became the spine of the interface. They sit in a fixed rail on the left of every screen with a timestamp against each, so the driver never has to remember what they last confirmed, and dispatch is looking at the same record.

Starting a ticket

Ticket setup screen: lookup, customer, customer contact number, BOL number, pickup and delivery location, truck and trailer selectors, a notes box, upload document and save buttons, and a list of start, pickup and delivery locations with distances
Everything needed to start a run, on one screen, in the order a driver receives it.

The ticket screen collects the load's identity — lookup reference, customer and contact, bill of lading, pickup and delivery locations, truck and trailer — and nothing else. Fields that come from dispatch arrive pre-filled and read-only; the only things a driver chooses are the truck and the trailer they're actually taking.

Underneath, the three legs of the run are listed with their distances: start, pickup at 49 km, delivery at 149 km. It answers the first question a driver asks before pressing Start, which is how far this is going to be.

Upload document dialog offering two large targets: camera and gallery
Paperwork capture reduced to two targets, both large enough to hit with gloves on.

Documents are the part of the job most likely to be done badly, because it happens at the least convenient moment. The dialog offers two choices at a size you can hit without looking closely: photograph it now, or pick one already taken.

Status and route

Once a run starts, the right-hand side becomes the map: the planned route, pickup and delivery pins, and a bar along the bottom carrying the destination, the time remaining and the distance.

The primary action in that bar — Arrived at Pickup Location — stays disabled until it applies. It's a small decision that removes a whole class of error: a driver can't accidentally mark an arrival that hasn't happened, and the status rail on the left stays trustworthy for everyone reading it downstream. Closing a ticket is similarly explicit and confirmed, because completing it removes it from the device.

On the phone

Four World Oil phone screens: driver login, ticket lookup with disposition code and BOL, an activity status window with directions, and a completion confirmation
The same flow on a phone: log in, pick up a ticket, work through the statuses, close it out.
World Oil login screen with driver ID and password fields beside an illustration of a tanker truck
Log in — driver ID rather than email, because that's the number drivers already know.

My role

  • Information architecture for the driver-facing product.
  • User flows and personas, so the sequence of screens matched the sequence of the job.
  • UX consistency across the redesigned screens — shared patterns for fields, selectors, status and confirmation.
  • UX inspection and audit of the existing product to find what was breaking.
  • Working in an agile team, delivering in increments alongside engineering.

Screens are from the World Oil prototype delivered in 2022.

The mark is S R in braille — from Full Housie!, where the same dots do the same job.