My Version of Google Pay

Problem Statement:

How would you go about improving monthly frequency among monthly transacting users, by focusing on the UX?

About G-Pay:

G-Pay is a digital wallet platform and online payment system developed by Google to power in-app and tap to pay purchases on mobile devices.

Plan of Action (POA):

The way I would like to go about this would be:

• To Identify focus User Segments and Payment Types. (Finding Trees)
• Understanding User Pain Points and to prioritise one. (Picking dry woods)
• Defining Success Criteria. (What’s the warmth are we expecting from the fire)
• Proposing Potential Solution(s) to solve the User Pain points (How to light the fire)
• Defining Success Metrics and Kill Metrics. (To gauge the warmth of the fire, to also check no one gets burned)

Segmentation:

There are mainly two types of users on the G-Pay platform;

1. Merchants
2. Individual Users

There are mainly two types of payments;

1. Individual to Merchant
2. Individual to Individual

Lastly, there are two use cases on a sky level, where Users use G-Pay for;

1. Unplanned payments
2. Planned payments

Assumption 1: For this problem statement, I will focus on individuals as most of the features will directly impact this cohort and secondly to make it more relatable. Here, I will restrict myself to Monthly transacting users (at least one transaction per month).

Assumption 2: I will consider both types of payments i.e Individual2Merchant and Individual2Individual to identify the user pain points, as the flow remains the same.

Assumption 3: Frequency can be increased with increase in rewards and cash backs which indeed is a delightful UX. However we would explore some other methods to improve the frequency. Given increased cash backs are no longer a motivation, I would focus on the Planned payments use case as the Unplanned payments is more co-related to rewards. (Zero cost to switch)

User Pain Points:

As a User whose transactions are mostly planned, Such transactions are generally repetitive and usually fixed in nature, especially those one need to pay monthly.

Example: Society fee, Gym fee, OTT Subscriptions, Utility bills, House rents etc.

One has to perform multiple steps to complete each transaction, and it takes a significant amount of time. Multiple Steps being:

1. Searching whom to Pay
2. Entering the amount every time I make a payment (which might vary or be fixed on monthly timelines)
3. Click on the “Pay” Button
4. Enter Pin

It takes 4*X hard steps for X number of transactions (After opening the App)

Success criteria:

• At least 1 extra transaction per month per target user.
• Number of Steps should NOT be a function of Number of Transactions (X)

Proposed Solution:

G-Rep: Introducing G-Repeat, where Users can customize their repetitive expenses (both fixed and variable) and pay at once. However, at the back-end, it will generate multiple transaction IDs for each unique payment output, resulting in users getting a chance to earn Cashbacks & Rewards for each unique payment output.

• The amount of all repetitive expenses can be paid at once.
• Users can Select/De-select the expense(s) based on needs.
• Users can add new expenses or delete any existing expenses.
• The last paid amount will be shown by default as these are generally fixed and repetitive. However, Users can edit the amount if needed.

Link to Prototype

Kill Metric(s)

Transaction success rate using G-Rep / Transaction success rate through conventional method
To check if the feature is actually serving the purpose of saving time

Success Metric(s)