There are many useful things in the world, this text isn't one of th
There are many useful things in the world, this text isn't.
There are many useful things in the world, this text isn't one of th
There are many useful things in the world, this text isn't one of them. Infact I would advice you to stop reading it. There's nothing to be found here. Just some placeholder to make the aesthetic shine. Please, stop reading. I am running out of words to type. If you read the next sentence you will get 7 years of bad luck.
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.
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.
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.
As the primary designer and product owner, I was responsible for:
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
And later, experiment with targeting and iterating. The user research and learnings from this experiment could also informing the GTM down the line.
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.
After some stakeholder interviews, to understand what the team already knew, I identified the biggest questions and objectives for initial research.
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.
We identified 4 cohorts that might need a cheaper/simpler way to accept card payments without traditional card machines:
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.
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.
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.
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
After spending a day or two going through the raw interview data, several insights emerged.
Some slides from the research report
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
I created some quick personas for these based on the research.
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.
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:
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:
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.
Entry-point with a callout for first-time users
A quick summary of the new feature, with the biggest reasons to switch (as learned from research)
Test payment flow - Step 1
Step 2 - Identifying NFC sensor location
Step 3a - testing different parts of the mobile device
Step 3b - testing different parts of the mobile device
Step 3c - testing different parts of the mobile device
Step 4 - processing the test payment
Step 1 - Enter amount and check the requirements
Step 1 - loading
Step 2 - tap the card
Step 3 - processing the payment
One of the possible errors
If tap-to-pay does not work, a quick option to still take the payment
If pre-requisites aren't met
My 8 week engagement came to an end at this point. I handed over to Shubhank, the in-house designer.
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:
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.
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.
I have spent 10+ years helping startups and big tech companies, from MVP’s to growth experiments.
If you like this work, there’s good news. I’m always looking for the next interesting product to work on. Shoot me a message to schedule a chat. (I’m not looking for full-time positions)