CargoWise Driver Mobile App (DMA)

The Driver Mobile App (DMA) is the field-facing mobile application freight transport drivers use to run their day, from receiving job assignments and driving an optimized route to completing stops, tracking consignments, managing shipping documents, and staying in contact with dispatchers. It sits at the physical execution layer of WiseTech Global's CargoWise ecosystem, the point where a planned move in a Transportation Management System becomes a truck arriving at a gate. Whatever happens in the back office, freight only moves when a driver can see what to do next and do it without friction.

The product evolved across two major bodies of work. The first unified the driver experience. Version 1 was built specifically for CTO (Container Transport Operations) drivers, covering daily task management, offer acceptance, sequential stop completion, document upload, signature capture, and dispatcher chat. Version 2 then unified that experience into a single application capable of supporting CTO, FCL (Full Container Load), and LCL (Less-than-Container Load) move types, so one app could carry the physical execution of every kind of move rather than fragmenting it across separate tools. These versions were built on Material UI (MUI).

Two connected problems defined the work, each belonging to one phase.

The first was fragmentation. Drivers running daily operations were working out of separate mobile applications, one per move type (CTO, FCL, LCL). That split created compounding friction: operational inefficiency from switching apps depending on the load assigned, inconsistent workflows because each app handled multi-pickup, multi-dropoff, and container management differently, navigation complexity because load-by-load task management forced drivers back and forth between lists and detail screens, unclear action requirements because drivers struggled to tell what was actually required at each stop, and no unified communication across the separate apps. The complexity intensified in the situations that happen every day: multiple containers at a single stop, different workflows per move type, two different driver types (company drivers and independent owner operators), and complex routing that needs exception handling when a stop goes wrong.

The solution came in two movements on the same product.

The first movement unified the experience. I built a single CargoWise Driver Mobile App (DMA) on a stop-based itinerary design that organizes the driver's day as a sequence of numbered stops on an optimized route, and the same structure absorbs every move type. A stop-based workflow makes each stop a card showing the required action, location, appointment details, and driver notes. A dynamic action system drives the driver through each stop with one contextual button that evolves through the flow, Start Route, Arrive, Update Details, and Depart, and inside Update Details, accordion sections guide the required actions in order: update container details, upload documents, confirm inspection, and capture signature. Sequential stop navigation advances automatically to the next stop on completion. A unified multi-move architecture lets the single app accommodate CTO, FCL with item verification, and LCL with multiple signatures and proofs of delivery per stop, while driver-type adaptation serves both company drivers and owner operators, alongside AI-assisted document identification and built-in exception handling for failed inspections, container issues, and route recalculation.

One structure well chosen can carry a lot of variation. The instinct with three different move types is to build three tailored experiences, but the stop-based itinerary showed that the right shared abstraction absorbs the differences instead of erasing them. CTO, FCL, and LCL all reduce to a sequence of stops with required actions, and once that structure held, the move-type specifics became variations inside a stop rather than separate products. Finding the structure the whole domain fits into was worth more than tailoring screen by screen.

A design-system migration is a chance to fix the product, not just its skin. Supplification could have been a straight re-theme, but the migration surfaced the real reason to touch the app: it was inconsistent with CargoWise and it overwhelmed drivers mid-route. Building the Supply Mobile Design System from scratch, faithful to the web system's structure and naming, delivered the consistency, and treating the same moment as the time to go map-first and rework the Stop Detail hierarchy delivered the usability. The lesson was that when you have to rebuild the foundation anyway, that is the cheapest moment to also fix what the foundation was holding up.