Portfolio Case Studies ClearPaisa
✶ FinTech · Personal Finance · Self-Initiated Framework

ClearPaisa

Trust isn’t a feature. It’s a system. A six-dimension design framework for fintech apps where 40% of users abandon onboarding before they ever see the product.

Type
Self-Initiated Framework
Role
Lead Designer
Duration
6 Weeks · 2026
Output
Framework + 6 screens + 14 microcopy rules
ClearPaisa — Trust isn’t a feature. It’s a system.
TL;DR — For hiring managers who have 90 seconds

The short version.

Problem

Indian fintech apps lose 40% of users in onboarding because they ask for irreversible commitments before earning trust.

Insight from research

Users don’t fear data theft. They fear commitment without retreat. Anxiety lives in the irreversibility of giving — not the misuse afterwards.

Solution

A six-dimension Trust Operating System — a framework any fintech team can audit, ship, and measure against. Not just an app.

Output

Framework + design tokens + 6 annotated screens + 14 microcopy rules + production validation plan.

Honest validation

5 moderated sessions surfaced strong directional signal. Production validation plan included for what I’d test next at scale.

01 — Context

Indian fintech has a trust ceiling.
No one is designing for it.

India has 14,500+ fintech startups and one of the world’s most mature payment infrastructures. Yet personal finance management apps see <8% adoption among first-jobbers — the demographic with the most to gain from them.

StatWhat it meansSource
40% of users abandon digital onboarding because it asks for things they’re unwilling to share Deloitte
24% of mobile apps are used once and uninstalled. The activation cliff is steeper in finance UXCam
₹2,500+ CAC per activated fintech user in India. Every dropped install is wasted spend Industry benchmark
The industry response has been to optimise speed: instant KYC, Aadhaar-based eKYC, sub-15-minute account opening. Faster onboarding solves a regulatory friction. It does not solve a trust problem. A user who completes onboarding in 12 minutes and uninstalls on day three has cost the company more, not less. The framing is wrong.
💡 The question I set out to answer: If trust is the ceiling, then trust must be designable. What are the specific, observable design moves that build it — and which ones, despite intent, actively destroy it?
02 — Research

Eight interviews. One diary study.
One finding that overturned the brief.

The research was deliberately scoped for a self-funded project: small enough to run with rigour, large enough to surface directional patterns. Sample sizes are called out throughout.

Methods at a glance

8
In-depth interviews

22–35 yr olds, Tier 1 metros

4
Diary study participants

14 days, daily expense log

6
Competitor apps audited

Across 11 trust signals

73%
Named “data fear”

As their primary blocker to using finance apps

Primary Persona — Built from research, not assumption

Primary Persona — Priya, 26, Software Engineer, Bengaluru

Competitive Audit — Trust Signal Score (out of 11)

AppTrust signalsData transparencyOnboarding frictionStrategic gap
CRED ● High (8/11) ● Medium ● Medium Credit cards only — locks out salaried first-jobbers
Fi Money ● High (8/11) ● High ● Low Targets high earners; bank-link mandatory
Jupiter ● High (7/11) ● High ● Low Limited manual control; auto-categorisation feels surveillant
Groww ● High (7/11) ● High ● Low Investing-first; personal finance is secondary
ET Money ● Medium (5/11) ● Medium ● Medium SMS parsing without explicit consent surfaced as anxiety trigger
Walnut ● Low (3/11) ● Low ● High SMS access required upfront; no recovery-visible design
🎯 The shared blind spot: every app in the audit assumed the user wanted bank linking and worked backwards from regulatory friction. None of them treated the choice not to link as a legitimate design state. That assumption is the gap.
03 — The Reframe

The finding that
overturned the brief.

The original hypothesis was the obvious one: users don’t trust fintech apps because they fear data theft. Three interviews in, that frame collapsed.

“It’s not that I think they’ll steal my data. It’s that the moment I link my bank, I’ve handed something over and I can’t get it back. I don’t want to feel that yet.”

Interview 04 · Software engineer · 26 · Bengaluru

The same pattern surfaced in 5 of 8 interviews. Users weren’t worried about malicious actors — they were worried about the act of giving something irreversible. Credentials, account access, biometric data: the anxiety lived in the irreversibility, not in the misuse afterwards.
The reframe: Trust isn’t built by saying “we’re safe.” It’s built by giving users moments of retreat at every step they feel exposed.

Anxiety Map — Where Existing Apps Lose First-Time Users

Anxiety map — two curves showing existing apps vs ClearPaisa across onboarding touchpoints
TouchpointExisting apps (anxiety state)ClearPaisa (anxiety state)
Install Calm Calm
Sign up Cautious Calm
Bank login ask ● High anxiety — “I closed the app” ✓ Not asked yet
Aadhaar ask ● High anxiety — “Why does it need this?” ✓ Not asked yet
Setup choice Calm — “Skip” is visible
First entry Calm — “Only you can see this”
Where in this flow does the user feel they’ve crossed a point of no return — and how do we make that point reversible, visible, and chosen?
04 — The Framework

Six designable dimensions.
Trust accrued, not declared.

A control surface, not a checklist. Each dimension is a lever a designer can audit, ship against, and measure. Together they describe trust as a system — not a feeling.

The Trust Operating System — Six designable dimensions diagram
Dimension 01
Disclosure timing

What it is. When the app asks for what. The chronology of consent — what is required at minute one versus what waits until trust has accrued.

Evidence. “I’d given the app my name and email. Then it asked for my Aadhaar. I closed the app.” — Interview 02

Pattern: Stagger requests across the value journey. Bank linking unlocks at day 7, not day 0. Aadhaar only when filing taxes is the use case. · Measure: Drop-off rate at each disclosure point.
Dimension 02
Control locus

What it is. Who is doing what to whose data — and how visible that authorship is. Users distrust passive verbs (“data is processed”) and trust active agency (“you decide who sees this”).

Evidence. Five of eight interviewees explicitly preferred manual entry to auto-sync — even when told it was “more convenient.”

Pattern: Show the user as the active subject in every microcopy line. “You logged...” not “We tracked...” Always offer manual override. · Measure: % of users keeping automation enabled at D14.
Dimension 03
Language register

What it is. The distance between how the app speaks and how the user speaks. Legalese, security jargon, and brand voice extremes all signal “this is not for me.”

Evidence. “Your data never leaves your device” tested 4× higher in trust ratings than any security icon or badge.

Pattern: “Only you can see this. Even we can’t.” Plain present-tense, second-person, concrete. · Measure: 5-second test on every trust message. Target ≥80% verbatim recall.
Dimension 04
Visual calmness

What it is. Density, colour, and motion as anxiety modulators. Most fintech UI uses urgency cues borrowed from trading apps — wrong context for personal finance.

Evidence. Three users used the word “scammy” to describe high-density dashboards. The same users described low-density layouts as “real.”

Pattern: Teal/amber palette (never red), one primary number per screen, motion only on user-initiated action. · Measure: Self-reported anxiety pre/post session.
Dimension 05
Recovery visibility

What it is. How easily the user can undo, delete, leave, or pull data out. Most apps hide these flows; surfacing them is the single highest-leverage trust move.

Evidence. Six of eight interviewees had abandoned an app because they couldn’t find the delete-account flow. They assumed it was “trapped on purpose.”

Pattern: “Leave anytime” surfaced in onboarding. One-tap data export. Account deletion in settings root. · Measure: Time-to-find delete flow (target ≤15s).
Dimension 06
Social proof layering

What it is. Whose validation matters, and where it appears. Generic “10,000+ users” badges are wallpaper. Contextual proof — at the moment of doubt — is leverage.

Evidence. Users trusted ratings most when they saw them on the screen they hesitated on, not on the splash screen.

Pattern: Just-in-time proof. On the bank-link screen: “412 users from your city linked their bank this week.” · Measure: A/B test conversion at decision points with vs. without contextual proof.
05 — Design System

From framework to tokens,
components, and copy rules.

The framework is only useful if it becomes a system designers can ship. Each Trust dimension translates to concrete artefacts.

Colour Tokens — Visual Calmness

The palette deliberately rejects the red/green convention. Loss is not a moral failure to be flagged — it’s information. Tokens are named semantically (intent, not hue) so the system can re-skin without breaking patterns.

TokenHexRole
--surface-paper#F4EFE6Default canvas. Warm enough to feel human, neutral enough to recede.
--ink-primary#0E0E0CPrimary type and high-emphasis surfaces. Not pure black.
--accent-trust#1E4D49Affirmative actions, on-track states. Stable, not loud.
--accent-attention#B47A2EWarmth and emphasis. Used for nudges, never urgency.
--accent-critical#A23E2CReserved for true urgency only — fraud, overdraft. Never spending.

Typography — Language Register

RoleFamilyUse
DisplayBricolage Grotesque 500Headlines, hero numbers, screen titles
EditorialInstrument Serif italicTrust-building emotional accents (“your way”, “no rush”)
BodyGeist 400All UI copy. Plain, second-person, concrete.
MonoGeist Mono 400Labels, meta, technical references

Microcopy Rulebook — Sample of 14 Rules

Rule 03 · Use second-person active voice. The user is the subject, not the object.
❌ Don’t✅ DoWhy
“We use 256-bit AES encryption to protect your sensitive financial data.”“Only you can see this. Even we can’t.”Plain, concrete, recalled verbatim 4× more often. Makes a falsifiable claim — which paradoxically makes it credible.
“We’re tracking your spending so you can make smarter decisions.”“You logged ₹450 today. That’s the third coffee this week.”User as active subject. Specific, neutral, no moral framing.
“Connect your bank to unlock the full ClearPaisa experience.”“You’re set. If you want to link your bank later for auto-tracking, it’s in Settings — no rush.”Surfaces optionality as a feature. “No rush” was cited by 3/5 testers as the moment they felt the app wasn’t pushing them.

Component Anatomy — The Privacy Disclosure

The most reusable artefact in the system: a component that surfaces what data is collected, who can see it, and how to revoke it — at the exact moment of any new data input.

6 Props

data · visibility · reversibility · tone · default · revokeFlow

4 States

default · expanded · revoked · error

Accessibility

Screen-reader order documented per state. Touch target ≥44px. Contrast ≥4.5:1.

06 — Applied Screens

Six screens, including the ones
most fintech case studies skip.

Most case studies show the happy path. The interesting design decisions live in the edge cases — empty states, network failures, account deletion. Each screen below is annotated against the framework dimension it addresses.

Screen 01 — Onboarding, three reversible decisions
01
Onboarding — Three reversible decisions
Disclosure timing · Recovery visibility

No bank, no Aadhaar, no SMS. Each toggle defaults off. The “delete in two taps” anchor sits below the primary CTA — not buried in settings.

Screen 02 — Empty state, Your money diary page one
02
Empty State — “Your money diary, page one”
Language register · Control locus

Frames the absence of data as ownership. No streaks, no guilt — the product respects the user’s pace.

Screen 03 — Manual expense entry
03
Manual Expense Entry — One amount, one tap, one privacy line
Language register · Visual calmness

“Only you can see this entry” appears inline at the moment of input — not in a settings page.

Screen 04 — Network failure, reassurance before action
04
Network Failure — Reassurance before action
Language register · Recovery visibility

Anxiety resolution comes first; retry is secondary. “Your data is safe on this device. Nothing is lost.”

Screen 05 — Settings, Your data
05
Settings → Your Data — Everything we hold. All of it yours.
Recovery visibility · Control locus

Every piece of data the app holds, listed plainly. Each row has a download and delete button. “Delete account” is visible, two taps.

Screen 06 — Bank link opt-in
06
Bank Link (opt-in) — Specific, recent, contextual proof
Social proof layering · Disclosure timing

“412 users from Bengaluru” — not “10,000+ trust us.” Granular toggles: read-only by default, auto-revoke in 30 days.

07 — Validation

What the testing showed —
and what it didn’t.

⚠️ Sample size disclosure. Five moderated remote sessions, 3 days, prototype only. Five sessions cannot prove anything — they surface qualitative signal strong enough to design against and weak enough to falsify in production. Treating directional signal as proof is the most common case-study mistake. I’m not making it.

What the Sessions Surfaced (n=5)

The bank-link absence didn’t feel “broken.”

5/5 completed setup without questioning the missing bank-linking step. Two used the word “respectful.”

The delete anchor was noticed.

3/5 commented unprompted on the visible deletion option in onboarding. Two said it felt “honest.”

Microcopy carried more weight than visuals.

4/5 quoted specific microcopy lines when asked what made the app feel trustworthy. Zero mentioned colour or layout unprompted.

“No rush” was the relaxation moment.

Cited by 3/5 as the moment they “felt like the app wasn’t trying to push them.” Worth A/B testing in production.

Production Validation Plan — What I’d Test Next, with Budget

MethodSampleHypothesisMetric
Unmoderated test (Maze / Lyssna)n=50Onboarding completion ≥75% without bank linkConversion through 3 onboarding screens, time-to-first-expense, SUS score
Trust surveyn=200Higher trust scores correlate with D30 retention6 Likert questions, one per framework dimension, pre/post 7-day use
Beta cohort, real metricsn=500Lower D1 (slower onboarding), materially higher D30 (trust converts to habit)D1 / D7 / D30 retention vs. industry benchmarks
Microcopy A/Bn=10,000“No rush” lifts D14 opt-in for bank linking by 8–12 ppConversion lift on bank-link screen
08 — Trade-offs

What the framework gives up —
and why it’s the right trade.

Every design decision is a trade. The framework optimises for trust accrual and long-horizon retention — which means it gives up things competitors hold dear. Listing them honestly because seniority is judgment, not consensus.

TradeWhat it costsWhy it’s worth it
Speed vs. TrustManual entry is materially slower than auto-sync for the first 30 days.Users who choose manual develop a stronger habit loop; trust gained at week one outweighs convenience lost.
Power vs. ActivationProgressive disclosure delays the 10% who arrive ready to engage deeply.Optimises for the 90% activation problem. A “show me everything” override would dilute the framework’s logic.
Calm vs. UrgencyTeal/amber palette is less attention-grabbing than red/green.Right trade for a daily-use app. The rose accent is reserved exclusively for true urgency — fraud, overdraft.
Insights vs. PrivacyNo bank linking caps insights depth (no merchant-level forecasts).Trade a feature ceiling for a trust ceiling. Trust is the binding constraint in this market.
Brand vs. PatternRestrained visual language — no CRED-like brand silhouette.For a year-zero fintech with no track record, “calm and credible” outperforms “bold and memorable.” Brand is a v2 problem.
09 — At Scale

How this becomes a roadmap
inside a real product org.

The framework is built to outlive the prototype. Inside a real product team — with PMs, engineers, data scientists, compliance — here’s how it ships and gets measured.

Measurement Plan

Each framework dimension maps to a tracked metric in production. The Trust Operating System becomes an instrumented surface, not a design philosophy.

DimensionProduction metricTarget
01 Disclosure timingDrop-off rate per disclosure point<8% per ask
02 Control locus% users keeping manual mode at D60≥40%
03 Language registerVerbatim recall in 5-sec test≥80%
04 Visual calmnessSelf-reported anxiety delta pre/post session≥1 pt drop on 5-pt scale
05 Recovery visibilityTime to find delete-account flow≤15 seconds
06 Social proofConversion lift at decision points≥10 pp with vs. without
The Trust Operating System is sector-agnostic by design. Any product that asks users to share data they cannot reverse benefits from the same six dimensions: healthtech (medical records), insurtech (health and asset disclosures), KYC-heavy banking, AI products that train on user data.
10 — Reflection

What I’d do differently.

Run the diary study before the interviews.

Diary participants surfaced patterns interviewees rationalised away. People know what they say about money apps; they don’t know what they actually do. Diary first, interview second — that’s the order I’d use next time.

Test the framework on a non-finance product earlier.

A framework that only works for one app isn’t a framework. Halfway through, I should have tested the six dimensions against a healthtech onboarding or B2B SaaS data import. That’s the generalisability test, and I deferred it for scope.

Resist the urge to design 12 screens.

The screens are demonstration, not deliverable. The framework, tokens, and microcopy rules carry the value forward. With sharper discipline, I’d cut to 5 screens and spend the saved effort on the framework’s documentation.

Three Things I’m Taking Forward into Every Product I Work On

01
Anxiety mapping comes before user journey mapping.

Where does the user feel exposed, and how do we resolve it?

02
Microcopy is design, not decoration.

It deserves its own test loop.

03
Every system needs a measurement layer.

Frameworks that can’t be instrumented are opinions, not systems.

More Work

See what else I’ve built.