Senior UX Designer, India Domestic Team, PayPal (2018–2021)

UX Case Study — Bringing PayPal UPI services to India

Designing PayPal UPI and competing with giants like Google Pay, Phone Pe and PayTM in a highly competitive and incentives-driven market — India.

Building P2P experiences

In 2018, PayPal started working on bringing UPI payment services to their platform and allowing users to send or receive money using UPI’s framework.

I led this large design project to integrate UPI in PayPal for the core ‘send and receive money’ user flows for one of the largest online payment processors in the world.

DISCLAIMER: To comply with my non-disclosure agreement, I have omitted and removed confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of PayPal.

India as a market

India is a heavily crowded market when it comes to online payment space. Local players like PayTM, PhonePe, Bhim UPI, Freecharge, Jio Money, and foreign players like Google Pay, Amazon Pay have the advantage of early entry into the market, thus gaining a large market share. Government and private bank apps (ICICI, HDFC, SBI, etc.) are also among the most popular digital payment apps.

Business objective

There is a huge opportunity to capitalize on when it comes to the P2P market in India. We looked at the current scenario and future projections to justify the need to build P2P.

1. India is the second-largest and fastest-growing P2P market for PayPal​.
2. India P2P Market poised to grow to $159B by 2022​.
3. Fastest growing with CAGR of 70%​.
4. UPI is a game-changer with an interoperable, instant bank-to-bank transfer. It is the fastest adopted payment option surpassing wallet (balance) volumes within 2 years of its launch​.
5. Crowded space with multiple players solving basic send/receive use-cases.
6. Significant opportunity to differentiate via use-cases/experiences/social integration.

The challenge: Building P2P experiences

Status quo of PayPal in India
Despite being a global leader, in India, PayPal is not a popular brand. People in India only resonate with PayPal as an international brand. The perceived value of the brand for people in India only lies in terms of foreign purchases/shopping or money transfers from abroad.

Our vision was to build core P2P experiences for consumers and businesses that can adapt to the ever-evolving Indian market.

Our high-level goals were to:

1. Build user validated P2P experiences for Indian consumers,
2. To offer differentiated experiences to users, and
3. To offer multiple payment methods from PayPal’s bouquet of offerings
   (Regular card payments (Debit, Credit, Net Banking), alternate payment method (UPI), PP checkout, subscription, installment, credit, etc.)

My role and responsibilities

Senior UX Designer, India Domestic Team, PayPal.

User research

1. Understanding users
   I helped the research team drive user studies (experience mapping, discussion guides) to uncover, understand and quantitatively analyze user behavior w.r.t payments.
2. Usability tests
   Observed multiple user testing sessions and also conducted interviews over days and helped the team gather feedback, insights. And finally helping the team in compiling the final read-out.

User experience

1. Competitive Analysis
   Once our main competitors were identified, I conducted an evaluation of their end-to-end user experiences.
   I was mindful of
   • our product’s goals,
   • how we want users to feel using our product, and
   • why they would prefer using our product over the competitors.
2. User stories
   I aligned with product partners to understand and write user stories for each stage of the process. All goals were clearly defined from a user’s perspective that tally with the feature set our product team wanted to build.
3. User flows (End-to-End)
   With the help from the product team, I identified all use cases very thoroughly and built a network of flows that capture end-to-end experiences, with each segment clearly defined and at the same time giving a larger view of how each of these flows is intertwined

Collaborative Design Process (Internal)

1. Working sessions
   One of our main collaborative strategies is to have a couple of working sessions with our stakeholders. What this helps is in critical thinking, gaining instant insights, solve complex technical challenges, close open-ended touch-points, and take measurables decisions quickly.
2. UX Reviews (PayPal’s internal UEDs)
   One of my weekly goals was to present the design to our community of UEDs and get feedback and insights. This helps in streamlining the designs and keeps a check on re-using existing patterns and construct wherever possible.
3. Senior Leadership Team Design Reviews
   Apart from my weekly UX review cadence, my role was to present the proposed designs to the senior leadership and support the design directions that we have adopted, get feedback, and iterate based on the feedback and insights received.

User Interface

1. Sketches & Wireframes
   Right from the kick-off meeting, we start working on creating flows by doing paper sketches, whiteboard wireframes, etc. The idea is to go wide and then start narrowing down on the design solve.
2. High-fidelity mockups
   To be ahead of engg, we started working on high-fidelity mockups that were close to the actual design while in its formation phase.
3. Designs
   We switched from working on the Sketch app to Figma as an organization and built our designs on it.
4. Protos
   We have planned to finish highly functional prototypes in Figma, during our research and usability testing phase.
5. Dev Handoff
   Again we leveraged Figma’s capabilities to design and deliver flows right in the app itself.

Restraints and roadblocks

Restraints

1. Our first restraint was a lack of internal tech bandwidth.
2. 6–8 months into the project we faced our second roadblock from RBI’s regulation. It directed PayPal to have the data center in India in order to use transactions of Indian users.
3. This was a major roadblock at that time as all our servers were based out of US.
4. This meant that we can’t deliver a solution purely based on UPI’s framework unless we build data centers in India.
5. We then had to resort to a first-of-its-kind P2P system using a debit card (Read the case study here: Designing first-of-its-kind debit card P2P for PayPal).
6. Adapting to this new regulation also meant we based all our further research, solution discovery, and testing based on this.

Kickoff: Understanding users

Design Thinking 101

The first thing we did utilizing the design thinking framework was to empathize with the users. That meant trying to understand the user with the help of experience mapping and user research.

1. How they go about their daily routines with money-related events that take place?
2. Where and how they spend their money digitally?
3. And for what all transactions do they use digital payment solutions?

1. Empathize

We wanted to get an understanding of our users and their money-related transactions that happen in their daily lives.

1.1 Discussion Guide

I along with the research team started with creating a discussion guide that will set as a base for our research. We essentially wanted to understand users behavior, intention, and motivation for their money related transactions

1.2 Experience Mapping (Current Transactions)

We wanted to understand how users make their transactions—daily, monthly, or yearly whether once or a few times. We asked them to stick post-it notes on the transaction chart we provided to them.

It helped us get a good larger view of their daily, monthly, and yearly money transactions. We could easily gauge the common transactions for all participants and some mid to smaller ones.

Initial user insights

We invited 20 participants from different age groups that were a match to our archetypes we wanted to understand. We focussed on their needs, how are they solving them currently and what are their expectations.

1. “Payment solutions should also help me manage my money well and make informed decisions.”

Consumers wanted payment apps to help them manage money and track expenses to achieve goals.

2. “Need a dependable way of receiving money when in need, regardless of where the sender is or what day of the week it is.“​

Consumers needed a system that can become a fallback when in need of money.​

3. “Digital payment solutions should make everything convenient and quick.”

To ease adoption, the system should be safe, secure, and exceptionally simple.

4. “Find it challenging to split expenses after a night out, movie or a dinner with friends. Multiple apps to complete one task“​

Users needed a single payment solution that will take care of payments as well as help in successfully splitting and settling expenses.

Redefining the larger problem

We realized that payment service providers in India have not solved all the problems of the consumers. They may offer one or two day-to-day solutions to their problems. But consumers are looking at a more cohesive platform that could solve most of their payment-related day-to-day needs if not all. With most of the apps providing a similar experience, we looked at the larger picture and questioned ourselves

“how might we help indian consumers perform their current social money related transactions (mostly offline) digitally with ease and confidence?”

Solutions (Based on deeper insights)

Solution1: To track and manage group expenses

We kept our focus on group traveling which came out to be the most common theme from the research. Users expressed their concerns about money mismanagement during a group journey where they end up spending more than planned.

PAY USING PAYPAL
It all starts right from when the user makes a transaction on any of the partnered merchants using PayPal. By identifying key partners, the system will be intelligent enough to understand the kind of transaction made and suggest actions based on it.

Pain point it solves: User doesn’t need to manually switch between apps and document the transaction. PayPal shall prompt users to take action through contextual communication.

CREATING A GROUP
Once the user proceeds to create a group, they will be redirected to the relevant screen with the option to add details and add friends.

Pain point it solves: Users can easily track their collective expenses once the group is created. It allows each member (friend added) to add additional expense and allows them to settle it then or later.

MEMBER NOTIFICATIONS
As any friend is added to a new group, they will get a push notification (open to explore other communication channels as well) keeping them well informed about group events as and when they are created.

Pain point it solves: A group owner doesn't need to run after each member informing about the group creation expected to evoke an action by members to track and document expenses.

ADDITION OF EXPENSES
Admin rights could determine access levels for each group member. They can easily add expenses and mark them to split if needed.

Pain point it solves: Everyone is allowed to participate by adding necessary expenses as they occur. There is one source of truth for all trip-related expenses.

Some hits and misses from usability test results

The prototypes were navigated completely.

1. MISS: Only 50% read the push notification message. They preferred SMS as the medium for such communication.
2. HIT: 100% of users were able to figure out the flow. They knew how group expenses worked. They understood that some expenses are pulled from payments made on merchant websites/apps.
3. MISS: “Can we see who owes whom? This can be added advantage.”
4. MISS: “Can I get more management controls? Or chat option to explain about the expense made?”
5. HIT: 100% of users found it self-explanatory that everyone in the group can add an expense. The process of adding an expense was expected and went well with users.
6. HIT: Adding expense details with the ability to edit was well received.
7. HIT: “Settle now/Settle later — is mostly same.” No learning curve for users (Split wise as their base expectations)
8. HIT: “Your UI is much better than splitwise.”

9. HIT: “Better to have split feature within a payment app than a separate one”

Solution2: Ability to split bills with friends

One of the most common facet of group events was—one paying now and rest paying later. This was the basis of split bill feature.

We wanted to use the same construct that we drafted for group expenses, with the additional flow for information review and payment method.

In the below illustration, it shows how the notification can engage users to split bill with friends. Again this was based on the intelligent system analysis key events which generally are group oriented.

Some hits and misses from usability test results

Split bill prototypes were navigated completely.

1. HIT: Users liked the fact that the notification directly takes them to event flow.
2. HIT: The amount mentioned in the notification made it look like a genuine message and not a spam.
3. HIT: Adding friends was easy and intuitional
4. MISS: “Can I chat?”
5. HIT: “This flow is better than WatsApp or Gpay as I don’t have to go to multiple products.”

How we got there and how did we solve it

Once we understood the current user transactions and their frequencies during experience mapping, we categorized the transactions into Friends & Family and Goods & Services. We listed down the topmost transactions these users make whether using any app or cash.

2. Define

What we learned from the research (insights, gaps, and opportunities) we then conducted a design sprint to come up with how might we problems statements and solution discovery.

2.1 Design sprint

Organizing the sprint
We organized a 5-day design sprint with a cross-functional team that involved people from business, product, design, and engineering working towards a common goal.

All of them participated in a 3-Day sprint, while the other 2 days were allotted for creating, prototyping, and testing them with users that were run by the UX design team.

Goals
The goal of the sprint was to explore possibilities that will make the P2P experience more engaging, relevant, and a differentiated experience amongst other apps that offer the same.

Starting off
We started off our sprint with ‘talks by experts’ where multiple stakeholders threw light on the overall P2P as it stands today, market, product, and engineering context and their scopes, compliance, and legal policies and where do we want to be in the next 6–10 months.

These talks also touched upon the P2P research findings we have and gave us a direction of how we can derive solutions relevant to the target segment we are solving for.

‘Talks by experts’ session that started off the sprint (Day 1)

There were multiple activities slated for all three days where each of the stakeholders in the room had his or her ideas, thoughts, suggestions, or solutions penned down on paper/notes.

Activities and sessions
We ran through sessions where we derived long-term goals, discussed the risks, wrote, organized, and voted on How Might We notes, picked a target segment, mapped the notes to the segment.

Long term goals and risk involved

Organizing How Might We problem statements

We had a demo of some apps for reference/analysis, followed by the four-step sketching process, speed critique final voting before we went on to make the storyboard for all the scenarios to test.

App demo and analysis

In the last two days, the design team spent time creating the end-to-end user flows for all 4 major use cases that came out of the sprint. And also, doing a quick in-house user testing for all 4 scenarios where we had roughly about 8–10 users trying out our prototypes and giving valuable insights into the solutions we derived. Mentioned below are the 4 use cases for our testing

2.2 How Might We

We derived our problem statements using HMW methodology. We categorized these HMWs into different segments of the experience, mapped it to the target segment, dot-voted the target segments, and then mapped each of these HMWs to the segments and goals we want to achieve.

2.3 Derived Scenarios to test

1. Send money flow
   First and foremost we wanted to create the standard P2P experience for Indian consumers and see where can we add differentiated experiences.
2. Split bill flow
   Another use case that came out of the research was splitting the bill.
3. Ask money — Borrow or request flow
   Borrow or request money was another problem statement that could create a differentiated experience.
4. Expense manager — Create group and share expenses flow
   And lastly, we wanted to give provision for an expense manager within the app that we felt could solve real user problems.

3. Ideate

We split the sprint group and went ahead with storyboarding, one ideation round with divergence and convergence, crazy 8’s, and final ideas to be presented to the group and get voting for the ideas. Each group was given time to present the ideas and give a rationale for their ideas.

We have already had a user testing review meeting with the product team where we discussed what went well in the testing and what the users couldn’t understand or relate to.

For each of the prototypes we tested, we noted down our observations and user insights.

Key Takeaways

Test findings and implementation

We had our rounds of usability testing and received good insights and feedback on how the product will solve users' problems.

With the larger goal in mind and persuading the product to put the differentiated experience in our roadmap. We prioritized our work to be done on feature sets i.e must-haves and good to have, in the next 2–3 quarters.