/work/mita

MITA™

MITA.

The Music Investment App

Services provided:

Brand Evolution
Web Design + Development
Asset Creation

Launch the live site:

joinmita.com

Made in Barcelona, SPain

2023

/Work/Settle-Club

Settle Club

Designing Credit for
India's First-Time Borrowers

Lead Product Designer

12 weeks · 1 Designer, 2 Engineers, 1 PM

55% checkout completion (vs 41% avg)

Settle Club app screens displayed on mobile devices

The problem we solved

"I thought BNPL was
like UPI, free. When the
EMI debited, I panicked."

Usability participant, 23, Pune

1. Understanding

Most users don't understand what they're agreeing to. In India's BNPL market, 60% of target users have never had formal credit. They think BNPL works like UPI, free and instant. The gap between that expectation and an actual credit obligation is the core design problem.

2. Regulation

RBI's Digital Lending Directions 2025 mandate a Key Fact Statement showing APR, total cost, and cooling-off period before checkout consent. Every additional screen before payment reduces completion by about 12%. The design has to make that mandatory disclosure feel useful, not like a speed bump.

3. Revenue

Revenue comes from merchant MDR (2-4%). The product has to work for borrowers and merchants while keeping three lending partners happy: CASHe, LiquiLoans, and U GRO, each with different risk appetites. It routes each transaction to the best available lender, but the user should never feel auctioned.

LazyPay, Simpl, and UPI Credit Line all compete for this same user. Settle Club's bet is that showing the true cost upfront wins more of them long-term.

We had a hunch. If someone sees the full cost and still goes ahead, they're probably going to pay it back. Fewer defaults means we can offer merchants a lower MDR. So the design argument doubles as a business argument.

Credit Score: Factor Breakdown

Free bureau pull · Score history · Factor breakdown

Free CIBIL pull shows the score, a history graph, and the factors behind it: payment history, credit utilisation, account age. Everything is written so users actually read it. If something looks wrong, the contest flow lets users dispute errors without leaving the app. Average score of active users: 752.

Credit score breakdown screen on iPhone

Who we designed for

First-Time
Borrowers

Priya

24 · Content creator · Bangalore

01

No credit history and no CIBIL record. Complete blank slate.

02

Got burned by a hidden subscription fee once. Now reads every line before tapping "confirm."

03

Mental model: “BNPL = free like UPI”

04

Checks her CRED score weekly but doesn't actually know what APR means.

What this meant for the design

Show total cost in rupees before consent. If the user can't see exactly what they'll pay in one glance, the screen has failed.

Ramesh

36 · Kirana shop owner · Nagpur

01

Runs on informal credit (udhar khata). Trusts the shopkeeper down the road, not an app.

02

Associates formal debt with harassment. His neighbour got collection calls at 6am and he still talks about it.

03

Mental model: “Credit = relationship with a person I trust”

Design Implication

Named lender contacts, visible grievance paths, language that never sounds like a threat.

Synthesized from 14 user interviews · 8 first-time credit, 6 small business owners · Tier 1–3 cities

Comprehension First

Users see the total cost before they commit

Settle Club app showing total cost before checkout

Lender Details

CASHe · ₹14,500 due · Credit stats visible

Hand holding phone showing lender details and credit stats

The cost-display card carries the same data structure across checkout, repayment, and overdue screens. Users always see the number they agreed to.

Design Principle
48 components · 8 tokens · Shared across all flows
Cost-display card shown across checkout, repayment, and overdue states

How we got here

The Hard
Decisions

Non-Blocking KYC
Speed vs. Risk

Constraint

RBI requires KYC for all lending. Mid-flow document upload kills 45% of conversions. Users expect the speed of UPI, not a bank loan application.

Options considered

Killed

Option A: Full KYC upfront. PAN + Aadhaar + selfie + Video KYC before any credit exposure.

Shipped

Option B: Tiered KYC. Soft credit pull for a micro-limit (Rs 5,000), Aadhaar eKYC for standard limit, deferred Video KYC for full limit.

PAN entry screenPAN + soft pull
DigiLocker document fetchDigiLocker fetch
KYC approved with Rs 5,000 micro-limitApproved · ₹5K limit

Who disagreed

Risk team pushed for full KYC before any credit exposure, and honestly, they had a point. Micro-limits without identity verification is a real fraud surface. We couldn't just dismiss that. The compromise: we kept the Rs 5,000 cap they wanted, but replaced upfront document collection with passive fraud signals (device fingerprinting, behavioral patterns during onboarding). Risk also insisted on a manual review trigger if any signal looked off, even on small amounts. We agreed. Two weeks of data showed <0.3% fraud on micro-limits, which got us the green light for tiered rollout, but the manual review trigger stayed in.

Outcome KYC completion: 34% → 68%

KFS Compliance
Legal Wall vs. Comprehension

Constraint

RBI mandates a Key Fact Statement showing APR, total cost, and cooling-off period before checkout consent. Legal team wanted the full regulatory text presented as-is.

Options considered

Killed

Option A: Full-text legal dump. Every RBI-mandated disclosure in one scrollable screen of regulatory language.

Shipped

Option B: Structured card format. Plain-language summaries for each KFS item, with expandable sections revealing the full regulatory text.

Checkout screen showing Rs 14,500 with EMI optionsCheckout · ₹14,500
Key Fact Statement with loan details and APRKFS drawer
Full KFS sanction letter from CASHeSanction letter

Who disagreed

Legal wanted verbatim RBI language, unedited, on screen. Their concern was legitimate: if a regulator audits and the mandated text has been "summarized," that's a compliance risk the company bears. We showed them the usability data anyway. 0 of 8 test participants could find the APR in the legal wall. In the card format, 7 of 8 found it in under 5 seconds. That moved the conversation, but legal still wouldn't sign off on summaries alone. The middle ground: plain-language cards up front, with the full unedited regulatory text preserved word-for-word inside expandable sections. Legal reviewed every summary line before launch.

Outcome KFS comprehension: 12% → 87% could state their total cost

Lender Routing
Abstraction vs. Transparency

Constraint

Three lending partners — CASHe, LiquiLoans, U GRO — each with different risk appetites, approval rates, and terms. Some users get approved by multiple lenders; some by none. The product must route to the best option without making the user feel auctioned.

Options considered

Killed

Option A: Abstract the lender. User sees "Settle Club credit" with no lender branding. Simpler UX, but hides the lending relationship.

Shipped

Option B: Show lender name and terms post-approval. If multiple lenders approve, let the user compare and choose. If none approve, show a specific "no lenders available" state with next steps.

Two lenders identified based on credit scoreLenders matched
Rejection with alternative lender optionsRejection · alternatives
Application in queue processingQueue · processing

Who disagreed

Business team wanted to own the customer relationship and hide lender branding. One of our own designers actually agreed with them. Her argument: showing three different lender brands makes the experience feel fragmented, like a marketplace instead of a product. She wasn't wrong. But RBI mandates lender disclosure, so hiding the name was never really an option. We tested both versions anyway. Users who saw lender names reported higher trust because they recognized CASHe and LiquiLoans. The fragmentation concern turned out to matter less than we expected. We did take her feedback and unified the visual treatment so lender cards feel like part of one system, even with different names on them.

Outcome Trust score: +18% when lender name visible vs. hidden

Overdue Comms
Urgency vs. Empathy

Constraint

Must recover payments without being predatory. Users are often 22–25 year olds on their first credit product. The collections path is where lending products build or destroy trust.

Notification escalation

Each payment state triggers a specific notification. Language graduates from informational to protective as urgency increases.

Current 7 days before

"Your payment of Rs 1,250 is due on July 26th"

Neutral
Approaching 3 days before

"Rs 1,250 is due in 3 days. Tap to pay now so you don't have to think about it later"

Warm
Due Today Day of

"Rs 1,250 is due today. Paying on time helps keep your account in good standing"

Encouraging
Grace 1-2 days after

"Your payment was due yesterday. Here's how to get back on track"

Helpful
Overdue 3 days past

"Your payment of Rs 1,250 is past due. Late payments affect your credit limit. Let's sort this out"

Serious
Frozen 7+ days past

"Your account is on hold. Here are your options:"

Pay full balance Set up a plan Talk to us
Protective

Paid transitions from every non-Frozen state. Partial payment stays in current tier. Frozen requires manual review + payment plan.

Who disagreed

PM wanted aggressive red banners from day 1, and to be fair, his instinct came from somewhere real. The previous product he worked on had a serious late-payment problem and harder language helped there. Different audience though. Our users are 22-25 year olds on their first credit product. We A/B tested graduated vs. aggressive with 20 participants per round. Graduated language had +27% higher self-serve resolution. But the PM was right that the very last stage (7+ days overdue) needed firmer language than our first draft had. We tightened that end of the ladder based on his pushback.

Outcome +27% self-serve overdue resolution

Results at launch

Measured Impact

55%

Checkout Completion

n = 2,400 sessions
14-day post-launch window

Pre-redesign baseline: 41%. Industry avg for Indian BNPL: 38–44% (source: internal benchmark across 3 merchant partners).

68%

KYC Completion

n = 1,800 started flows
First 21 days

Pre-redesign: 34%. Tiered KYC (micro-limit at Rs 5K without Video KYC) accounted for 60% of the lift. 22% completed across two sessions via save-and-resume.

87%

KFS Comprehension

n = 8 usability participants
Moderated, in-person, Pune

Pre-redesign: 12% could state their APR. Small sample — directional, not statistically significant. Validated by 30-day post-launch support ticket analysis: cost-related queries dropped 41%.

+27%

Self-Serve Resolution

n = 20 participants per variant
A/B test, 2 rounds

Graduated tone vs. aggressive red banners. Resolution-first language drove higher self-serve payment. Caveat: unmoderated remote test — real-world effect may differ.

All metrics from first 30 days post-launch unless noted. Checkout and KYC are product analytics (Mixpanel). Comprehension is qualitative (moderated usability). Resolution is A/B (unmoderated, Maze).

55% checkout completion. 68% KYC completion. +27% self-serve overdue resolution. 2.4x repeat purchases in 90 days.

Results at Launch
12 weeks · 24 screens · 48 components

Checkout: Payment Selection

Pay in full or split into EMIs. Every option shows the exact rupee amount upfront, fees included. Instalment plans break out the total cost across 3, 6, or 9 months with processing fee and interest on separate lines.

Payment selection screen showing EMI options

Repayment Tracking

Payment details · EMI schedule · Overdue alerts

Every transaction shows the lender, order ID, and repayment timeline. Upcoming EMIs, amounts paid, overdue status: it is all on one screen.

iPhone in jacket pocket

Merchant Checkout

Pay with Settle Club credit · EMI selection · Instant approval

Users pay at any merchant partner using Settle Club credit. Choose full payment or split into 3, 6, or 9 month EMIs. Lender approved in under 3 seconds. The checkout widget drops into any merchant app via SDK.

/Work/Settle-Club

What I Owned

I designed three flows end to end: KYC onboarding (PAN, Aadhaar via DigiLocker, liveness check), checkout with EMI plan selection, and repayment tracking including overdue resolution. 24 screens, 48 components, 8 design tokens covering colour, type, spacing, and elevation.

The cost-display card carried across checkout, repayment, and overdue. A progress stepper tied together KYC and repayment timelines. The action sheet handled plan selection and payment confirmation. Those three did most of the heavy lifting.

How I Worked With Engineers

API Scoping

Feasibility sessions before design

Feedback Loops

Engineer review after each round

Handoff

Figma Dev Mode, annotated props + states

Shared UI Logic

Core components reused across iOS + Android

Before designing anything, I sat with the engineers and walked through what was feasible: what APIs existed, what data we could get, what would need new backend work. Specs went through Figma Dev Mode with annotated props and states. Engineers reviewed every round of design, starting from sprint planning.

Built under RBI's Digital Lending Guidelines (Sep 2022, updated 2024). Compliance shaped how we structured consent flows and what information had to be visible at each step.

Systems thinking

One Component,
Three Props

The lender card is the most reused component in the app. It shows credit limits, KYC progress, overdue alerts, and failure states. Instead of designing 10 separate screens, I designed one card that renders all 10 states from three props. The developer wrote one switch statement. When the third lender joined, nothing changed on the frontend.

<LenderCard status={"active" | "kyc_pending" | "approved" | "overdue" | "unavailable" | "loading"} kyc_step={1 | 2 | 3} has_history={boolean} />

State transitions

LenderCard state transitions KYC PENDING DIGILOCKER SELFIE E-SIGN SPEND DEFAULT OVERDUE UNAVAILABLE TRANSACTIONS LOADING any state timeout has_history
Lifecycle states
Default card

Default

Active account with available limit and next EMI due. The baseline layout every other state inherits from.

Spend card

Spend

Fully approved. CTA shifts to "Start Spending". The user is ready to transact.

Overdue card

Overdue

Red banner with days past due. Amount turns red. Limit stays visible so users know what's at stake.

Unavailable card

Unavailable

Lender can't offer credit. Card stays instead of vanishing. Shows "No Limit" and explains why.

Loading card

Loading

API timeout. Card grays out with a refresh spinner instead of a dead error screen.

KYC funnel + edge cases
KYC Pending card

KYC Pending

Lender matched, KYC not started. Shows the limit they can unlock to motivate completion.

DigiLocker card

DigiLocker

First KYC step. CTA says "Connect to DigiLocker". Same card, only the action changes.

Selfie card

Selfie

Second KYC step. "Capture your Selfie" replaces DigiLocker CTA. Limit stays the same throughout.

E-Sign card

E-Sign

Final KYC step. Label changes to "Approved Limit". One tap to activate.

Transactions card

Transactions

Lender gone, but past transactions still accessible. Card persists so nothing disappears.

1 component.
3 props.
10 states.

The developer wrote one LenderCard component with a switch on status, kyc_step, and has_history. When the third lender joined mid-project, the frontend needed zero changes. The API returns a lender, the card renders it.

How we spent the time

12 Weeks,
Honestly

12 weeks · 1 designer, 2 engineers, 1 PM

How We Actually Spent 12 Weeks

 123456789101112
Research
14 interviews
Synthesis
Design
Framing
Prototype v1
Iterate
System
System
Checkout
Overdue
Repayment
Usability
2 days
3 days
Engineering
KYC build
KYC build
Ship KYC
Checkout
Checkout
Lenders
QA
Launch
Shipped
KYC Live
Full Launch
Active
High intensity
Compressed window
Shipped
W1
Research — 14 interviews in 5 days
W2–3
Research — SynthesisDesign — Framing → Prototype v1
W4
Design — Iterate post-testingUsability — 2-day window, 8 participants
W5–6
Design — 48 components, 8 tokensEngineering — KYC build started
W7
Shipped — KYC live with CASHeDesign — Checkout flow
W8
Design — Overdue commsUsability — 3-day A/B testEngineering — Checkout build
W9–11
Design — Repayment flowEngineering — Lender integration + QA
W12
Shipped — Full launch, 3 merchants

Key moments

W1

14 interviews in 5 days. PM pulled field research forward because lender contracts were closing. Pre-recruited participants in Pune and Nagpur — no time for a second round.

Compressed
W3–4

Engineering idle — waiting on CASHe API specs. Lender hadn't finalized their sandbox environment. Engineers used the gap to set up CI/CD and write integration test scaffolding. Design continued without them.

Blocked
W4

Legal rejected the first KFS approach mid-sprint. Full-text disclosure was non-negotiable. Redesigned as a structured card format in 48 hours. Tested the next day — 7/8 participants found the APR in under 5 seconds.

Pivot
W5

Engineering started the KYC build while checkout design was still in progress. Possible because each KYC step mapped to one API call — engineers could build and test screens independently.

Parallel
W7

KYC shipped to production mid-project. Tiered model live with CASHe. Micro-limit (Rs 5K) without Video KYC. Checkout design continued in parallel — two workstreams, one designer.

Shipped
W8

A/B test squeezed into 3 days between releases. Graduated vs. aggressive overdue copy. 20 participants per variant, unmoderated (Maze). Had to run it before the checkout build locked the notification system.

Compressed
W10

Design paused — waiting on legal sign-off for multi-lender disclosure language. Used the gap to document component specs and write handoff notes for the repayment flow. Resumed when legal approved the templated KFS approach.

Blocked
W12

Full launch across 3 merchant partners. 24 screens, 48 components. Adding a new lender required zero frontend changes — server-side routing meant the UI rendered whatever the API returned.

Shipped

The KFS component accepts locale-specific regulatory text, so adding a new market means updating the content, not the layout.

KFS Disclosure & Error Handling

Key Fact Statement · Lender terms · Cooling-off period

RBI mandates full cost disclosure before checkout. The KFS card shows lender name, APR, contingent charges, and grievance officer, all written to be understood on first read. When payments fail, the error state reassures users that no deduction was made.

KFS disclosure card and payment error handling screens

Design thesis

Show the rupee
amount first

What we learned

Every BNPL app we benchmarked buried the real cost inside percentage rates and multi-page PDFs. 73% of users in our sample never opened the agreement. That told us the format was wrong, not the users.

So we made one rule for every screen in Settle Club: the total rupee amount you owe is always visible, in plain text, before you commit to anything. No APR math, no scrolling. If the number scares you off, good. That is the product working.

Flow 01

KYC
Onboarding

7-step KYC flow. Each step maps to one API call, so screens could be built and tested independently without waiting on the full pipeline. Progress stepper and save-and-resume meant 22% of users finished across two sessions. The stepper component got reused in repayment timelines later.

74%

KYC completion
vs 58% avg

22%

Completed across
two sessions

19 screens

Splash
Welcome
Enter mobile
OTP
PAN
PAN error
Confirm identity
Complete KYC
KYC alt
Lender selection
DigiLocker
DigiLocker not accessed
Documents
Selfie
Captured
Validated
Rejection
Queue
Roadmap

Flow 02

Home

The main dashboard pulls from five data sources: active loans, credit limit, upcoming EMIs, credit score, and transactions. Each widget handles its own loading and error states so the page never feels stuck waiting. Empty states guide new users instead of showing blank cards.

5 screens

Dashboard
Empty
Minimal
Empty state
Lender details

Flow 03

Transactions

Full transaction history with search, date filters, and lender sorting. The tricky part was keeping filter combinations manageable. I spec'd them as query parameters against one endpoint instead of separate calls per combination. The detail view shares the same cost-display card from checkout, one component across both flows.

7 screens

Transactions
Details
Date filter
Category filter
My transactions
No results
Empty

Flow 04

Credit
Score

Credit score with factors breakdown and history graph. The bureau API returns raw data, so I shaped the factor cards to match that structure directly. Less work translating between design and API, fewer bugs in production. The score graph uses the same charting component across compact and full views. Contest flow lets users dispute errors without leaving the app.

752

Avg score of
active users

8 screens

Compact
Detail
Factors
Full
Dark
Bank
No report
Contest

Flow 05

Repayment

Same cost-display card from checkout appears here. Users see exactly the numbers they agreed to, no recalculation needed. The payment method selector (UPI, net banking, card) is a single action sheet with swappable content. First version had three separate screens for each method, which was a pain to keep consistent, so I collapsed them into one.

55%

Checkout
vs 41% avg

2.4x

Repeat
in 90 days

7 screens

Repayment
Options
UPI
Net banking
Approve
Dashboard
Lender

Flow 06

Merchant
Checkout

Merchant-facing checkout widget. EMI plan selector, lender switching, and KFS disclosure all live in one embedded flow that drops into any merchant app via SDK. Lender routing happens server-side. The UI just renders whatever lender comes back, so new lending partners don't require frontend work.

8 screens

Checkout
EMI
Change lender
KFS
Loan details
Success
Failed
Pending

Flow 07

Raise a
Request

Issue reporting with evidence upload and ticket tracking. Every screen has one primary action. No branching, no decision fatigue for the user. The upload component compresses images client-side before sending, which mattered since most users are on slow mobile connections. Status screens pull from the same ticket object, so one endpoint serves the entire flow.

61%

Self-serve
vs 34% avg

6 screens

Report
Upload
Track
Open issue
Success
No issues

Flow 08

Profile

Account settings, personal details, and policy documents. Flat list of action rows, same pattern as the KYC settings screens. The account deletion flow follows RBI data retention rules. I designed a two-step confirmation that meets compliance without needing a custom modal.

6 screens

Minimal
Main
Refer
Policy
Logout
Delete

More from the portfolio

Keep
Exploring

Available for projects and open to senior roles in the UK.

Get in touch