My Role
Product Designer
Services
Dashboard Design
Timeline
6 weeks
Scope
Research, Design & Usability Testing
The transaction of money always require careful reconciliation. The self serve reporting & scheduling is designed to increase visibility of transactions for users. Giving them more control of their transaction data and reconciliation. Through this project users can download different types of reports at any time, present or past and set up schedules for the future ensuring all-time access without dependency.
Problem Statement
Problem Statement
Problem Statement
Merchants using the Razorpay dashboard frequently downloaded transaction reports—some daily, others multiple times a day—for reconciliation. Larger firms relied on Razorpay’s engineering team to manually create report schedules, but modifying these schedules required merchants to go through a lengthy approval process.
There was a clear need for a self-serve solution that allowed merchants to automate report deliveries via email, SFTP, or S3 without depending on customer support.
High demand: Report schedule requests grew 90% YoY, from 362 in 2020 to 658 in 2021, with 65 new requests per month in 2022 (as of May).
Slow turnaround: Any change in schedules required merchant support intervention, with an end-to-end TAT of up to 5-7 days.
Poor visibility: Merchants had no way to view or manage existing schedules on the dashboard.
This created friction, delays, and a frustrating experience, making automation and self-service essential.
Merchants using the Razorpay dashboard frequently downloaded transaction reports—some daily, others multiple times a day—for reconciliation. Larger firms relied on Razorpay’s engineering team to manually create report schedules, but modifying these schedules required merchants to go through a lengthy approval process.
There was a clear need for a self-serve solution that allowed merchants to automate report deliveries via email, SFTP, or S3 without depending on customer support.
High demand: Report schedule requests grew 90% YoY, from 362 in 2020 to 658 in 2021, with 65 new requests per month in 2022 (as of May).
Slow turnaround: Any change in schedules required merchant support intervention, with an end-to-end TAT of up to 5-7 days.
Poor visibility: Merchants had no way to view or manage existing schedules on the dashboard.
This created friction, delays, and a frustrating experience, making automation and self-service essential.
Understanding Users
Understanding Users
Understanding Users
User Segment
User Segment
Traits
Traits
User Needs
User Needs
Small Market Enterprises
Small Market Enterprises
Generally managed by 1-3 people
Founder most of the time manages the transactions
Need reconciliation less frequently, once a year or month
Generally managed by 1-3 people
Founder most of the time manages the transactions
Need reconciliation less frequently, once a year or month
Downloading capability is enough for them in their opinion
Downloading capability is enough for them in their opinion
Mid-Market Enterprises
Mid-Market Enterprises
Mostly have business ops team to manage reconciliation
Reconciliation happens everyday three times, 11 am, 2pm, 4pm or 6 pm. Some only do at 12pm once a day. And some once a year
Mostly have business ops team to manage reconciliation
Reconciliation happens everyday three times, 11 am, 2pm, 4pm or 6 pm. Some only do at 12pm once a day. And some once a year
Needed scheduling and in some cases hourly
Needed scheduling and in some cases hourly
Large scale Enterprises
Large scale Enterprises
Business ops team manages this
Have more than 100 Merchant-IDs on Razorpay
Large scale reconciliation happen.
Business ops team manages this
Have more than 100 Merchant-IDs on Razorpay
Large scale reconciliation happen.
Needed scheduling
Needed scheduling
If we try to understand Razorpay's user base and their contribution to business, the presentation would look like these triangles.
Razorpay had a large base of Small businesses, followed by Mid-Size businesses and lastly least in number enterprise business. While the contribution to business is inverted.
Keeping this in mind, we can concur that it was important for Razorpay to have schedules for enterprise's requirement and we need to have easy user experience for large based (majority) SME users.
If we try to understand Razorpay's user base and their contribution to business, the presentation would look like these triangles.
Razorpay had a large base of Small businesses, followed by Mid-Size businesses and lastly least in number enterprise business. While the contribution to business is inverted.
Keeping this in mind, we can concur that it was important for Razorpay to have schedules for enterprise's requirement and we need to have easy user experience for large based (majority) SME users.
Defining Information Architecture
Defining Information Architecture
Defining Information Architecture
The old information architecture:
The old information architecture:
The old information architecture:
The old information architecture had history and capability to download report in a single view, making it a long scroll. Also it left no scope to add more capabilities in the view.
The old information architecture had history and capability to download report in a single view, making it a long scroll. Also it left no scope to add more capabilities in the view.
The new information architecture:
The new information architecture:
The new information architecture:
With expansion of reporting as a product, we needed a more flexible dashboard with clearer sections. Current dashboard had a single view ‘Reports’ which was divided in two parts: new download, and previously downloaded.
In the new setup, we needed to introduce new schedules and running schedules. We decided to divide sections to avoid long scroll and overwhelm.
With expansion of reporting as a product, we needed a more flexible dashboard with clearer sections. Current dashboard had a single view ‘Reports’ which was divided in two parts: new download, and previously downloaded.
In the new setup, we needed to introduce new schedules and running schedules. We decided to divide sections to avoid long scroll and overwhelm.
The new setup has
The new setup has
The new setup has
Overview section to introduce reports to SME merchants and to not overwhelm with long list of input fields
Overview section to introduce reports to SME merchants and to not overwhelm with long list of input fields
Overview section to introduce reports to SME merchants and to not overwhelm with long list of input fields
Product list and filters, to prevent users in getting distracted from other products which they don’t use
Product list and filters, to prevent users in getting distracted from other products which they don’t use
Product list and filters, to prevent users in getting distracted from other products which they don’t use
CTA for each product to create schedule or download report
CTA for each product to create schedule or download report
CTA for each product to create schedule or download report
UI Design & Decisions
UI Design & Decisions
UI Design & Decisions
1. Introduction of overview, schedules & download tabs
1. Introduction of overview, schedules & download tabs
Need of overview tab
Need of overview tab
Need of overview tab
Validated importance of self-serve reports & reconciliation.
Validated importance of self-serve reports & reconciliation.
Validated importance of self-serve reports & reconciliation.
Decided to optimize capability for our SME audience (the majority of users).
Decided to optimize capability for our SME audience (the majority of users).
Decided to optimize capability for our SME audience (the majority of users).
Recognized that SMEs typically have 2-3 people or owners handling dashboards and don't have finance team behind.
Recognized that SMEs typically have 2-3 people or owners handling dashboards and don't have finance team behind.
Recognized that SMEs typically have 2-3 people or owners handling dashboards and don't have finance team behind.
Did not want to overwhelm less tech-savvy SME users with complex, heavy tables or too many fields at the first touchpoint.
Did not want to overwhelm less tech-savvy SME users with complex, heavy tables or too many fields at the first touchpoint.
Did not want to overwhelm less tech-savvy SME users with complex, heavy tables or too many fields at the first touchpoint.
Simplified experience with an overview section and a smaller list of items, fitting SME use-case, as they typically use a smaller suite of products.
Simplified experience with an overview section and a smaller list of items, fitting SME use-case, as they typically use a smaller suite of products.
Simplified experience with an overview section and a smaller list of items, fitting SME use-case, as they typically use a smaller suite of products.
Need of schedule and download tab:
Need of schedule and download tab:
Need of schedule and download tab:
Dashboard having different use cases for self serve and one time downloaded reports, hence segragation made sense.
Dashboard having different use cases for self serve and one time downloaded reports, hence segragation made sense.
Dashboard having different use cases for self serve and one time downloaded reports, hence segragation made sense.
In scheduled reports, users need to know the status (active/inactive) and require capabilities like edit or delete.
In scheduled reports, users need to know the status (active/inactive) and require capabilities like edit or delete.
In scheduled reports, users need to know the status (active/inactive) and require capabilities like edit or delete.
In manual downloads, status focuses on success/pending/failed, with no need for edit/delete, but instead a history of downloaded reports.
In manual downloads, status focuses on success/pending/failed, with no need for edit/delete, but instead a history of downloaded reports.
In manual downloads, status focuses on success/pending/failed, with no need for edit/delete, but instead a history of downloaded reports.
Designing Entry Point
Designing Entry Point
Entry Point 01: Create Schedule
The introduction banner with the CTA to create a schedule or watch a helpful video.
Entry Point 01: Create Schedule
The introduction banner with the CTA to create a schedule or watch a helpful video.
Entry Point 01: Create Schedule
The introduction banner with the CTA to create a schedule or watch a helpful video.
Entry Point 02: Create Schedule
User can choose any product and click on “create schedule” button.
Entry Point 02: Create Schedule
User can choose any product and click on “create schedule” button.
Entry Point 02: Create Schedule
User can choose any product and click on “create schedule” button.
Entry Point 03: Create Schedule
Users can also create a schedule from “schedules tab” while exploring the need of it with other schedules
Entry Point 03: Create Schedule
Users can also create a schedule from “schedules tab” while exploring the need of it with other schedules
Optimising Form Structure
Optimising Form Structure
The new information architecture:
The new information architecture:
The new information architecture:
Modal experience was chosen for a schedule creation journey.
Reason behind this UX decision:
Schedule creation/edit is a one-time/rare action user needed to perform.
This action required an undivided attention & un-interrupted experience from the user.
Being a multi-step journey, following a no-modal approach would have led to multiple page navigations within dashboard.
Modal experience was chosen for a schedule creation journey.
Reason behind this UX decision:
Schedule creation/edit is a one-time/rare action user needed to perform.
This action required an undivided attention & un-interrupted experience from the user.
Being a multi-step journey, following a no-modal approach would have led to multiple page navigations within dashboard.
UI Iterations
UI Iterations
UI Iterations
V1
V1
V1
Created a cleaner version of the original approach.
Designed a flowing layout to reduce excessive eye movement, ensuring users find information intuitively.
User Testing:
Observed users filling fields in various orders, leading to confusion.
Custom sections required users to perform actions in a specific sequence.
Created a cleaner version of the original approach.
Designed a flowing layout to reduce excessive eye movement, ensuring users find information intuitively.
User Testing:
Observed users filling fields in various orders, leading to confusion.
Custom sections required users to perform actions in a specific sequence.
V2
V2
V2
Designed with progressive content delivery to avoid overwhelming users with information all at once.
Adopted a sequential approach to guide users clearly on which fields to fill first.
User Testing Insights:
Despite sequential content, users still filled fields randomly due to visibility of all fields at once.
Designed with progressive content delivery to avoid overwhelming users with information all at once.
Adopted a sequential approach to guide users clearly on which fields to fill first.
User Testing Insights:
Despite sequential content, users still filled fields randomly due to visibility of all fields at once.
V3-Final
V3-Final
V3-Final
Based on user testing feedback, we identified two key insights:
Users needed guidance on the order of filling details, as some fields depended on others.
Custom sections weren't relevant for all users, so they should be optional and accessible only when needed.
Our refined approach divided the form into three clear sections: What (report details), When (report schedule), and Who (report recipients).
Implemented a sequential flow, requiring users to fill details in the given section order, ensuring clarity and simplicity.
Based on user testing feedback, we identified two key insights:
Users needed guidance on the order of filling details, as some fields depended on others.
Custom sections weren't relevant for all users, so they should be optional and accessible only when needed.
Our refined approach divided the form into three clear sections: What (report details), When (report schedule), and Who (report recipients).
Implemented a sequential flow, requiring users to fill details in the given section order, ensuring clarity and simplicity.
Outcome: We tested iteration 03 with our internal users, account managers and this faired well with them. Hence we decided to go ahead with this.
Outcome: We tested iteration 03 with our internal users, account managers and this faired well with them. Hence we decided to go ahead with this.
Usability Testing & Outcomes
Usability Testing & Outcomes
🔍 UT CohoRt & Setup
🔍 UT CohoRt & Setup
🔍 UT CohoRt & Setup
We tested with three major user personas:
Ops teams from our merchants
KAMs (Key Account Managers) who manage enterprises and understand reporting struggles
Merchants who don’t use reporting functionality at all
A functioning prototype was created, and users were given specific tasks. We observed their actions, struggles, and feedback to refine the design.
We tested with three major user personas:
Ops teams from our merchants
KAMs (Key Account Managers) who manage enterprises and understand reporting struggles
Merchants who don’t use reporting functionality at all
A functioning prototype was created, and users were given specific tasks. We observed their actions, struggles, and feedback to refine the design.
✅ What went well
✅ What went well
✅ What went well
UI revamp was well-received, with clear and understandable elements.
Report scheduling feature & its placement were appreciated.
Terminologies & copy were intuitive, despite no dedicated copywriter (handled by me).
New scheduling capabilities (pause, edit, delete, history, re-download, recipient controls) were a major improvement since previous schedules ran entirely in the backend with no user control.
Business validation: My hunch that users rarely need reports for random days (e.g., 12 or 17 days) was initially dismissed by stakeholders. However, user testing validated my assumption, proving that such cases are rare, and users would manually download reports instead.
UI revamp was well-received, with clear and understandable elements.
Report scheduling feature & its placement were appreciated.
Terminologies & copy were intuitive, despite no dedicated copywriter (handled by me).
New scheduling capabilities (pause, edit, delete, history, re-download, recipient controls) were a major improvement since previous schedules ran entirely in the backend with no user control.
Business validation: My hunch that users rarely need reports for random days (e.g., 12 or 17 days) was initially dismissed by stakeholders. However, user testing validated my assumption, proving that such cases are rare, and users would manually download reports instead.
Lesson learned: Choosing which battles to fight in design discussions is crucial.
Lesson learned: Choosing which battles to fight in design discussions is crucial.
❌ What didn't go well
❌ What didn't go well
❌ What didn't go well
Information sequencing was unclear, causing users to struggle with the correct order of filling details (e.g., duration, date, frequency).
Repetition frequency & duration covered were confusing for most users, even though some understood after multiple tries.
Scalability issue: In some companies, the number of MIDs (merchant IDs) exceeded 100+ employees, making a dropdown-based recipient selection unusable.
Information sequencing was unclear, causing users to struggle with the correct order of filling details (e.g., duration, date, frequency).
Repetition frequency & duration covered were confusing for most users, even though some understood after multiple tries.
Scalability issue: In some companies, the number of MIDs (merchant IDs) exceeded 100+ employees, making a dropdown-based recipient selection unusable.
Breaking down design decision of selected direction (iteration 03)
Breaking down design decision of selected direction (iteration 03)
What the report about
What the report about
What the report about
This sections forms the foundation of the schedule. Letting the users choose the type and give schedule a name.
Product Selection: User selects the product they need information about.
Format: Chooses report format (Excel or CSV).
Naming: Assigns a custom name (e.g., "Afternoon Reconciliation," "Weekly Schedule").
This sections forms the foundation of the schedule. Letting the users choose the type and give schedule a name.
Product Selection: User selects the product they need information about.
Format: Chooses report format (Excel or CSV).
Naming: Assigns a custom name (e.g., "Afternoon Reconciliation," "Weekly Schedule").
When is it needed?
When is it needed?
When is it needed?
Once the basic details about what the reports are about, schedule setup is to be done.
Now in the above section as we saw in user testing, we saw 50% of the enterprise users needed customisation and minute modifications while rest 50% didn’t need custom at all. SME and MM also didn’t need customisation.
Hence we decided to make the “custom” scheduling OFF as default and allowed users to switch it on when they want as a friction step.
Once the basic details about what the reports are about, schedule setup is to be done.
Now in the above section as we saw in user testing, we saw 50% of the enterprise users needed customisation and minute modifications while rest 50% didn’t need custom at all. SME and MM also didn’t need customisation.
Hence we decided to make the “custom” scheduling OFF as default and allowed users to switch it on when they want as a friction step.
So the flow looked something like this:
Start Date:
Users select the schedule start date; defaults to today if unspecified.
Data & Duration: Users specify:
Duration of data (e.g., "1 week of data").
Frequency (e.g., "weekly").
Universal frequency options (daily, weekly, etc.) are standardized.
Default logic:
Selecting a duration auto-sets and locks frequency.
(e.g., "1 week of data" defaults frequency to "weekly.")To edit frequency differently, users must select "Custom" scheduling.
Delivery Time: Users specify report delivery time.
Custom Toggle:
When enabled, allows flexible duration options such as past 2 days, 3 days, weekly, 15 days, month, or past quarter.
So the flow looked something like this:
Start Date:
Users select the schedule start date; defaults to today if unspecified.
Data & Duration: Users specify:
Duration of data (e.g., "1 week of data").
Frequency (e.g., "weekly").
Universal frequency options (daily, weekly, etc.) are standardized.
Default logic:
Selecting a duration auto-sets and locks frequency.
(e.g., "1 week of data" defaults frequency to "weekly.")To edit frequency differently, users must select "Custom" scheduling.
Delivery Time: Users specify report delivery time.
Custom Toggle:
When enabled, allows flexible duration options such as past 2 days, 3 days, weekly, 15 days, month, or past quarter.
Who is it needed for?
Who is it needed for?
Who is it needed for?
Add old screenshot of email functionality
Initially, only dropdown functionality was provided to select recipients.
User Testing Insight: Some organizations had 50-100 team members, creating a long, cumbersome dropdown.
Solution: Added search functionality within the dropdown for improved usability.
Add old screenshot of email functionality
Initially, only dropdown functionality was provided to select recipients.
User Testing Insight: Some organizations had 50-100 team members, creating a long, cumbersome dropdown.
Solution: Added search functionality within the dropdown for improved usability.
Simplifying Calendar Component
Simplifying Calendar Component
Product Team's Vision
Product Team's Vision
Product Team's Vision
The product and business teams aimed to let users create recurring schedules for reports. The ideal scenarios included receiving daily reports with past 24-hour data, weekly reports with past week’s data, and similarly monthly, quarterly, and yearly reports. Additionally, the business team required allowing flexibility, such as receiving a daily report with past 3 days of data, which would cause repetitive data on the 2nd and 3rd day.
The product and business teams aimed to let users create recurring schedules for reports. The ideal scenarios included receiving daily reports with past 24-hour data, weekly reports with past week’s data, and similarly monthly, quarterly, and yearly reports. Additionally, the business team required allowing flexibility, such as receiving a daily report with past 3 days of data, which would cause repetitive data on the 2nd and 3rd day.
Initial Design Exploration
Initial Design Exploration
Initial Design Exploration
Initially, all scheduling fields (e.g., Duration Covered and Repetition Frequency) were combined into a single, complex grid structure. To clarify:
Duration Covered: Range of data included in the report (e.g., past week's data).
Frequency: How often the report repeats (e.g., daily, weekly).
Initially, all scheduling fields (e.g., Duration Covered and Repetition Frequency) were combined into a single, complex grid structure. To clarify:
Duration Covered: Range of data included in the report (e.g., past week's data).
Frequency: How often the report repeats (e.g., daily, weekly).
Internal Challenge & Hypothesis
Internal Challenge & Hypothesis
Internal Challenge & Hypothesis
Lack of Initial User Research:
Without upfront research, it was challenging to justify simplifying these complex customization options. Product team relied on enterprise user data, advocating for detailed customization.Product Team's Logic:
Claimed enterprise customers frequently requested detailed customization. But I believed this data was skewed toward large enterprises, neglecting the 95% of SME & mid-market users.My Hypothesis: Excessive customization would confuse most users (SMEs & MM). Proposed keeping customization backend-managed for few enterprises, preserving a simple experience for majority users.
Trade-off Decision:
Faced a trade-off between:Ensuring excellent user experience for majority users
Providing extensive functionality for large enterprises
Conclusion:
As the product team was the final decision-maker, we agreed to conduct usability testing to validate my hypothesis vs. their requirements.
Lack of Initial User Research:
Without upfront research, it was challenging to justify simplifying these complex customization options. Product team relied on enterprise user data, advocating for detailed customization.Product Team's Logic:
Claimed enterprise customers frequently requested detailed customization. But I believed this data was skewed toward large enterprises, neglecting the 95% of SME & mid-market users.My Hypothesis: Excessive customization would confuse most users (SMEs & MM). Proposed keeping customization backend-managed for few enterprises, preserving a simple experience for majority users.
Trade-off Decision:
Faced a trade-off between:Ensuring excellent user experience for majority users
Providing extensive functionality for large enterprises
Conclusion:
As the product team was the final decision-maker, we agreed to conduct usability testing to validate my hypothesis vs. their requirements.
Insights from Usability Testing
Insights from Usability Testing
Insights from Usability Testing
Usability Testing Round 01 revealed:
Users found Duration and Frequency extremely confusing.
Grid structure with overlapping fields like “repeat on” dropdown caused redundancy and complexity.
Initial approach was inspired by Google Calendar, allowing complex customizations (e.g., select specific days for weekly reports or specific dates for monthly reports).
Usability Testing Round 01 revealed:
Users found Duration and Frequency extremely confusing.
Grid structure with overlapping fields like “repeat on” dropdown caused redundancy and complexity.
Initial approach was inspired by Google Calendar, allowing complex customizations (e.g., select specific days for weekly reports or specific dates for monthly reports).
Custom schedule: simplified user experience
Custom schedule: simplified user experience
Custom schedule: simplified user experience
In the new approach, custom was made default OFF, adding friction for SME
Data duration and repetition were made co-dependent. While users can choose which field to fill first, the other field will automatically be filled with right option and would not be editable.
Example: If user selects Data duration as 24hours or 2 days or 3 days, the repetition will automatically be set to “daily” and won’t be changeable. Similarly for duration: past week, repetition would be set to weekly.
The only change one could do is to choose the day of the week on which they would get the report
In the new approach, custom was made default OFF, adding friction for SME
Data duration and repetition were made co-dependent. While users can choose which field to fill first, the other field will automatically be filled with right option and would not be editable.
Example: If user selects Data duration as 24hours or 2 days or 3 days, the repetition will automatically be set to “daily” and won’t be changeable. Similarly for duration: past week, repetition would be set to weekly.
The only change one could do is to choose the day of the week on which they would get the report
Schedule Modal: with Custom
Schedule Modal: with Custom
Schedule Modal: with Custom
Download custom calendar: simplified user experience
Download custom calendar: simplified user experience
Download custom calendar: simplified user experience
New download without custom
For standard cases of everyday, weekly, monthly downloads, users got ideal duration period within dropdown.
This decision was taken as many users did reconciliation on specific time of the day or specific days of the week or month.
New download with custom
Solving the use case for SMEs, MM and Enterprise.
For SME, reconciliation is occasional and can require a specific date range.
For MM and Enterprise, schedules solve the majority use cases. In case of error tallying or emergencies, custom date range download was needed.
Additionally in some cases, users were just used to download than schedule and they use custom date range
New download without custom
For standard cases of everyday, weekly, monthly downloads, users got ideal duration period within dropdown.
This decision was taken as many users did reconciliation on specific time of the day or specific days of the week or month.
New download without custom
Solving the use case for SMEs, MM and Enterprise.
For SME, reconciliation is occasional and can require a specific date range.
For MM and Enterprise, schedules solve the majority use cases. In case of error tallying or emergencies, custom date range download was needed.
New download without custom
Additionally in some cases, users were just used to download than schedule and they use custom date range
Some Other Screens from Schedule Journey
Some Other Screens from Schedule Journey
Result & Learnings
Result & Learnings
With the launch of self serve reporting, we also launched a banner on the dashboard to publicize it to SME merchants.
We saw an overall increase in schedules by 108%, almost more than double in number. This is data of 4 months. 3000 schedules in 4 months.
Reduce in number of tickets by 83%
Since this was one of my first projects, I started with product requirements. And after considerable development, I realised that some of requirements were micro optimizations. It took multiple rounds of usability to convince product and business and also to gain confidence in the current state of project. In any project, any kind of usability testing is good and necessary. It can save a lot of time.
With the launch of self serve reporting, we also launched a banner on the dashboard to publicize it to SME merchants.
We saw an overall increase in schedules by 108%, almost more than double in number. This is data of 4 months. 3000 schedules in 4 months.
Reduce in number of tickets by 83%
Since this was one of my first projects, I started with product requirements. And after considerable development, I realised that some of requirements were micro optimizations. It took multiple rounds of usability to convince product and business and also to gain confidence in the current state of project. In any project, any kind of usability testing is good and necessary. It can save a lot of time.
Let’s make businesses people will remember!
Proudly made with Framer & Love
By Apoorva Agrawal
Let’s make businesses people will remember!
Proudly made with Framer & Love
By Apoorva Agrawal
Let’s make businesses people will remember!
Proudly made with Framer & Love
By Apoorva Agrawal