I still remember the moment this task landed on my desk: “Redesign the shopping history flow.” Sounds straightforward, right? Add a few filters, clean up the cards, maybe throw in a search bar and you’re done. At least, that’s what I thought.
But like many things in product design — especially in healthcare — the surface simplicity hid a mess underneath.
Let’s step back for a second. The app I work on connects dieticians and trainers with their clients. It’s a one-stop digital platform where patients can log water intake, meals, sugar levels, periods — things they’d otherwise manage via messy WhatsApp threads.
There’s another feature too: a shop, where dieticians can recommend or sell products to their clients. Think of it like your dietician adding essential supplements to a cart for you — and you just have to pay.
But here’s the catch: sometimes the user buys the product themselves, and other times, the dietician places the order — either as prepaid or COD.
Now imagine being a 60-year-old user. You open the app and see a product order you don’t remember placing — and it’s asking you to pay. You didn’t tap anything. You didn’t get a message. The interface just expects you to understand. But you don’t. Because the design never told you.
As I started diving into the old UI, here’s what I noticed:
Nowhere did it say who placed the order.
The product name was buried in visual noise.
The price and taxes? Vague at best.
When multiple items were ordered? The layout broke down.
I thought this was it — until I dug deeper. I looked through support queries. I talked to the team. And I realized the real pain wasn’t visual. It was invisible.
Users had to call their dieticians just to ask if an order had been placed.
Prepaid orders sat unpaid because users didn’t know they had to pay.
Most couldn’t even remember having a conversation about that product.
The flow relied on one thing: push notifications — many of which were disabled.
I needed to get under the hood.
I sat down with the developer to understand how the backend was wired. I still remember this bit of the conversation:
Me: “How will the user know that the dietician placed the order?”
Dev: “They’ll get a notification.”
Me: “Okay… but what if they want to cancel the order?”
Dev: “They can’t. Only the dietician can cancel it.”
That was it. The moment I realized: this flow isn’t just broken — it’s unbalanced.
Users had no control, no visibility, and were left guessing in a health-critical purchase flow. That’s not just bad UX — that’s a breach of trust.
I raised this with the founder. He replied, “Users are older. They rarely cancel. Most of the time, orders go through.” Fair point. But what about:
Duplicate orders?
Products no longer needed?
Dieticians unavailable?
I fought for it — and we found a middle ground: add a “Cancel Delivery” button, but hide it inside the Order Detail page. A soft red ghost button. Not front-and-center, but there when you truly need it. That’s intentional friction, done right.
Tell users who placed the order, and when.
Make it crystal clear if they needed to pay, wait, or take no action.
Make multi-product orders scannable.
Organize info by what matters most to a confused or cautious user.
All this, while keeping the interface familiar to users already used to the old design — however broken it was.
I turned to the pros. I opened Blinkit, Swiggy, Zomato, Amazon, and Flipkart, not as a customer, but as a designer. I watched how:
They grouped data.
What they showed first.
How they reduced friction in placing, tracking, and understanding orders.
Blinkit stood out — clean structure, tight labels, minimal friction.
I started with the obvious:
A search bar at the top — and a mic icon for voice input (accessibility win).
Tabs for Pending, Shipped, and Delivered orders.
But then came the biggest challenge — how do I show ownership?
I tried inline text: “Ordered by Dietician.” Result? Clutter. I tried bordered tags. Still too noisy.
Then it hit me — why not categorize orders into two sections?
🧑⚕️ Ordered by Dietician
🙋 Ordered by You
I had concerns: what if one category pushed the other too far down? But after confirming with the founder that users usually stick to one type, I locked it in.
Then came the card.
Product name, quantity, image — clean and consistent
Final price with “(incl. of tax)” — adds trust
No per-item pricing on summary cards — avoids overload
Multiple items? Show the first one, then a line: “+2 more items” — inspired by Amazon
The mode of payment (useful to let the users know if its COD or prepaid)
But then came the biggest challenge — how do I show ownership?
I tried inline text: “Ordered by Dietician.” Result? Clutter. I tried bordered tags. Still too noisy.
Then it hit me — why not categorize orders into two sections?
🧑⚕️ Ordered by Dietician
🙋 Ordered by You
I had concerns: what if one category pushed the other too far down? But after confirming with the founder that users usually stick to one type, I locked it in.
Then came the card.
Product name, quantity, image — clean and consistent
Final price with “(incl. of tax)” — adds trust
No per-item pricing on summary cards — avoids overload
Multiple items? Show the first one, then a line: “+2 more items” — inspired by Amazon
The mode of payment (useful to let the users know if its COD or prepaid)
Added extras:
A subtle nudge to contact sales
Clean UX copy — swapped “In Transit” for “On the Way” and others using GPT feedback
Here, I gave the user what the main card doesn’t:
Banner tags at the top of each detail page:
Red = Awaiting Payment
Yellow = On the Way
Green = Delivered
Item-level prices
A soft red ghost button to cancel (visible only in Awaiting Payment / In Transit orders)
Full price breakdown (tax, total, etc.)
Order ID (low priority, but present)
Other details such as delivery address
The feature isn’t live yet. But here’s what we’re betting on:
Less confusion around mystery orders
Faster payment on prepaid items
Fewer dietician calls, fewer support tickets
More trust = better reviews
Add “Contact Dietician” inside Order Detail
Once Shiprocket goes live, enable Track Delivery
Add a Download Invoice option for paid orders (added this, discussion pending)