Discovery Methods

A. Problems from a normal UX audit: I went through the app flow by flow, like a regular UX audit, and noted anything that felt unnecessarily long, inconsistent, or confusing.

B. Problems from on-ground shadowing: I shadowed couriers on the ground and watched them work in real life, which surfaced a lot of “small” issues and workarounds you’d never catch from a desk.

C. Problems from the satisfaction survey: I pushed to run a satisfaction survey (it hadn’t been done before), then I sat down and read 3,000+ comments one by one. It was exhausting, but it gave me a much more real feel for what people were actually struggling with.

Problems

I ended up finding around 45 to 50 issues across the courier experience. First, I grouped them into three buckets: UX issues, technical issues, and operations issues. Then I prioritized them by severity.

In this case study, I’ll keep it focused and only walk through two of the biggest problems, and how I solved them.

1) Too many delivery steps

The delivery flow had way more steps than it needed. Even simple, repetitive actions took longer than they should, which adds up fast when you’re doing 50 deliveries a day.

2) Avoidable repeating trips.

In shipping, not every order can be opened by customers before delivery, some merchants don’t allow it. So whenever a customer asked to open a package first, the courier had to send an in-app request to the merchant and wait.

If the approval came after the courier already moved on, it meant returning to the same customer again, creating avoidable back-and-forth.

Solutions

1) 50% Fewer Delviery Steps

The delivery flow used to take 4 steps. Two of them felt like “process rules” more than real value.

Scan shipment before delivery: The operations team said it’s to make sure the courier has the shipment and to capture a location stamp. But the courier already scans shipments at the hub when receiving them and scanning again at the door isn’t a real guarantee (a courier could’ve saved a photo of the barcode). Also, the location stamp can be captured from the final confirmation step.

“Are you sure you handed the shipment?” This extra confirmation felt unnecessary because the courier already enters the customer OTP. I replaced it with a simple slide to confirm interaction.

2) 74% Reduction in Repeat Trips

As I said above, In shipping, not every order is allowed to be opened before delivery by the customer, some merchants refuse because of their policies. So when a customer asked to open the package, the courier had to send a request to the merchant in-app

If the merchant approved it after the courier already left (which happens all the time), the courier had to go back to the same customer again, which wasted a lot of time.

To understand how big the problem really was, I extracted the current year of “open package” requests and found that 74% of merchants always allow it and 16% always reject it.

Based on that I added it as a simple configuration in the desktop merchant portal which removed most of the unnecessary waiting and repeat trips.

Impact

1) 50% fewer delivery steps

On a normal day, a courier does around 50 deliveries. Before the redesign, that meant roughly 200 steps inside the app. After simplifying the flow, it became around 100 steps for the whole day.

2) 74% fewer repeat trips (open package)

Allowed “Open package” requests usually represent around 25%–30% of daily deliveries.

With 3,000 couriers doing 50 deliveries/day, that’s about 150,000 deliveries/day.

Repeat trips caused by this issue (25%–30%): 37,500–45,000 repeat trips/day.

Saved repeat trips after the fix (74%): 27,750–33,300 trips/day.

Practically, this means couriers can fit more than 50 deliveries/day into the same working hours, so they earn more per day, and the business can push higher daily throughput (which directly impacts GMV).