Building a Neo-banking Platform  0️⃣→1️⃣
Building a Neo-banking Platform  0️⃣→1️⃣

Building a Neo-banking Platform 0️⃣→1️⃣

TIME: 1. Building the base: December 2018 2. Adding Enhancements: Jan - Jun 2019
Stakeholders: 2 PM's, 1 PMM, 3 Designers, 2 FE , 4 BE, 1 QA
Role: Product Thinking, User Research, Design Exploration and Implementation

Understanding the problem: Origins

October 2018:
Even though the world of tech and moved ahead by leaps and bounds, our banking experiences are terrible, primarily because it rests on legacy systems, conservative stakeholders and not enough tech experts to lead this front. This buggy experience is even more amplified when you have to perform a lot of banking operations as a business. The friction to bank is too high with the multiple layers of security, and doesn't look at banking as a product but a service.
Razorpay wanted to solve this.
Razorpay had realized that merchants consistently looked for solutions that will allow them to disburse money with ease, just as they could accept money for their business via various methods.
To be the "One stop Financial Hub for Businesses", Razorpay needed to provide solutions in not just payout disbursal, but also finance management and making sure business always have working captial. Welcome to the vision of building a neo-bank , RazorpayX!
But what exactly is a neo-bank? A Neo-bank is a bank with no physical branches.
🧗 The catch here is that in India, you need a banking license to operate, which can take a long time and hence we partner with a bank to carry out any banking functions like transaction.
notion image
In this project, I want to talk about the early days of RazorpayX when we were figuring out what to build, some project planning techniques that helped us build an MVP in 45 days of WarRoom, as well as showcase some interactions we created, in an attempt to break the mould.

What was the MVP?

In the first phase of the neobank, we were primarily looking to solve for the following problems:
Provide API banking to users who want to automate their payout disbursal, specially in businesses where money to the end customer is part of the business plan as in industries like Gaming (Rewards) , Lending.
Replace the current account experience by creating a banking layer on top of banks. It should include opening an account, contact creation and disbursal of payouts. Eventually, we will also add bulk creation of contacts and payouts, followed by applications.
We decided to build a platform that allows users to:
  1. 📝 Sign Up and fill KYC (Compliance)
  1. 💰Load Money into a Virtual Account
  1. 👯‍♀️ Create a Contact
  1. 💸 Send Payout
  1. 🤖 Integrate with API


Why was a new platform required?
Since the function of this product and the market was entirely different from any of Razorpay's existing products, we needed to build a separate platform. Also, a neo-bank is change of behavior in the way businesses will approach banking, and hence the product could not sit and merge with something users are used to.
Why did we want to build this in a month? Why didn't we want to spend more time on it?
We wanted to test out an idea with an audience. We wanted that idea to be as close as possible with reality, but since we were talking about behaviour change with money movement, we couldn't have assessed the true potential with a prototype. Razorpay also tap on the first mover advantage. Going into a war room is also Razorpay's way of getting things done in high-intertia.
What do I mean by Working in War-Mode?
  • War room is like going into a month long Hackathon to solve a problem. The small team worked over 14 hours a day to solve a problem.
  • In the one month, we also looked into different ways we could propel faster. Design and Tech worked in parallel, so we needed to decide the scope to enable tech faster.
  • We had an advantage of being in Razorpay, that we weren't resource constrained, we had data and we had access to finance teams. After launch, we didn't have to start from scratch since Razorpay is a trusted brand among merchants.
How did we know that we should build this without proper validation?
While we didn't have a lot of time to do a proper validation of the idea, we started conversations with our finance team at Razorpay and merchants who had shown interest in the past to such a venture. Post creation of Beta, we asked users to sign up on early access to test out the platform.

Why was this a wicked problem?

Design Challenge #1 : What does RazorpayX look like?

Since RazorpayX wanted to make waves with the experience it provided for banking experience, the UI should not look like another standard SaaS platform. We stuck with three Design Tenets for Visuals:
Dark theme
This also meant we needed to reimagine the theme and user interactions for RazorpayX from scratch. We also took this opportunity to discard everything which was difficult to fix on existing dashboard and move forward with only things that could be repurposed without changing the interaction pattern.

Design Challenge #2: Banks!

Since RazorpayX was still building a banking platform it had build for trust within its platform. This also meant that reinventing some interactions which didn't make users feel comfortable or add cognitive load, could lead to a loss of adoption.
For example: Entering bank account number twice when it is copied from a source. OR asking for OTP for every transaction, which can be a pain with repeat actions.
We were cautious while taking some decisions, and decided to keep them and remove them only after validating that users are okay without them.

Design Challenge #3: Databases!

Despite all our efforts to not look like "JUST ANOTHER SAAS TOOL", we were still looking into a lot of data and databases eventually meant looking at rows and rows of data and numbers.
What we could optimise here for:
Increase readability: Show what's most important first, and remove non-essentials.
Remove complexity : Keep a non-finance person in mind.
Make data easy to find: Bring to notice what needs to be acted upon.


Since we had very little time to get to the main design, we wanted to reduce as much time as we could while planning projects. Here are couple of things that helped us.

Design War-Room:

We ditched a Sprint and went into a month long Marathon without any meetings apart from the Standup.. We started by dividing owners for different areas on the basis of effort, priority and complexity, and we tracked it via an excel sheet everyday. At standup, we updated the progress of this sheet. We also worked in a war-room together, with a whiteboard nearby to get on discussions, and have each other in close proximity to close tasks faster.

Crisp Design Specs:

We kept our Design Specs to small sections with the focus towards the problem statement, and considerations. This let us concentrate more on the interactions, and less on the edge cases. These design specs couldn't capture all approaches for saving time, but tried to capture all the major decisions we took and why.
A snippet of the design specs used in these cases
A snippet of the design specs used in these cases

Unblocking Engineers:

With the problem statement in hand, we needed the maximum time we could to explore design solutions, but at the same time, we would've bottle necked the whole work flow, if we even waited till wire-framing level to get engineers involved. So we started with writing all the attributes the user would need to identify a particular entity ( A payout, a transaction, a contact) . We also included the actions user could take and the properties which the user would require to be searchable. This not only built a common understanding of the entities but also let back-end move forward in more time-consuming tasks.
notion image

User Understanding:

We didn't have much information about what do businesses look for while working with banks, so we took 30 minute sessions with the finance team in getting acquainted with the finance terms and what pain-points do they deal with while working with banks. This gave us the idea on which information pieces we bring higher up in the hierarchy, and the next set of action-ables to work on right after the MVP launch.

Design System Foundations

While it was not perfect, we tried to maintain as much consistency as possible while using components from Design and Engineering. We used an excel sheet to keep track of our tokens as well as a common design library, where we made note of all the components were used, and avoided variants as much as possible. Even though the eventual scaled design system needed a lot more depth, this whole exercise reduced effort while experimenting with themes in the initial phase as well as lead to a base for a formal design system to grow.
Origins of our Design System
Origins of our Design System

Iterate 💡, Build 🔧and Validate ✅ (WIP):

Dashboard Evolution

  • Instead of opening the dashboard with graphs, we decided to make the two most important numbers prominent: Account Balance and the recent Payout amount
  • The right most section gives way to all relevant actions like creating a new payout or contact as well as informs you of any platform updates
  • The widget in the bottom gives a snapshot of the Account Statement, so that the user know what updates were done while they were away.
notion image
We decided to not have a dedicated space for Navigation and provide entry to different points of the platform through our Action Center and widgets. It would also feel like a differentiator from other SaaS apps. This however on the hindsight was not the best idea, as without dedicated navigation, it has got us scaling challenges as we now have more apps.
We used cards instead of full list pages to contextually open relevant information. We could have avoided doing this mistake, had we had better understanding of how things would scale 1 year down the line.
notion image
Look at some of the iterations we explored for homepage below:

List and Details Views

We didn't have much to work with when we started out on List Views, except that we didn't want the database to look overwhelming. So we decided to let typography come to our advantage. We gave the information that required the maximum focus, the highest hierarchy. We also grouped this database by time to make search easier.
Onto detail views, whatever wasn't the primary information was put under progressive disclosure. We didn't want to redirect to another page and opted in for a drawer instead, so that user could jump from one item to other with ease, preferably with a tap of a keyboard button (for power users). Interconnected information was shared with a card on card interaction as seen in the video below.

Payout Creation & Contact Creation

In the interest of time, we kept the Payout creation flow straightforward and easy to build, since we didn't know what kind of use-cases would come. We decided to keep it on modal so that we can invoke the flow from anywhere. Initially, this flow worked well but started to break when we started getting complexities like various payment methods not being available on a bank as well as handling flows like "Creating new contact from payout" or "Sending payout link when a fund account is not available".
Also read: Case study on Payout Creation flow re-design

Micro-interactions I worked on:

With a zero-to-one, we also had the chance to explore multiple interaerctions from scratch, sharing a few here

Quick Filters

The idea of quick-filters here was also to provide summary of the items under the selection, and on selection, it could quickly select a single filter or a combination of commonly used filters.
notion image

Test Mode Interaction

Make user hyper-aware that they are in test mode, as well as allow easy switch to live mode.

Export Data Interaction

• Instead of having a dedicated page to download reports, we wanted to make reports contextual, so that user could apply filters, see results and then download information.
• Since report generation could take time and we could have external stakeholders , we also provided for sharing reports via email.
• In order to give the feeling of an async process, the popover for the report floats over the list page, so that the user can navigate to other parts of the dashboard.
• We eventually wanted to solve for async download of reports as well, however due to bandwidth issues, that was deprioritised.
Implemented Export Data Interaction

Search Interaction:

notion image
We wanted to stir away from multiple input boxes for each attribute because of the clutter and confusion they add. Hence, we decided to build some intelligence into our search by combining the search component and automatically identifying the attribute on the basis of the search term.
Updated (2021) (In Progress):
A smaller search component which automatically searches across multiple attributes. Users can further refine results basis the search category.
Minimal Search Input Box


  • SaaS tools should be built for scale, our first task after release was building bulk actions everywhere.
  • Optimising for first time user experience is worth the effort. If your product cannot explain itself, its not simple enough to scale big.
  • Do not reinvent interactions without looking at the scope of the next 6 months and testing with actual users in real-world environment
  • 🎰 Behavioural change requires big-bets on experience
  • One does not simply achieve PMF in the first release.
  • Know thy user: Even a 15 minute conversation with the right person can propel you by leaps and bounds in the right direction.
  • Test on actual user devices: When we set out to create a new "design", we forgot to put focus on some of the basics like resolution in different devices. Most finance users are on Windows, while we designed and viewed and tested everything on Mac first, which was a big mistake, and caused inconvenience to our Windows users, as they could only see 3-5 rows of actual information . Once the layouts are set, it can be very difficult to redo the layouts, and it can take a long time to come back to redesign.
  • 🧩 Modular Design >>>

Gauging Design Success

  1. Since we didn't have a lot of time to do user testing, we wanted to know the intuitiveness and perceived complexity
  1. Did the UI theme match the design tenets we designed them with: of being futuristic, cutting edge and easy to use.

Future Scope

  1. After building MVP, we got into making our dashboard ready for early access users, which would let us understand the first set of users who would find value in the MVP of RazorpayX.
  1. We also started conducting more user calls to understand the various personas using our MVP and how can we target and build for them better. We also conducted usability tests with these users to understand what is working and what isn't
  1. Once we got inputs on our usability, we started working on a couple of design driven projects that could help make things simpler. For example: Optimising List Views for Bulk Actions, Payout Creation Redesign.
  1. We also formed the base of our Design System with RazorpayX , which is now a full-fledged design system called "Blade".
  1. As of today (June 2021) we can now open multiple current accounts in RazorpayX as well as have 3 apps (out of which 2 were designed by me: Vendor Payments & Tax Payments)
🙌 Special thanks to my colleagues Pingal, Soni and Chandru from Design, and everyone from engineering and product.