Improving Discovery and Navigation for Amazon Pay UPI Users
Why Amazon Pay UPI users drift to Google Pay and PhonePe, traced to navigation rather than features
✳The problem they went after
Amazon Pay UPI lives inside an app organised around shopping, not payments. QR scan is buried deep and rarely found on its own, and cashback offers and rewards are scattered across sections with eligibility that is hard to read. Users who would prefer Amazon's ecosystem benefits end up on Google Pay or PhonePe because those are simply faster to reach.
✳What they actually did
Three segments were studied. Frequent Amazon shoppers cannot track and claim rewards as easily as they can on a dedicated payments app. Offline QR users walk a path through Options, Amazon Pay and Scan where one tap should do, so they abandon it for faster alternatives. Power users who know about widgets and home page shortcuts got there with no in-app guidance, meaning the built-in advantages sit unused. Two hypotheses follow: surface Scan and Pay and Rewards earlier with contextual prompts, and teach the wallet button and UPI widget directly.
✳What you can take from it
Worth stealing
- Three segments defined by behaviour, not demographics
- Multi-step QR path counted tap by tap
- Hypotheses written to be validated, not shipped
- Contextual prompts and guided education over new features
Read this if
Adoption is flat and you suspect navigation, not the feature itself
The transferable bitNothing here is missing from the product, and the write-up resists proposing new features anyway. Segmenting by how people actually reach the feature, rather than by demographics, is what makes the navigation cause visible and leaves two hypotheses you can genuinely validate.
✳The submission itself
Open the PDF →Reading on a phone? The embedded viewer is cramped — open the PDF in a new tab instead.
