Delivery Driver App Redesign
Summary
The dispatch driver app—a mobile tool part of SaaS platform OS1 used by riders to manage pickups, drops, and order updates—was slow and difficult to use. It led to delayed deliveries, , and frequent order failures. The business required faster, more reliable execution to speed up operations, but only small incremental changes were possible due to having limited development bandwidth with one Android and one React developer.
The goal was to improve usability within a month without major tech rewrites.
Problem Statement
The existing driver mobile app was inefficient, causing delays in deliveries and high training time for riders.
Research /
Validating Problem
Since there is no way to understand how OS1 driver app would be used in last mile deliveries, I did a field study at Delhivery's last-mile distribution centre to gather insights into user personas and map user journey and evaluated OS1 driver app by simulating the user journey in last-mile scenarios. Additionally, I collated inferences from existing competitor benchmarking.
Field Research
To map a user persona in a natural environment & understand rider pain points, semi-structured ethnographic study was conducted at Delhivery’s last-mile centre. Tagged along with the rider on their and observed behavioural patterns.
Driver App used: Delhivery Partner App
Please note that the app used by last-mile drivers is not same as OS1 Driver app, this user journey is simulated in
Existing App Evaluation
I did a hands-on evaluation of the existing OS1 driver app by assigning dispatches to myself and completing tasks like a delivery rider — like any other day, but took screenshots and documented insights this time. This helped uncover key usability and performance issues—delays in loading, inconsistent UI, and unclear task flows that made basic actions unnecessarily complex.
Competitor Benchmarking
I conducted competitor benchmarking by reviewing the mobile apps of Onfleet, Shipsy, and FarEye. Onfleet stood out for its clean, minimal UX; Shipsy offered strong localisation features; and FarEye provided enterprise-grade configurability. While I mapped these insights into a benchmarking sheet, they couldn’t be explored further in solutioning due to the project’s tight timelines and limited engineering capacity.
Insights / Inferences / Pain Points
Waiting before moving:
Every morning, both the driver and the team lead spent nearly 40 seconds just waiting for the app to load the day’s orders—averaging around 35. This slow start created daily frustration and wasted valuable time before deliveries could even begin.
Too many taps, too little time:
To complete a single delivery, drivers had to navigate through up to 12 steps on the app. This made the process unnecessarily long and mentally taxing, especially under time pressure.
New flows create confusion, not clarity:
When a new workflow appears mid-shift, inexperienced drivers often hesitate to interact with unfamiliar screens. Many complete the delivery in real life but skip app updates, later asking the team lead to manually correct the order status—leading to extra work and confusing the customer with inaccurate tracking.
Risky calls on the move:
Drivers often call customers while driving to inform them about upcoming deliveries. During these calls, they simultaneously refer to the app to check order details and ETA—forcing them to juggle both tasks and putting their safety at risk.
Premature exits from the workflow:
Some drivers mistakenly assume a delivery is complete and exit the app before finishing all required steps, resulting in incomplete records and operational gaps.
Before we solve serious problems
..there are few UI enhancements and standardisations that I had in backlog already which would also keep developer busy while we redesign the app.
Theme color for the header
Supporting information on footer
All action buttons moved to bottom
Waiting Before Moving
Waiting before moving:
Every morning, both the driver and the team lead spent nearly 40 seconds just waiting for the app to load the day’s orders—averaging around 35. This slow start created daily frustration and wasted valuable time before deliveries could even begin.
Too many taps, too little time:
To complete a single delivery, drivers had to navigate through up to 12 steps on the app. This made the process unnecessarily long and mentally taxing, especially under time pressure.
New flows create confusion, not clarity:
When a new workflow appears mid-shift, inexperienced drivers often hesitate to interact with unfamiliar screens. Many complete the delivery in real life but skip app updates, later asking the team lead to manually correct the order status—leading to extra work and confusing the customer with inaccurate tracking.
Risky calls on the move:
Drivers often call customers while driving to inform them about upcoming deliveries. During these calls, they simultaneously refer to the app to check order details and ETA—forcing them to juggle both tasks and putting their safety at risk.
Premature exits from the workflow:
Some drivers mistakenly assume a delivery is complete and exit the app before finishing all required steps, resulting in incomplete records and operational gaps.
Challenges
Improve order fulfillment speed and rider efficiency within one month.
Increase orders per rider (35 → 38 per day) and reduce failures (5 → 2 per day).
Reduce on boarding time for new riders and simplify workflows.
Work within constraints: limited resources, hybrid architecture, and phased implementation.
Approach
Week 0 – Research & Planning
Conducted field study at Delhivery’s last-mile center to understand rider pain points.
Observed key behavioral patterns: frequent customer calls before delivery, reliance on mobile holders, and cognitive overload due to excessive app prompts.
Identified performance bottlenecks, redundant actions, and navigation issues.
Mapped out an initial plan: documenting current usability issues, outlining quick fixes, and defining reusable UI components for faster prototyping.
Design & Execution
Prioritizing Usability & Efficiency
Simplified the home screen to show nearby orders first and load additional orders on demand.
Optimized the pickup and drop flow, Reduced unnecessary clicks, standardized button placements, and introduced clearer CTA hierarchy.
Performance Enhancements
Addressed the ~40-second loading time by restructuring how orders were fetched, allowing immediate access to nearby orders.
Eliminated excessive loading screens, reducing wait time.
Improving Rider Communication
Bell icon feature: Riders previously called customers before arriving, but many calls were missed due to spam filtering. We introduced a bell icon that sends a text message with ETA, reducing missed deliveries.
Less intrusive notifications: Reduced redundant confirmations to avoid cognitive overload.
Development & Rollout
Phased Implementation:
Phase 1 & 2: Focused on core flows (pickup & drop, verification modules, and end-of-day processes).
Phase 3: Covered secondary flows (search, order scanning, full-screen loaders, and map view).
Release Process:
Wednesdays & Fridays: Releases were pushed twice a week.
Bug Fix Cycle: Wednesday release issues were reported by Friday, fixed by Monday, and included in the next release.
Outcome
✅ 20% faster flow completion, reducing clicks and interaction time. ✅ Lower failed deliveries due to better user experience and communication tools. ✅ Reduced training time, allowing new riders to onboard quicker and navigate the app with ease. ✅ Improved order visibility, ensuring drivers could start deliveries instantly.