Shrey Bharadwaj
Objective
Create a Transaction detail page where the user lands from his transaction history entry point for a specific transaction, encompassing all transaction details from top to bottom creating an information hierarchy prioritizing users need for information and action.
Why do users visit Amazon Pay Transaction History page?
Monitoring Transactions
Verification of Payments
Budgeting and Expense Tracking
Refund and Dispute Resolution
Tax and Financial Reporting
Recurring Payments Management
Security and Fraud Detection
Payment History Sharing
Managing Multiple Accounts
Customer pain points
The issues customers experience when using the product or interacting with the service. These problems negatively impact the customer experience and must be addressed to attract new business and improve customer retention.
Discoverability
Search-ability
Information gap
Action gap
Generic labels do not aid in realizing what the cashback was received against and entails that customers would need to take extra steps. Customers propensity to click for more details needs to be analyzed quantitatively
Customers exhibit a tendency to use tabs and not so much filters to find specific transactions (e.g. a cashback from Swiggy). Hypothesis: Filters is not an experience that customers associate with transactions. They tend to associate it more with retail.
Something to think about: Providing the information in one place does not necessarily make it fit with the customer’s natural behavior (like accessing YO) or make it useful.
Customers typically remember recent transactions but are unable to distinguish some of the older ones. Hypothesis:
Transactions do no carry any obvious marker of the ASIN/category which was purchased. The current iconography is not sufficient.
The transaction has stopped being relevant for the customer unless the order was not delivered or the payment failed or he/she is awaiting refund etc.
The transaction was carried out by someone else who the account is shared with.
The label does not clearly communicate what the options would be. The options of ‘Amazon.in’ and ‘Partner merchants’ are not presented in customer friendly language. Only on making guesses do customers comprehend what they actually mean.
Timeline would contain Months and Year is not clear from the label. Simply writing Month/Year might be easier to comprehend.
That customers will have to clear the filter before using tabs is not intuitive for customers.
On filtering with Amazon Pay balance, this information shows up. Customers do not really interact with it. The information visually blends with the rest of the page and does not look distinct.
Customers did not understand the difference between Money and GC
Initial Limitations
!
Cashback earned for any particular transaction is shown as a separate item. The problem with this is that it is very hard to find track the transaction for which the cashback has been received. Also User can not understand if there any any cashback that are pending.
!
Two statuses clashing with each other. This may confuse users and also logically wrong.
!
The current Download statement CTA doesn't work.
!
The status is ambiguous and difficult to understand.
!
Plus and minus amount is easy to understand in case of money debited and credited to own account. But when self transfer and add money cases it becomes meaningless as both the accounts are of users own.
User Stories
I should be quickly able to identify the transaction through the transaction name/title.
Re-establish data hierarchy and information architecture for transaction detail page.
I should be able to easily identify whom did I pay or received money from.
Add a Receiver and Sender widget to the transaction details page.
I should be able to pay/transact again with the person/merchant who sent me money or whom I paid money.
Add a Pay again CTA on the Transaction detail page.
I should be able to pay the sender/receiver/merchant directly from detail page page.
I should be able to pay the sender/receiver/merchant directly from detail page page.
I should be able to know if my bill was paid successfully so that I can be sure that I wont be charged any late payment fees.
Create clear transaction status messages along with template for additional server side messages related to the payment status.
I should be able to see payment break up details. (if there was discount, convenience fee, tax etc involved.
Have a clear ‘Payment details’ section with payment breakup discount, convenience fee, tax etc involved.
Provide an option to download payment receipt and invoice for all use-cases wherever applicable.
Have CTA to download Payment receipts and Invoices.
I should be able to reach out to customer support directly from TH page so that someone help me resolve my query.
Have CTA for Help, FAQs and support.
I should be able to know all the relevant details about refund.
Have a related refunds and cashback section for the transaction.
For any failed transaction, I should be able to retry the payment from the transaction detail page only.
Have a retry CTA in case of Failed Transactions.
Derived Goals
Competitive benchmarking
Note: Benchmarks are in regards to there state at the time of research rather then the present UI of these competitors which is subject to keep changing over the course of time.
Before reinventing the wheel, we had a look at how other players in the market, were solving this problem of showing a transaction history and comparing our present UI with them and looking at where we stood.
Feature based Analysis
Functional UI, gives user control to functions like Check Balance and pay again etc.
Easily accessible Help.
Transparent system messages showing system/Transaction status.
Minimal design.Good documentation of transaction details.
Good information hierarchy.
Mindful features like Check balance, Pay again [New Payment], Share etc.
Timeline of payment process, shows system transparency.
Minimal Functional UI.
Good Information Hierarchy.
Minimal Aesthetic UI.
Easier for users using the Chat platform to make concurrent payments during conversations.
Good visibility of system status.
Features like Pay again and help contribute to user control.
Information Structure
Information structure is based on following metrics:
Information Priority
User anticipation
Information inter-relation
Visual Flow on the page
This is an early version of the information skeleton which is followed to some extent across all the subsequent iterations.
Information Categorization
Primary Transaction Details
Transaction status
Amount
Transaction note
Transaction sub-status
Primary call to action [if any]
Payer/Payee details
Name
Bank Details
Related call to actions [if any]
Rewards
Casback/Refunds
Secondary Transaction details
Date and Time of Trasnactions
Trasnaction ID
Related call to actions [if any]
Secondary call to actions
CTA 1
CTA 2
Explorations
Exploration 1
Exploration 2
Exploration 3
Iterations
Iteration 1
Feedback
‘Share’ CTA needs prioritization.
Need a widget to track payment sub processes
Iteration 2
Feedback
Need a cta for ‘More actions’ at the top
Iteration 3
Feedback
Keep the top widget from Iteration 2
Add a product detail widget in case of shopping use cases.
Shift cashbacks/refunds as Tabs.
Final UI
Once we had a transaction detail page ready and approved, now we had to implement those designs across 50+ categories.
