How I led user research and design of a gold backed loan product from concept to launch, increasing conversion by 8%
Company
Rupeek Fintech (2021-22)
Role
UX Researcher, Designer
Methods
Concept testing, field research, semi-structured interviews, wireframing and prototyping, usability testing
Deliverables
Personas, Storyboarding, Usability test reports, Journey mapping, Overall UX research reports
Tools
Figma, Dovetail, Excel, Fullstory, Google meet
How I led user research and design of a gold backed loan product from concept to launch, increasing conversion by 8%
Company
Rupeek Fintech (2021-22)
Role
UX Researcher, Designer
Methods
Concept testing, field research, semi-structured interviews, wireframing and prototyping, usability testing
Deliverables
Personas, Storyboarding, Usability test reports, Journey mapping, Overall UX research reports
Tools
Figma, Dovetail, Excel, Fullstory, Google meet
Context and Problem
Gold Teller Machine (GTM) - A self serve machine for instant gold loans.
In the Indian context, gold is a very important asset that is used as a collateral for short term monetary requirements. Rupeek's main service is doorstep gold loans. With a massive gold loan demand , the purpose of the GTM was to make credit accessible across the economic pyramid, multiple geographies (Tier 1,2,3 cities, remote locations)
0 to 1 Challenge: The GTM was one of its kind machine to disburse automated gold loans which would otherwise take couple of hours to avail and involve human dependency
Problem
?
Solution
?
Impact
8% ↑
Conversion Rate
85%
User Satisfaction (NPS)
100%
Task Completion
Context and Problem
Gold Teller Machine (GTM) - A self serve machine for instant gold loans.
In the Indian context, gold is a very important asset that is used as a collateral for short term monetary requirements. Rupeek's main service is doorstep gold loans. With a massive gold loan demand , the purpose of the GTM was to make credit accessible across the economic pyramid, multiple geographies (Tier 1,2,3 cities, remote locations)
0 to 1 Challenge: The GTM was one of its kind machine to disburse automated gold loans which would otherwise take couple of hours to avail and involve human dependency
Problem
?
Solution
?
Impact
8% ↑
Conversion Rate
85%
User Satisfaction (NPS)
100%
Task Completion
Research Questions
1
How do customers use/think/feel about existing options to avail a gold loan?
2
What factors influence a customer's decision when selecting a gold loan offering?
3
How might GTM positively impact the gold loan experience of customers?
Research Questions
1
How do customers use/think/feel about existing options to avail a gold loan?
2
What factors influence a customer's decision when selecting a gold loan offering?
3
How might GTM positively impact the gold loan experience of customers?
Research
I interviewed 12 users across four functions that request and use literature reviews: Health Economics and Outcomes Research (HEOR), Market Access, Medical, and Marketing. The research was organized around two questions:
01
How do teams discover, conduct, manage, govern, and reuse literature reviews today?
02
What influences adoption and trust when manual
review is replaced by AI?
Research
I interviewed 12 users across four functions that request and use literature reviews: Health Economics and Outcomes Research (HEOR), Market Access, Medical, and Marketing. The research was organized around two questions:
01
How do teams discover, conduct, manage, govern, and reuse literature reviews today?
02
What influences adoption and trust when manual
review is replaced by AI?
Key Findings
WHAT RESEARCH FOUND
WHAT WE DECIDED
01
Tracking ran on meetings, not systems
Teams relied on status meetings to know where a review stood.
A single point of entry for all literature review requests
02
Past reviews were invisible
The only way to find an existing review was word of mouth.
A broadly accessible repository of existing review output
03
Vendors were an administrative burden
Engaging external vendors added overhead for every request.
A short-term internal team (HP CXE) for some requests; only business-critical reviews outsourced
04
Internal reviews felt more transparent
Users saw more of the work when it ran in-house.
Reinforced bringing execution in-house
05
AI was welcome, within limits
Trusted for low-risk tasks, not for final or regulated outputs.
AI built into execution for basic literature reviews
Where users drew the line on AI
AI CAN HELP WITH
Search term suggestions
Rapid scanning
First-pass summaries
Structuring content
PEOPLE KEEP CONTROL OF
Regulatory submissions
External publications
Final abstraction
Key Findings
WHAT RESEARCH FOUND
WHAT WE DECIDED
01
Tracking ran on meetings, not systems
Teams relied on status meetings to know where a review stood.
A single point of entry for all literature review requests
02
Past reviews were invisible
The only way to find an existing review was word of mouth.
A broadly accessible repository of existing review output
03
Vendors were an administrative burden
Engaging external vendors added overhead for every request.
A short-term internal team (HP CXE) for some requests; only business-critical reviews outsourced
04
Internal reviews felt more transparent
Users saw more of the work when it ran in-house.
Reinforced bringing execution in-house
05
AI was welcome, within limits
Trusted for low-risk tasks, not for final or regulated outputs.
AI built into execution for basic literature reviews
Where users drew the line on AI
AI CAN HELP WITH
Search term suggestions
Rapid scanning
First-pass summaries
Structuring content
PEOPLE KEEP CONTROL OF
Regulatory submissions
External publications
Final abstraction
Users
The platform and service was designed for 2 user groups: the people who need reviews and the team that delivers them
R
Requester
HEOR, Market Access, Medical & Marketing
NEEDS
Submit a request
Find existing reviews
Track status
PAIN POINTS
No view of past reviews
Status only via meetings
Vendor paperwork
D
Delivery Unit
Triages, scopes & runs reviews
NEEDS
Triage requests
Catch duplicates
Update status
PAIN POINTS
No central intake
Duplicates hard to spot
Manual status updates
Users
The platform and service was designed for 2 user groups: the people who need reviews and the team that delivers them
R
Requester
HEOR, Market Access, Medical & Marketing
NEEDS
Submit a request
Find existing reviews
Track status
PAIN POINTS
No view of past reviews
Status only via meetings
Vendor paperwork
D
Delivery Unit
Triages, scopes & runs reviews
NEEDS
Triage requests
Catch duplicates
Update status
PAIN POINTS
No central intake
Duplicates hard to spot
Manual status updates
Process
Process
The pivot: from AI platform to trust-building MVP
Research changed the product's direction. The original vision put AI across the full review lifecycle, but users had real reservations about that. What they needed first was a simpler way to request, track and find reviews.
So we narrowed the scope to an MVP designed to earn trust and adoption before expanding AI's role.
FULL VISION
Full review lifecycle
AI-driven review execution
Deep collaboration features
Reporting features
SCOPE
CHANGE
MVP SCOPE
Central request intake & triage
Central review repository
Status updates from the Delivery Unit
AI for discovery & basic summaries
The pivot: from AI platform to trust-building MVP
Research changed the product's direction. The original vision put AI across the full review lifecycle, but users had real reservations about that. What they needed first was a simpler way to request, track and find reviews.
So we narrowed the scope to an MVP designed to earn trust and adoption before expanding AI's role.
FULL VISION
Full review lifecycle
AI-driven review execution
Deep collaboration features
Reporting features
SCOPE
CHANGE
MVP SCOPE
Central request intake & triage
Central review repository
Status updates from the Delivery Unit
AI for discovery & basic summaries
Process Mapping Workshops
I ran 6 workshops with stakeholders and users to design the end-to-end service, not just the screens. I structured each workshop and facilitated the discussion between teams with competing priorities.
For every step in the process, we defined:
The activities and outputs
The primary role responsible, and who owns quality control
The request status at that point
Expected platform behavior, screen content and notifications
The process map built with stakeholders. I facilitated the discussions, surfaced disagreements, and kept the group moving toward decisions.
Process Mapping Workshops
I ran 6 workshops with stakeholders and users to design the end-to-end service, not just the screens. I structured each workshop and facilitated the discussion between teams with competing priorities.
For every step in the process, we defined:
The activities and outputs
The primary role responsible, and who owns quality control
The request status at that point
Expected platform behavior, screen content and notifications
The process map built with stakeholders. I facilitated the discussions, surfaced disagreements, and kept the group moving toward decisions.
Design
From process map to prototype
I turned the MVP process map into user stories, then designed each screen from them. I built the prototype in Lovable so users could click through real flows early.
A note on confidentiality: Production screens have been withheld under NDA. Selected work can be presented in a 1:1 setting
Design
From process map to prototype
I turned the MVP process map into user stories, then designed each screen from them. I built the prototype in Lovable so users could click through real flows early.
A note on confidentiality: Production screens have been withheld under NDA. Selected work can be presented in a 1:1 setting
Usability Testing
I tested the prototype with 12 users- 6 Requesters, 6 from Delivery Unit.
What we needed to fix:
TRANSPARENCY
Deeper visibility into sub-statuses
Top-level statuses weren’t enough to replace status meetings.
PERMISSIONS
Permissions per user type adjusted
Users needed more autonomy to act without waiting on others.
AI TRUST
More cited references in AI answers
References are what users rely on to trust an AI answer.
AI QUALITY
More consistent, accurate AI answers
Inconsistent answers undermine trust in a regulated setting.
Usability Testing
I tested the prototype with 12 users- 6 Requesters, 6 from Delivery Unit.
What we needed to fix:
TRANSPARENCY
Deeper visibility into sub-statuses
Top-level statuses weren’t enough to replace status meetings.
PERMISSIONS
Permissions per user type adjusted
Users needed more autonomy to act without waiting on others.
AI TRUST
More cited references in AI answers
References are what users rely on to trust an AI answer.
AI QUALITY
More consistent, accurate AI answers
Inconsistent answers undermine trust in a regulated setting.
Trade Offs
1. Limiting AI to low-risk tasks
We chose: AI for discovery, search and first-pass summaries only.
We gave up: Some of the speed and cost savings that full AI execution promised.
Why: In a regulated industry, one wrong AI output in a regulatory submission could cost more than the savings. Users told us where their trust ended, and we designed to that line.
What it unlocked: Adoption. A tool people trust partly beats a tool they don't trust at all.
2. A narrow MVP instead of the full lifecycle
We chose: A few steps done well — intake, triage, repository and status updates.
We gave up: Execution, vendor management and deeper AI features in the first release.
Why: The full platform would have taken over a year. The biggest pain (duplication and invisibility) could be solved much sooner.
What it unlocked: Measurable impact within 2 months, and evidence to justify the next phase.
Trade Offs
1. Limiting AI to low-risk tasks
We chose: AI for discovery, search and first-pass summaries only.
We gave up: Some of the speed and cost savings that full AI execution promised.
Why: In a regulated industry, one wrong AI output in a regulatory submission could cost more than the savings. Users told us where their trust ended, and we designed to that line.
What it unlocked: Adoption. A tool people trust partly beats a tool they don't trust at all.
2. A narrow MVP instead of the full lifecycle
We chose: A few steps done well — intake, triage, repository and status updates.
We gave up: Execution, vendor management and deeper AI features in the first release.
Why: The full platform would have taken over a year. The biggest pain (duplication and invisibility) could be solved much sooner.
What it unlocked: Measurable impact within 2 months, and evidence to justify the next phase.
Impact
What changed after launch:
Impact
What changed after launch:
8
Duplicate reviews avoided in the first 2 months
~$1M
Saved by not repeating that work
More transparency across teams: requests and existing reviews now live in one place, instead of being tracked through meetings and word of mouth.
8
Duplicate reviews avoided in the first 2 months
~$1M
Saved by not repeating that work
More transparency across teams: requests and existing reviews now live in one place, instead of being tracked through meetings and word of mouth.
Reflections
Trust is the real product in regulated AI. Users accepted AI where mistakes were low-risk; references, consistency and human sign-off drove trust.
Research makes trade-offs easier. Knowing where users drew the line made scoping down feel like an evidence-backed decision, not a compromise.
Influence comes from structure, not title. Designing the service through shared workshops aligned teams I had no authority over.
Reflections
Trust is the real product in regulated AI. Users accepted AI where mistakes were low-risk; references, consistency and human sign-off drove trust.
Research makes trade-offs easier. Knowing where users drew the line made scoping down feel like an evidence-backed decision, not a compromise.
Influence comes from structure, not title. Designing the service through shared workshops aligned teams I had no authority over.
Next Project
SWARNA
©
Swarna Pandu
2026
Driving efficiency and usability in a clinical studies management system
Project Type
Professional project at Boehringer Ingelheim
My Role
UX Researcher and Designer
Methods
User interviews, service blueprinting, wireframing and prototyping, usability testing
Deliverables
Personas, User stories, Service Blueprints, Research reports
Tools
Figma, Dovetail, Klaxoon, Excel, JIRA
How research into a scattered clinical studies intake process led to a single platform, saving $2M in data costs, cutting task time by 41%, and lifting user satisfaction by 40%.
01
Context
OASIS, a clinical evidence study intake process, was originally built to handle fewer than 200 studies, running entirely across a patchwork of MS SharePoint pages with no dedicated product foundation. As organizational demands scaled well beyond that, the system became increasingly unstable and difficult to manage.
02
The Problem
Users struggled to navigate the process with no single place to submit, track, or review requests. It created significant workflow inefficiencies and poor transparency across the end-to-end process.
03
Research Approach
Stakeholder interviews
1:1 interviews with project manager, project owner, process owner, director
To gather context about the project, the goals and expected outcomes
User interviews
1:1 semi-structured remote interviews with 5 users from each user group-requesters, reviewers and analysts
To learn in depth about users experiences from the previous version and identify pain points that needed to be addressed in the new design
Service blueprint
Developed service blueprints to evaluate the user interactions, touchpoints and backend processes for different study types
The system redesign involved not only front-end actions but also numerous back-end processes that needed evaluation, which could be effectively mapped using a service blueprint.
Service blueprints are instrumental artifacts that help not only researchers but also stakeholders in visualizing the current experience being delivered.
User stories
Translated insights from user interviews and journey maps to user stories
To kickstart the agile product cycle
User testing
Once the mid-fidelity prototypes were developed, I tested them with 3–4 users from each user group. 1:1 testing with observation (task based) and think aloud
User testing not only helped in evaluating the usability but also the efficiency of the new processes for request submission, approval and tracking of requests
With the constraints of an NDA, I am only able to briefly explain my research process
04
Impact
The processes were streamlined using the future-state service blueprint I developed, and the new application was designed based on user stories.
Automating certain steps and enabling self-service reduced users' dependency on colleagues.
Transparency in the system was improved, saving $2M in data costs, reduced time on task by 41% and user satisfaction increased by 40%.
05
Reflections
Advocating for users in a low UX maturity environment
In a low UX maturity setting, I’ve driven user advocacy by educating stakeholders, demonstrating impact through insights, and embedding user needs into decision-making. Through storytelling, workshops, and quick wins, I’ve influenced teams to shift from assumption-driven to evidence-based approaches.
Navigating an enterprise environment
Enterprise environments often come with complex organizational structures, multiple stakeholders, and lengthy decision-making processes. My experience in such settings has taught me how to navigate cross-functional teams, align diverse perspectives, and balance business priorities with user needs. I have learned to tailor my communication strategies, distilling research insights into actionable recommendations that resonate with leadership while ensuring execution teams have detailed guidance.
