Time: 1 month of Research (July 2019) 1 month of Design (October 2019) 1 month of Execution (February 2020)
Role Design Driven Project Research, Prioritization & Execution
A Neobank is a bank which operates entirely online and has no physical branches. It provides an umbrella of financial services but with tech-first approach. However, neobanks don't hold banking licenses by themselves, and rely on bank partner to provide bank licensed services like money transfers. Neobanks can provide better customer experience to users as they are not bogged down by legacy systems of the bank.
RazorpayX is also a neobank which caters to SME's and tech-first businesses. It intends to provide business oriented financial services like bulk and API based payouts, Vendor Payments, Tax Payments, Payroll and Complaince etc.
The money movement from a debit account to a beneficiary account is called a transaction. Payouts are transactions which are initiated by the neobank. Once the beneficiary account receives the money, the payout is processed and an entry is added to the account statement.
In essence, payouts form the banking layer of the neobank, and is called the platform. All the financial services which a neobank intends to provide will all be done on top of the banking layer through apps. Hence, the payout creation experience is essential to the user experience on RazorpayX.
As of October 2019, we were offering instantaneous money transfer through IMPS /RTGS / NEFT and UPI.
We conducted a persona analysis on who are our users and found that there were primarily four types of users.
Dashboard users creating vanilla payouts. - 10-20 payouts / month. - Startup founders, who have just started their business. - Early adopters looking for alternatives to banks. - Outsourced accountants help them with the finance processes, and payment calculations and the founders make the payouts - Personally look into all banking transactions; as their business grows, they will soon be expand and add collaborators such as the finance team. -Value the user experience.
API based business - 100-200 payouts / week. - Large businesses who have payments as a part of their business model. - Rarely use Razorpay Dashboard once the integration is done. - Large finance teams who help reconcillation. - Value instantaneous money transfer, and tech finesse.
Dashboard users creating bulk payouts. - 10-20 payouts / week. - SME's and small businesses. - Use multiple finance tools along with RazorpayX. - Tech-aware. - In-house finance teams, who makes all the calculations and create bulk payments. - Have individualized responsibilities divided within the team. - Use of maker checker model. - Can create multiple vanilla payments in a small time. - Value easy team management and bulk processes.
FUTURE: App Users - Each App will target different business use-cases which create payouts as a part of their process
As a general rule of thumb, we explicitly focused towards dashboard users 1 & 2 mentioned above. Goal was to enable vanilla payout users to become power users. For cohort 4, we tried to make the core payout creation super compact as well as thorough enough, so as to not require rebuilding features.
When we first built RazorpayX in Jan 2019, we had a very simplistic understanding of payouts. However, by October 2019, this understanding had evolved, we could no longer add more features in the existing flow, without breaking something else.
We also started looking at issues which were raised from
- usability testing (Think Aloud Exercise) and user observations (Hotjar Videos),
- internal tech limitations, and
- complexities in the user flow which came after adding another partner bank.
Usability Issues with current layout: 1. Lot of information makes it look complex 2. Fund account not shown on the summary page 3. Fintech terms may not be understandable for a lot of people 4. Space constraints, the modal is on scroll 5. No one can view the entire payout form in a single glance. 6. Optimise for: Contact Creation while creating payouts 7 Mobile Responsiveness 8. Progressive Disclosure makes everything seems looong
Change of context: The new set of use cases which weren't there in the original design : 1. Choosing a debit account 2. Fund Account availability based on Debit Account 3. Queueing of payouts based on Account Balance 4. Narration of the payout 5. Payout processing time based on Payout method 6. Approval of payouts 7. Scheduling of payouts
Thinking about Apps: 1. Lot of new apps would require long forms, like Payout Link, Vendor Payments. These new flows shouldn't feel very different from each other. 2. Allow invoking payouts from multiple sources, without having experience breaks or making the journey too long.
We took up this exercise in four phases.
Brainstorming Exercise: For exploring what are user expectations of the current layout, we conducted a brainstorming activity with designers. Designers were given an hour to understand the usability issues and start brainstorming on what possible layouts can be explored.
Outcomes of the exercise: From that exercise, a couple of patterns emerged:
- The summary should be available at all times
- One should be able to move back and forth between steps to correct them
- Even though, one would want to see the summary of the entire action, we could still use progressive disclosure while creating the form.
Iteration Round 1: After the brainstorming, we started detailed iteration on the layouts. RX Design and a few designers from Merchant Dashboard got into a room, to pick a layout which we should go ahead and detail out.
- Types of approaches:
- Single page constructs, and different layouts for the long form.
- We tried modals, with different layout for the steps
- Build summaries in a separate group
- Bring the entire existing modal to a full page.
- Try a mobile-first layout and then build it for desktop
- We also tried a popover for creating payouts
- Outcome of the discussion:
- We still needed to reduce information inside each step,
- Use defaults everywhere
- Use a linear layout
- Still need progressive disclosure
Iteration Round 2: From the previous set of iterations, we picked one approach on the long form and detailed it out for all use cases. After this, we opened this discussion to all designers, where they were allowed to point hierarchy flaws .
- Outcomes of the discussion
- Overall positive outcome, with small Hierarchy issues
- We decided to stick to the modals, as they allowed maintaining context to the page of creation and the approach of having a single page didn’t maintain context, it made users feel they were going somewhere else.
Visual Refinement and Prototype Testing
• At this stage we added some visual refinements to the spacing and icons. Worked on microtransitions.
The redesign caters for both the usability issues as well as the user expectations of a long form.
- Less number of errors while creating a payout. Less back and forth between steps.
- Ease of understanding for new users and its perceived simplicity.
- Ease of adapting the layout for future cases
These metrics were tracked with GA and Hotjar, and also controlled release to a percentage of the users at all times. We also kept a lookout on Support tickets around Payout Creation.
- The mobile version was deferred for the mobile app to be released.
- New actions such as Payout link creation will also be done on a similar long form.
- Post inputs and approval for the approach, we will migrate the Contact creation on the long form.
- We may have cases where smaller components need to be updated when a new debit account or a payment mode appears.
We could also reuse this similar layout for more elements like "Payout Links", "Contact Creation", "Tax Payments", "Vendor Payments".
- This was a design driven project which took about four months, before it got picked, as the product team had already allocated bandwidth on high priority projects associated with OKR's for the quarter.
- In the meanwhile, I moved to the apps team, and had to hand over the project for implementation to the platform, which was taken up by my colleague, Pingal Kakati.
- Couple of UI improvements happened after handover, as design system had updated a few elements from when it was first designed.
- In order to get this prioritized, I had to be very persistent, even after I moved teams. The key here was keep the conversation ongoing, and highlight during Apollos (monthly product reviews) and product discussions, how the new designed solution can help our prevalent issues.