Neo-banking App: Vendor Payments MVP
Neo-banking App: Vendor Payments MVP

Neo-banking App: Vendor Payments MVP

My Role R&A, Product Strategy, UI/UX Design, GTM
Team 1 PM, 5 Engg.,1 Comm. Designer
Time Period Feb 2020 - March 2020 for MVP

Background and Overview:

When one sets up a business, their purchases shift from B2C → B2B, which can be called Vendor Payments. These payments can be for setting up and running the office, like - office laptops, housekeeping etc. or for the functioning of a business like bulk purchase of raw materials or goods from vendors. They are liable to a different costing bracket and taxes.
In the life-cycle of a vendor payment, there are many pain points in the areas of invoice sourcing, invoice processing, & reconciliation, which leads businesses to adopt multiple software at every stage and takes a lot of investment of time, and effort of finance operations teams.
As the team grows, the number of such transactions and the complexity of maintaining these vendor payments becomes bigger and bigger.
RazorpayX is trying to provide solutions for the payables of a business. Vendor Payments(VP) helps businesses simplify their vendor payments by automating invoice sourcing and processing, taxation and lets businesses seamlessly make payments without switching to another platform.
Various pain points in the Invoice life cycle.
Various pain points in the Invoice life cycle.

🧖🏻 User Personas

We can broadly divide our businesses into three types of users based on the size of the company:
notion image

Design Process

Since this product had many incremental upgrades over a period of 1.5 years, here are a couple of methods applied throughout to get the best output.

👁 Collect Insights:

Try to identify the right problem by talking to users (80%) and the business (20%). Product Managers and Designers co-own this process and build a common understanding of the user as well as the problem space.

🧭  Aligning our team:

Commence the design process with a team huddle in a room or a zoom meeting and hashing out the user flow together.
This helps in
  • Understanding the scope better, and identifying product gaps and edge cases early.
  • Gather & Identify UX requirements
  • Visualising the big picture
  • Look at the system design with respect to the payout layer of the platform and the state machine.
  • Unblock tech early
notion image
notion image

📝  Go Wide and then Go Deep

Document user stories in design specs with Google docs. For smaller projects, document directly on the Figma file, to avoid to-and fro.
This helped in
  • Bring clarity towards the core design problem being solved
  • Ideas captured from different stakeholders were in a single place
  • No room for the discrepancy between design expectations and developer outcome
  • Hash out frameworks for design requirements like notification matrices
  • Keep the user at the centre of the journey at all times
  • Make data-driven decisions, including competitor study

🗣 Early feedback from users & stakeholders

Keep the whole process accessible and collaborative at all stages. We also conducted focus group sessions during the wireframe stages. Feedback could be shared by anyone on Slack or Figma. Deliverables were shared in smaller modules.
This helped in
  • Unblocking Front-end earlier.
  • Digging deep into each part of the experience.
  • Receiving feedback faster.
notion image

💡 Focus group sessions

These allow us to assess the requirements as a team, and address issues of async communication and collaboration

Design Solution: Building Zero-to-One

👁  For the scope of this case study, I will focus on the zero-to-one project, which includes → Uploading and reviewing an invoice, and making it ready for payment → Viewing Vendor Payments from the dashboard. → Open Details and take actions depending on the status, as well as accessing payout details and contact cards. → Expanding base entities to include app meta-information I also worked on discovery, onboarding, platform changes and communication emails which I’ve kept out of scope for this case study. Since 2020, there have been multiple other projects which were built on this base layer.

Design Goals for Vendor Payments :

Flexible: To allow for multiple use-case cases like Editing taxes etc., skipping fund account addition etc.
Coherent with the Platform: Follow existing design patterns for speed of execution and outsource existing functions.
Supports large teams: Allow the information to be communicated async. , Supports bulk actions for larger volumes

Create Invoice

Invoice can be divided into three parts: Invoice Details, Vendor Details and Amount Details. Once all these details are reviewed, we can move to payout creation.
We decided to have a split-screen UI so that users can upload and cross-check details from the invoice. Here are a couple of iterations we tried to work with:
Click to expand
Click to expand

After a whole round of feedbacks, you can have a look at the final Invoice creation flow here:

Feel free to interact with the prototype to see how it works on the dashboard.

Details Views

notion image

Expanding the base-entities

With the help of the engineering team from the Apps and the platform, we were able to build a state machine for Invoice Entity, but also expand the Payouts and the Contacts entity to include meta-information from the app
State Machine
State Machine
With these changes, we also kept the meta information available to users when they interact with the parent entity (for example: looking at the status of the payout created by the invoice) or the child entity (for example approving or rejecting a payout which was created by the Vendor Payment).
notion image
notion image

Navigation to Vendor Payments

Vendor Payments app sat on the action centre along with the other app we had: Payout Links. User can quickly access the list view, or create an invoice from the “+” icon button.
Action centre also served as the place to access all important items such as Due , Overdue Invoices. Clicking on these would apply quick-filters so that user could quickly take an action on these invoices.

Some Design-Driven features we added post MVP

(Bulk Actions) Multi Select and Pay

Sep 2020 : Paying out invoices one-by-one can be a pain when the instructions are same, and you have to add OTP every time. Hence allowing bulk actions, simplifies processing multiple invoices in one go.

(Bulk Actions) Drag and Drop Invoices

October 2022: We observed behaviour on Hotjar where users would add a lot of invoices one-by-one and then do a bulk pay. Adding multiple invoices in one go, lets users just focus on editing these invoices.
This feature was released as a part of a Hackathon, where we won the third price and then went live in a month after testing and PR reviews etc.

🎯 Measuring success and qualitative feedback

Quantitative Data:

From design, the objective has been to increase the usability of the Invoice Creation Flow. For this purpose, we have been tracking: 1. Invoice Creation Funnel to track drop-off areas 2. Feedback form (linked to an excel sheet) after the first invoice creation to understand perceived ease of usage and learnability

Qualitative Data:

Hotjar for viewing user patterns over a period of time & User Feedback Recordings on MarvinApp
Current Success →(March 2022), 500 merchants, out of which 74 merchants were acquired last month. Total no. of RX MTU’s is 1800As of Jan 2022, 9800 invoices were created. 5600 invoices were paid.High success in self-serve, with 30 merchants of 74 new MTU's acquired without SME sales

Challenges and Learnings:

Early feedback is important. We found multiple ways to get feedback through focus group feedback sessions as well as sharing our work with users through Makers Club as well as Early Access Releases. • For a zero-to-one product, designers should be a part of the foundational research, and work closely with the users by building direct access channels as well as documented user sessions. • Collaboration with Tech: → For smoothening product gaps, engineers, product managers and designers should be on the same page. → For building a holistic solution and having buy-in for delight, it is important to include engineers as a part of the product solution phase.

Current State and Future Scope

We have found a PMF with early-stage founders and D2C brands. Vendor Payments is expanding to become its own unit on RazorpayX so that we can target an audience outside of RazorpayX’s general users and build specialised use cases.
We are also building a Vendor Portal to attract Mid-Market segment (Read Case Study here)
We have also upgraded our Invoice Creation flow for better usability as well as capturing the audience which would like to move easily between Payouts and Vendor Payments.
notion image