Razorpay

Context

Valued at $7.5b, Razorpay is one of India's biggest fintech brands.

Their core offering is payment gateway for online businesses. Razorpay were looking to expand to offline payments in India—card, UPI and other solutions for merchants who accept face-to-face payments.

One of these offline experiments was a new technology based on NFC (near-field-communication) to turn merchants’ mobile phones into card machines.

The experiment

A merchant could accept in-person customer payments by tapping customer's debit/credit card on the back of the merchant’s mobile phone, all thanks to NFCs.

In essence turning their phones into card machines that could collect tap-to-pay payments. The tech team had a proof of concept ready with the technology working. I was brought on to answer the biggest questions, and lead the design for this experiment.

The Team

I worked closely with Chetty Arun, the Director of Design, Radha Sagi from Marketing, Kapil Chaudhari from product management, Shubhank Pawar, an in-house product designer, and some developers. I brought on Sai Shinde, a product designer, for part of the project to help with various design and research tasks. Chetty and Kapil guided the team, while Radha helped with research recruitment. Shubhank helped me a bunch with the UI, assets, and the interviews.

My role

As the primary designer and product owner, I was responsible for:

1. UX strategy and project plan
2. Research plan and recruiting
3. User interviews and synthesis
4. Secondary and competitive research
5. Facilitation
6. Interaction design
7. UI design

The strategy

At this stage, Razorpay was yet to define their go-to-market strategy for the offline payments space as a whole, including deeper market research. They wanted to launch and learn from this experiment in the meantime, to test the hunch that there's a market out there for this product. The cost of failure was low, and they had the bandwidth to build this quickly, so we decided to

Keep the time to launch as low as possible, find the best target cohort to address at first launch, and get the experience right based on current merchant workflows.

And later, experiment with targeting and iterating. The user research and learnings from this experiment could also informing the GTM down the line.

I had 8-weeks to research, define and design before development would need to start.

I decided to spend a week on kickoff and mapping hypotheses, two weeks for primary and secondary research to identify target cohorts and understand their current workflows, a week to define the personas and map the journeys, and three weeks for user-flows and then handing off the UI to development.

Research

After some stakeholder interviews, to understand what the team already knew, I identified the biggest questions and objectives for initial research.

The biggest Question

Who might need NFC card payments, when and where?

Secondary research objective: Understand how current card payment workflows happen, and related pains or opportunities

So the first thing I did was gather the team and surface all our hunches, hypotheses and experience-driven tentative answers for this question, along with a preliminary attempt to bucket these into hypothetical cohorts. From research, some of these hunches turned out to be correct, some not. The marketing team had previously done market-research with some of these segments, so I particularly leveraged their insights.

the Hypothesis

We identified 4 cohorts that might need a cheaper/simpler way to accept card payments without traditional card machines:

1. Small physical stores (eg., grocery stores)
2. Boutique luxury stores (eg., organic bakery)
3. Large logistics partners with home delivery fleets
4. Small businesses with in-house home delivery

‍

Secondary research

While Radha filtered the current userbase to send the screener to and we waited for the responses, Sai and I went internet-sleuthing to understand the technology, the offline payments landscape and the competitors.

mapping the landscape & competitors

I discovered several more players in the space than we were previously aware of, and studied their marketing targets.

I mapped the offline landscape for shared understanding. While the team knew about two of the competitors already, I discovered several more players in the space, and Sai and I tried to use the current products. Their marketing aimed at specific segments added another point of reference for our hypothesis for our own target audience. The details also gave me important context when putting together the interview guide.

a dive into Analytics data

I found that most current Razorpay mobile users had average transactions less than ₹5,000, which was great news for us because government regulation only allowed transactions upto that amount when using tap-to-pay without a PIN.

I also got a better sense for how the app was used, which industries currently brought in the highest GMV, and therefore would be good targets for research recruitment.

User Interviews

I interviewed 5 merchants in a local market and observed their payment workflows, and remotely interviewed 5 current Razorpay users who were interested in this solution.

To make sure I covered the landscape with the limited time for interviews, I made sure to include a mix of existing users of Razorpay app and non-users from untapped market segments, including a mix of smaller towns and bigger cities, different geographic regions in India, remote plus field visits to observe workflows in context, business owners and employees, small sellers and luxury businesses etc

‍

Key Insights

After spending a day or two going through the raw interview data, several insights emerged.

1. Owners can’t leave their phones at payment counters, they want to use a separate phone as mobile-POS

1.2 Commission rates for current POS machines are lower than we expected

1.4 Merchants want a single solution covering all payment methods—card, UPI, sometimes cash, across online/offline

1.7 Customers in cities are familiar with tap-to-pay but in smaller towns, there may be apprehension

Some slides from the research report

‍

Definition

While the research wasn’t aimed at rigorous segmentation, these cohorts emerged from the interviews with the most difference in their needs from razorpay’s new solution

the 5 significant cohorts

1. Boutique offline business owners
2. Online business owners
3. Micro/small offline store owners
4. Cashiers at offline businesses
5. Delivery executives

I created some quick personas for these based on the research.

Primary target cohort

We identified existing Razorpay users with hybrid (online+offline) businesses as the primary persona to serve and target for the initial launch.

Because this cohort was the easiest to convert with minimum marketing, and would help validate and test this solution with low-efforts and low-risks, while the rest of the organisation aligned on a formal go-to-market strategy for offline payemnts at large. Following which, other cohorts’ needs could be addressed and targeted.

Workshopping the journey

Once we had our target persona, I conducted a workshop for the team to collaboratively map out the future-state journey. From the persona coming across the new solution, trying it out, and then using it repeatedly. As the team thought throught each step in detail, some gaps emerged:

Key Gaps in the journey

1. The placement of the NFC sensor on phones can be different, which could lead to frustrating initial failures until merchants became familiar.

2. Being a new payment method, merchants will want to try things out before using it with a real customer.

The solution:

An onboarding flow with mock payment

1. a quick way to identify where the phone’s NFC sensor is and point merchants to that area during payments

2. a refundable R1 payment that merchants can try out with their own cards

Based on the potential pain-points in the journey, I created a low-fidelity flow with paper wireframes that addressed the gaps we identified. This included:

‍

Interface

Based on feedback from the team, and after a quick orientation to Razorpay’s in-house design system, I got to crafting the UI, with help from Shubhank, the in-house product designer. Below are some of the key screens.

Onboarding with trial payment

Payment flow

Outcomes

My 8 week engagement came to an end at this point. I handed over to Shubhank, the in-house designer.

With the biggest aspects of the project figured out, the client was ready to carry things forward.

1. Ready to test, launch and learn

Some delays with operations and legal meant that the internal team had a few more weeks before launch which meant they could spend a little time testing the interactions before building them.

While we designed, we had made some assumptions about user behaviour which could benefit from validation. Shubhank was ready to take the design for a round of usability testing, along with Radha from marketing, who wanted to also answer some deeper questions about the target-market.

Questions for next round of testing:

1. Would NFC sensors have a high enough failure rate to justify finding their exact placement with an extra step in onboarding?
2. In the case when the phone’s NFC is off, what would be the quickest flow for turning it on? (This was important to get right because merchants would be using this feature many times a day and every second extra would be frustrating. Research especially pointed to efficiency being of high priority to merchants when adopting payment methods.)

2. Insights from research informed the go-to-market strategy and other teams’ work

The client loved the research report. In addition to clarifying the details of the offline landscape and the current project, it provided them insights for the larger strategy, as well as validation for various things that other teams were working on.

3. A living workspace

The client particularly appreciated the workspace I created, as it evolved in Figjam. So even though I was the product owner whose engagement ended before launch, I left the team with a well-organised documentation of all the hypotheses, insights, decisions, and UX artefacts, to refer to easily as the project progressed.