Order Tracking System
Rebuilding parcel tracking for 2M+ daily visits — across three platforms that each told the customer a different story.
- Role
- Lead Product Designer
- Scale
- 2M+ daily visits
- Platforms
- Android · iOS · Web
- Duration
- 3 months
2M+ visits a day. One question.
If you've ordered from Amazon, Flipkart, Myntra or Meesho, Delhivery has probably carried a parcel to your door. The order belongs to the brand. The wait belongs to us.
Where is my package?
A festive gift, 50 km from home, sitting still for days.
In transit
Last scanned at the hub · 3 days ago
A relatable moment
A photo of someone checking their phone for a parcel, or a gift waiting at a doorstep.
Every silence becomes a ticket
Five messages. Zero answers.
Each stock reply bought another follow-up. Support had nothing better to send — no readable view of what came next, only the last scan.
Paraphrased from real escalations.
Where is my package? It's been in transit since Monday.
Your shipment is in transit and will be delivered soon.
Same status as yesterday. Last scanned in Mumbai.
There's been an uncontrollable delay. We regret the inconvenience.
That tells me nothing. When will it actually arrive?
We knew more than we said
Tracking was built on the last scan, so it only ever reported the past. What would happen next was already in our systems, but it never reached the screen.
- What the customer saw
In transit, with an uncontrollable delay
What our systems knewThe truck was 130 km from Bangalore. Delivery was likely the next day.
- What the customer saw
Last scanned at Vadodara. Delivery by 27 Oct.
What our systems knewExpected in Goa by 25 Oct, two days before the date we showed.
- What the customer saw
A route from Delhi to Vadodara
What our systems knewA Vadodara to Goa parcel. Delhi was only where the order was manifested.
The misleading route
The old app drawing a Delhi to Vadodara path for a Vadodara to Goa parcel. Blur any address or phone number.
Tracking only ever looked backwards.
It told people where their parcel had been, and never what would happen next. Every silence turned into a follow-up.
The customer
Refreshing the same status, with no idea what comes next.
The support agent
Reading raw scans, sending stock replies.
The brand
Taking the blame for a wait it can't see.
Fewer tickets. More trust.
Cut the ticket count
Most tickets ask one thing: where is my package, and when will it arrive?
Earn trust through clarity
It's never just a package. It's
- a hope
- a pride
- a long-awaited watch
- a book
It's an emotion — so share every detail, and earn that trust.
Three conversations reframed the problem.
With my alter ego
Do we even need a new tracking system? Can't we just handle tickets better?
I don't want users reaching the ticket page at all. Trust has to be won on the tracking page itself.
Why can't the current design earn that trust?
It looks fine when everything goes right. The moment there's a delay it gives you nothing — and web and app don't even match.
A system-level revamp is needed.
With customer service
People reach CS when things go wrong — that's where the real failure modes live.
- Orders delayed
- Fake remark from the field executive
- Longer TAT than expected
- Where is my package?
- Package damaged
Design for the happy flow — and for the moment it breaks.
With our customers
- 1
- 2
- 3
- 4
- 5
- 6
- 7
The first five: “I don't have any problem.” What?
“The FE says he'll reach in 2–3 hours. I wait, and I can't plan anything for those 2–3 hours.”
“For a high-value order I check the app constantly, but I see the same information all day.”
Reduce anxiety. Earn trust through clarity.
The map nobody wanted
Couriers
- DHL
- Bluedart
- India Post
Consumer apps
- Swiggy
- Zomato
- Amazon
- Flipkart
The pattern
In quick commerce, the map is a pillar of trust. You always know where your order is.
The question
Could a courier app carry a map — for the whole journey, not just the last mile?
Instant rejection
Not feasible. Too much effort for the return. Three versions proposed; the map turned down.
A month later
I was asked to build the entire flow with a map view.
7 days in Goa
My manager and I spent a week at our Goa head office, built entirely around the tracking page — with CS to find the underlying problems, and operations to learn what could live on the map.
- CS team
- Operations
- Data-driven decisions
Iteration
The iteration story goes here — how the design changed between rounds.
Built from three parts
The map
Two views, depending on how close the parcel is.
The tracking card
Two segments, scannable in a glance.
Hover to see the decisions
- Pickup dateIf a shipper is slow to hand the parcel over, that delay shouldn't read as ours.
- The answer, in one scanDate in bold, days remaining right beside it.
- Consignee and contentWho it's for, and what's inside.
- AWBTap and hold to copy.
The timeline
The whole story, in seconds.
The bar is alive
It fills as the journey moves — and turns yellow exactly where a parcel ran late.
Only what still matters
Where it was, where it is, where it's heading — with the distance left.
Assembled
Map, card and timeline in one screen. One scroll, and the customer never has to ask where their package is.
- The map
- The tracking card
- The timeline
Six states, one answer
The C2C journey end to end. Each state answers the same question with a little more certainty.
Two journeys, same surfaces
C2C starts with a pickup. B2C starts with a seller. Only the first promise changes.


Built for when it goes wrong
The happy flow was never the hard part. Every edge case needed its own state — on the same three surfaces.
- Delay
- Lost
- Weight mismatch
- Incomplete payment
- Returns
- Refunds
- Reattempts
- OTP
Where is my package?
The question that drove most of our support volume now answers itself on the page.
More work


