Work Journey Contact
Abstract
This was the first project that I took up at Razorpay. It initially started as a concept that was proposed to the org leaders as a prospective approach to enhance our merchant's experience and then turned into a full-blown product that went on for 16 months until completion. The product is now available in the App Store and the Play Store. This is a short writeup of the product journey.
About Razorpay dashboard
Razorpay Payments Solutions, a fin-tech startup that 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. The customers can manage their payment-related activities in the Razorpay Dashboard.
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 picked this from there to identify the needs of our merchants using mobile devices to access the dashboard.
Process & Timeline
Understanding the Problem
Initially, I spent some time analyzing data from google analytics and hotjar of the previous months to understand that if the spike has any pattern. I have also cold-called up a bunch of users to roughly validate the noted problems and opportunities.
Researching the Needs
We presented the outcomes of our quick study and got an initial sign-off from the product team, then we spent a whole quarter doing extensive user research with our users. Initially started off with a survey on the dashboard asking for consent and then conducted a structured interview with users who responded.
Analysis and Inferences
The research was conducted with one aim to find out whats is that we have to build on mobile which is minimal and viable enough for our merchants to solve their on-the-go needs. We analyzed the data collected with other stakeholders involved in the project like PMs, Design Managers etc.,
Key Inferences
On average first touchpoint (signup) for 65% of our users happens via mobile devices
Tracking and Capturing their payments is one of the primary use cases of this segment and they do this often to keep themselves updated with their business.
Merchants wanted a quicker way to reach out to customer support.
In critical situations like payment failures, they reach out to their customers and send out a payment link instead to make sure they pass through.
In SMEs, mostly the founders play all the roles like finance, sales, and management so their on-the-go needs are met via an m-web version of the dashboard
Delay in settlements causes panic and in such cases, merchants want to be updated on their statuses.
Design Process
// I personally believe that the process of defining the interventions from inferences is where design happens and it's an iterative + collaborative process.
Post the data collection and analysis I have run a bunch of workshops with the team at different stages to finalizing on feature prioritization and breakdown, framework design, initial ideation, brainstorming, critique, etc. All of these and much more of such workshops are listed in the following article. Check out to get a brief idea about the various methods I have followed.
Collaborative Design Practices →
User Journey
This is a very high-level overview of the user journey that covers most of the use cases of the identified personas.
Solutions and Testing
The problems identified are then converted into features, we conducted a bunch of exercises to decide on the framework and draw user flow and architecture of the whole application. Post that we started iterating on the layout and navigation of the application.
During this phase, we often went back to our internal design and collaborated with them by conducting workshops, brainstorming, and critique sessions. After validating internally we were able to come up with two final iterations. We created some high fidelity prototypes and tested with our users
There were equal pros and cons in either of the approaches. We documented all of them and this gave us a chance to understand them better. The following image contains some of the feedback given on the home screen of the prototypes tested.
Visual Designs
The visual language of the app has already starting to shape out as you can observe through the iterations. But to harness the potential and direct them towards one goal, we went on to create a mood board with the team that expresses the central theme of keeping it light.
Light Scalable Intuitive Accessible Unconventional
Design System and Illustrations
The mobile application was the first product in the organization which had built a full-fledged design system. The design system team worked closely with us and understood the use cases of each and every token and component and build them ground up alongside. This team is comprised of some talented designers from the org. The illustration library was also created alongside Rahul Chandh adopting some principles from the mood board we generated.
Final Designs
Home Screen
The home screen is the primary screen of the application that gives an overview of what is happening with the user’s business. This screen highlights the settlement balance in their Razorpay account on top, an analytics card to give a graphical summary of payment in the last 7 days, a list view bottom sheet, and a floating new payment link button.
Payment Link Creation
The user can create a payment link by tapping on the floating button on the home screen. The user can quickly add just the amount to be collected and send out a payment link or if they wish they can also add other additional details like reference number, expiry date, and internal notes before sending it. Once the user adds the needed details he can send it out by filling out the customer details. In the final screen he also has additional options to share it via other applications.
List and Detailed view
List view gives a way for the merchant to review their payments, settlements, and payment links. Tapping on any of the field elements in the list view will lead the user to the detailed view of that particular entry. The header of the detailed view screens is color-coded to reflect the status of that field entry.
Payment Analytics
The analytics summary card in the home screen expands into full-screen analytics with additional options to change the duration. It also shows the users about the trends compared to the previous month/week. Here the user can also select custom date ranges to see the graph of payments in that selected time frame. The user can also then check the payment list of any particular day by clicking on that day’s graph bar.
Notifications
These are in-app notifications to notify the user of any change or update that occurred with any payment or payment links or settlements while they are using the application.
To conclude
This product is live right now in both App store and Play store. The benefits of spending time to understand the users were clearly reflected in the product performance. After the release of the product, it reached 20,000 downloads with 3000 daily active users within a month. Also generated a revenue of around USD 1.6m from the payment links alone. We are currently working on onboarding and designing scaling principles of the application.
Documentation
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.
