top of page

Amazon PayLater




The goal of this project was to re-design the Amazon Pay Later(earlier Amazon Pay EMI).

Amazon Pay Later is a virtual line of credit to eligible customers shopping on Customers can pay the entire purchase amount next month at no extra cost or pay in 3 to 12 EMIs.


To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study.





This application was already live when I joined Amazon. I am the current Design owner. I focus on understanding users and their challenges, defining new flows, interaction design, visual design and design quality check post development.




  • Registration rates were low

  • ~50% of the registered customer were not using the credit line

  • Onboard new lender to expand this features to more customers



Research insights — Brainstorming + Explorations — Solution + Development



We did tons of market research, interviews, surveys over a period of 9 months.


Key issues 

  • India is majorly cash driven economy where people avoid credits

  • Registered customers thought "Amazon Pay EMI" can only be used for high value items 

  • Customers generally buy high value items 2-3 in a year

We didn’t want to just improvement the current payment experience. We wanted to reimagine the whole product.





Few interesting insight that I derived from the data I collected during research.


  • I asked the tech team to retrieve last 2 years data on how lists were created and what parameters were used for creating these lists. After looking at the data I realized the most of the lists were created by using upload options.

  • After looking at the data I also realized that the users were using the same set of filters most of the times.

  • Basic flexibility such as ‘OR’ between conditions was missing. In a lot of scenarios, users wanted to do an OR between conditions, but the system didn’t have that option. Users were creating 2 lists and then merging them into one.

  • There was a good number of cases where users wanted to target the same set of users but since that was not possible, they were exporting the list from one campaign to upload in another.

  • Since lists were only available in the campaign manager, users were creating segments to use in other products

  • In some cases, the predefined filter labels were misleading. In some filters, the mentioned date was included, whereas it was not in the rest. This did not inspire confidence.

  • During list creation, users look for audience level data such as reachable customers and demographic wise distribution, as it helps make their targeting more effective.



Based on these insights, I realized that there will be 2 types of users

          1. Account managers - The ones who will be consuming the content

          2. Analytics team - The ones who will be creating the content and sending it to the account managers.



Based on the user research and insights, my primary objective was to resolve these problems.

  • How to introduce complex filter conditions:

Quite a few brands were using very complex filter conditions while creating their list, but the usage wasn't that high. The first approach was to define all the possible filter condition, but this will result in too many filters. Users will ask for new filters now and them, which will unnecessarily make the filters list cluttered. The second defines basic filters and in each filter give few optional fields for advanced filtering. This will solve most of the scenarios with minimum no of filters.


  • Information architecture choice:

Audience groups will be consumed in the Campaigns and Loyalty systems for precise and personalized targeting. They will also be used in the Reporting product for further analysis. In the future, I wanted to allow list creation from within this product, as most analysis is anyways done there. So the question here was that where will audience manager reside. The first approach was to keep it under Campaigns, but Analytics associates do not have access to it. So, they’ll have to pass on the information or the finished lists to Account managers. The whole process feels bit complex and lengthy. The second approach was to keep it under the Reporting product, but in that case, Account Managers will always have to depend on the Analytics team to create the list, which is not a good idea. The third approach was to keep it in the shared repository, where both users will have access.


  • Filters rewriting the filters

I tried multiple approaches. Top three approaches are shown below. Since the end users, this system has a mix of technical and not technical people I wanted to make the filtering language as simple as possible. The filters are written in such a way that novice users who don’t have any clue can also use it easily. New filters are written in a very normal way without jargons.

  • AND & OR operations 

Screen Shot 2019-01-28 at 10.47.01
bottom of page