# CargoWise Driver Mobile App (DMA)

By Munawar Khel / WiseTech Global / Lead Product UI/UX Designer, CargoWise Landside / 2025–26 / 9 min read

Published at https://munawarkhel.com/work/wisetech-global/cargowise-driver-mobile-app/

Eliminated app fragmentation by replacing three separate move-type apps with one unified application, reducing driver confusion and onboarding time

- Company: WiseTech Global
- My role: Lead Product UI/UX Designer, CargoWise Landside
- Timeline: 2025 – 2026
- Platform: Mobile (iOS and Android)
- Category: Enterprise SaaS / Mobile Field Operations App / Mobile Design System
- Status: Redesign, delivered
- Tools: Figma, FigJam, Material UI (MUI), Supply Mobile Design System (created from scratch)
- Team: Cross-functional, with CTO, FCL, and LCL operations teams, dispatchers, and domain experts

## Context

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).

The second body of work, known internally as "DMA Supplification," took the unified app and brought it home to the rest of CargoWise. The MUI foundation had left the DMA visually and behaviorally disconnected from the wider CargoWise product family, which runs on the proprietary Supply Design System. Supplification migrated the app onto Supply, but Supply had only ever been built for web, so there were no mobile components to migrate to. The work therefore became two things at once: creating a Supply Mobile Design System from scratch, and using that migration as the moment to fix long-standing UX problems in the driver experience, most visibly by making the app map-first for drivers who are actively on the road.

## The problem

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 second was consistency and clarity. Once the app was unified, it was still built on Material UI, which put it out of step with the rest of CargoWise and its Supply Design System, creating a fragmented brand and interaction experience across platforms. Supply had no mobile components at all, having been built exclusively for web, so a direct migration was impossible without first creating the missing pieces. On top of the design-system gap, the Stop Detail screen presented large amounts of data with no clear hierarchy, overwhelming drivers during time-sensitive delivery operations, and the app lacked a map-first approach, forcing drivers through unnecessary steps while they were actively driving. The tension throughout both phases was the same: absorb genuinely different operational workflows, and align with a web-first design system, without pushing any of that complexity onto a driver who just needs to know where to go and what to do when they arrive.

## What I did

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.

The second movement, Supplification, migrated the app onto the CargoWise Supply design language and used the migration to sharpen the UX. I created a Supply Mobile Design System from scratch, building mobile components carefully aligned with the Supply web components' structure, naming conventions, variants, states, and reusable patterns, so that visual and behavioral consistency held between web and mobile CargoWise products and future mobile work had a foundation to build on. On top of that foundation, I redesigned the Stop Detail screen around a map-first layout so navigation flows smoothly once a driver starts a route, restructured the Stops module with faster-scanning stop cards, live location tracking inside cards, a prominently highlighted in-progress stop, and clearer progress indicators, overhauled the information hierarchy of the Stop Detail into clearer sections that keep every critical detail accessible without overwhelming the driver, and simplified interaction and layout with bottom-sheet patterns for contextual actions and streamlined onboarding, login, and password-reset flows.

## Outcomes

- Eliminated app fragmentation by replacing three separate move-type apps with one unified application, reducing driver confusion and onboarding time
- Reduced navigation effort through sequential stop advancement and a later map-first Stop Detail, removing the repetitive list navigation and unnecessary mid-route steps of the earlier experience
- Improved operational clarity at each stop, with a dynamic action button and accordion-based task completion, and a reorganized Stop Detail hierarchy that cut information overload during task execution
- Created a Supply Mobile Design System from scratch, aligned with the Supply web components' structure, naming, variants, and states, bringing the driver app into visual and behavioral consistency with the wider CargoWise product family
- Established reusable mobile groundwork, a scalable Supply Mobile Design System that later CargoWise mobile products can build on, where none existed before
- Strengthened the field experience with faster-scanning stop cards, live location tracking, a highlighted in-progress stop, bottom-sheet contextual actions, exception handling, and streamlined onboarding and authentication
- Grounded both phases in structured UX research (current-state and design-system audits, a cross-region terminology chart, scenario mapping across all three move types, a QAD framework, and validation against real CTO, FCL, and LCL operational data)

## Decisions

### Stop-based itinerary over load-by-load task management

What: Organized the driver's day as a sequence of numbered stops on an optimized route, with the app advancing automatically to the next stop on completion, rather than managing work load by load.

Alternatives: Keeping the load-by-load model that forced drivers to navigate between lists and detail screens for each load.

Why: The load-by-load approach generated constant back-and-forth navigation and left drivers unsure what to do next. A stop-based route matches how a driver actually experiences the day, one place after another, and sequential advancement removes the repetitive list navigation entirely so the app always shows the next real action.

### One unified app across CTO, FCL, and LCL over separate apps per move type

What: Built a single app architecture that accommodates CTO direct transport, FCL with full-container item verification, and LCL with multiple signatures and proofs of delivery per stop, serving both company drivers and owner operators from one interface.

Alternatives: Continuing with a separate mobile application for each move type.

Why: Separate apps forced drivers to switch tools by load and learn three inconsistent workflows. Unifying on one stop-based structure eliminated the fragmentation, gave drivers a single mental model, and created a foundation that can absorb new move types without a structural redesign.

### Build a Supply Mobile Design System from scratch rather than force-fit MUI or reuse web components

What: Created a mobile component library from the ground up, aligned with the Supply web components' structure, naming conventions, variants, states, and reusable patterns, instead of keeping the app on Material UI or trying to drop web components onto mobile.

Alternatives: Leaving the DMA on MUI and accepting the inconsistency, or attempting to reuse Supply's web-only components directly on mobile.

Why: The MUI foundation left the app out of step with the rest of CargoWise, and Supply had no mobile components to migrate to, so a direct port was impossible. Building the mobile system from scratch, but faithful to Supply's web structure and naming, was the only path that produced genuine cross-platform consistency and left behind reusable groundwork for every future CargoWise mobile product rather than a one-off re-skin.

### A map-first Stop Detail over a data-first screen

What: Redesigned the Stop Detail screen around a map-focused layout with a reorganized information hierarchy, live location tracking in the Stops module, and a highlighted in-progress stop.

Alternatives: Keeping the data-heavy Stop Detail that presented large amounts of information without clear hierarchy.

Why: The old screen overwhelmed drivers during time-sensitive operations and forced unnecessary steps while they were actively driving. Leading with the map matches what a driver needs in the moment, getting to the next stop, and a clearer hierarchy keeps every critical detail accessible without burying the one thing they need right now.

## What I learned

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.

Building the missing layer pays forward. Supply had no mobile components, so the honest choice was to create them properly rather than improvise per screen. Aligning the new mobile components with the web system's structure, variants, and states turned a one-app migration into reusable groundwork the whole organization's mobile products can stand on. For a field product a driver depends on, and for a company standardizing across platforms, building the missing layer well is what makes the next thing easier.

Tags: UX Research, iOS, Android, Mobile, Enterprise SaaS, Logistics, Supply Chain