QWIPO · 2025
B2B
Android mobile app
Consumer goods
Reducing decision fatigues of Kirana store owners
Most users left the product listing page without clicking anything. Redesigned the card - drop-offs fell from 16.7% to 2.2%.
MY ROLE
Product Designer
TIMELINE
Dec ‘24 - Jan ‘25
RESEARCH
Contextual Inquiry
OWNERSHIP
UX & visual design
Prototyping & testing
Handoff
ABOUT THE PRODUCT
Qwipo is a B2B mobile marketplace connecting Kirana and general store owners with FMCG and grocery wholesalers. Retailers browse and order stock digitally; wholesalers list and manage inventory - all on one platform, with integrated logistics.
Its key differentiator: wholesalers can showcase products the way they would at a traditional mandi, creating a familiar digital equivalent of physical marketplace browsing. Competitors include Udaan, Jumbotail, and Solv.
1
Browse categories
Retailer opens the app and navigates to an FMCG category.
→
2
Compare SKUs
Scans multiple product cards to find the best price and vendor.
→
3
Select & add to cart
Picks the variant and vendor, adds to cart in one tap.
THE USER
Kirana and general store owner
Mobile-first
Solo operator
Time-poor
ORDERS
Weekly restocking runs, multiple SKUs
DECISION CRITERIA
Price per unit → Vendor → MOQ → Delivery
BLIND SPOT
Can't mentally calculate % savings from MRP vs SP at speed
THE PROBLEM
Analytics flagged a 16.7% drop-off on the SKU list page - one of the steepest exits in the purchase funnel. Users were landing, scanning, and leaving before making a decision.
The card showed data. It didn’t help users decide.
STORE OWNER
Paying more without knowing it
PLATFORM
Abandoned orders = lost GMV
WHOLESALER
Lower visibility, fewer sales
IDENTIFYING THE BLIND SPOTS
I audited the existing card against what store owners actually need to make a purchase decision - and found four places where the UI was working against them.
Product card
1
Variants of SKU
2
MRP of the SKU
3
Selling price offered by the vendor
4
Logistics partner name
5
Discounts offered by vendor on bulk orders
6
Vendor selection dropdown
Product details bottom sheet
1
Vendors selling the same SKU
2
Case sizes and prices offered by the vendor
THE REDESIGN
The card doesn't need to show everything. It needs to show the right things in the right order.
SCREEN 1
PLP
1
Vendor name
2
Delivery fee charged by the vendor
3
CTA to minimise product card
4
SKU variants
5
“Best price” badge
6
Discount offered by the vendor
BEFORE
Only one vendor visible at a time
Vendor listed generically - no hierarchy
No visual signal to indicate best option available
No delivery fee information
AFTER
All vendors visible on expanding product card view
Vendor listed in ascending order of selling price
Vendor names prominent with "Best price" badge
Delivery fee details flagged inline per vendor
SCREEN 2
PDP
1
% off - no mental math
2
Number of units added in cart
3
All vendors visible at a glance
4
Case size, SP and discount offered
BEFORE
Price offerings visible only for one vendor at a time via tabs
No % off - only raw MRP vs SP
No delivery info for vendor cards
No running cart total visible
AFTER
All vendors visible as cards simultaneously
% off shown on every vendor card
Delivery fee shown per vendor upfront
Live cart total visible with number of units added
IMPACT
16.7%
PLP drop-off rate before
→
2.2%
PLP drop-off rate after
(3 months post shipping)
1 tap
to compare vendor pricing - previously required opening a separate popup
WHAT I’D CARRY FORWARD
01
Information hierarchy is the interface
The data was always there. What changed was the order in which it appeared. Putting % off and vendor name first - matching the mental model store owners use - was the entire fix. No new data, no new features.
02
Push for usability testing earlier
Most validation was reactive - analytics post-launch. Even 5 sessions with actual Kirana owners before finalising the card layout would have validated the information hierarchy assumptions faster. I'd push for this earlier next time, regardless of timeline pressure.