This was the first project that I took up as an intern at Razorpay. It initially started as a concept/idea that was proposed to the founders as a prospective product that could add value to our merchants and then turned into a full-blown product which went on for 16 months until completion. The product is not available in the App Store and the Play Store.
Duration: 14 months ( until go live date ) Role : Intern > Product Designer > Sr. Product Designer
⍜ The whole process is not revealed in public as it contains some sensitive company-related data.
• Razorpay
Razorpay Payments Solutions, India is one of the fast growing fin-tech startups enables businesses to accept, process, and disburse payments with its product suite since 2015. One of their primary product, the payment gateway allows merchants to accept payments via multiple payment modes. They also have other no banking products like, Razorpay X and Razorpay capital.
• Payments Dashboard
As mentioned payment gateway is one of the primary products of Razorpay. The customers can manage their payment related activities in the Razorpay Dashboard. Using this dashboard the merchant can also collect payments from their customers using other payment products like payment links, payment pages etc.,
• Overview of the problem
The problem was initially identified by a couple of designers in the org when they noticed a surge in mobile traffic on the Razorpay web dashboard. This was reported in Dec 2018. When I joined in June 2019, I was asked to take up this case and find out if the mobile needs of our merchants
• Process & Timeline
• Understanding the Problem
Initially, I spent some time analysing data for the Apr, May, and June months of 2019 to understand that if the spike has any pattern. This resulted in me understanding the organic m-web events were significantly high. Even though it was not as effective as a structured interview, I was able to understand that there is a potential problem to be solved. Then these identified metrics were presented to a larger audience and got approval to continue with broader research to understand in detail the nature of the problem, size of the user base, and their demographics.
• Researching the Needs
Once we had an overall understanding on the existence of a need, we then did an extensive research to understand what are the needs of these users who seek a mobile experience. We wanted to know ideally what could be that minimum viable version of the dashboard that our merchants would want to access on the go. This process went on for three months. We had conducted the research with different stakeholders representing different business sizes in our over all merchant base to get a clear structure. We went on with this until we could see a clear pattern emerging out.
• Analysis and Inferences
From the above-employed methods, we collected a lot of data and then analysed them with other stakeholders involved in the project like PMs, Design Managers, Tech and Marketing folks. This helps us to gather various perspectives on the data. Following are some of the high level inferences we have made with the available data.
On an average first touch point (signup) for 65% of our users happens via mobile devices
Merchants wanted a quicker way to reach out to the customer support.
In SMEs, mostly the founders play all the roles like finance, sales and management so their on the go needs are met via mweb version of the dashboard
Tracking and Capturing their payments is one of the primary usecases of this segment and the do this often in a day to keep themselves updated with their business.
In critical situation like of a payment failures, they reach out to their customers and send out a payment link instead to make sure they pass through.
Delay in settlements causes panic and in such cases merchants wants to be updated on their statuses.
• Design Process
I personally believe that the process of deciding the interventions from Inferences is where the design happens and its an iterative+collaborative process.
Post these data collection I have run a bunch of workshops with the team at different stages of the process here like feature prioritisation and breakdown, framework design, ideation, brainstorming, critique etc. All of these and much more of such workshops are listed here. Check out to get a brief idea about the various methods I followed.
Formulating the Features
From the above-employed methods, we were able to draw out a clear persona of who we wanted to serve with this product. This helped us to create a journey map given their day to day activities, which also revolves around their needs and frustrations.
- Drawing a User persona
- Identifying their Journey and Needs
- Formulating the features.
Documentation
As I have mentioned earlier I joined Razorpay as a grad student intern after my post-graduation. I have written a full-fledged ~300 pages document on the whole process that I followed throughout while building the product.
The document is protected under NDA, I would be open to discuss the process in detail over a call.
☉ MORE FROM RAZORPAY
