IndusInd Bank — INDIE

Shortening complex banking flows into few-step, error-proof journeys. A UX overhaul that streamlined high-friction workflows into clear, guided steps — for both customers and internal users.

6 min read 2024
RoleProduct Designer · Customer-facing flows + design system support
BrandINDIE — IndusInd Bank's customer banking experience
Team2 designers (system) · 6 designers (consumers) · ~40 engineers
SurfacesCustomer mobile · web banking · internal staff tools
DomainBanking · Mobile + Web · Multi-platform
StackFigma, Tokens Studio, Style Dictionary, Storybook, GitHub Actions

TL;DR

  • Compressed high-friction banking flows (account opening, business loan applications, cross-currency transfers) into few-step, error-proof journeys by collapsing decisions and pre-filling state.
  • Built and rolled out a unified design system underneath — same tokens, same components — across customer mobile, web, and internal staff tools.
  • Component reuse hit ~85% across surfaces. Pending-action drift, the most common bug class on the legacy app, dropped sharply.

The friction audit

IndusInd's customer experience had years of organic feature growth. Mobile and web had drifted apart. The same "transfer money" flow looked, behaved, and was named three different ways across surfaces. But cosmetic inconsistency wasn't the urgent problem — flow length was.

The audit method was uncomfortably simple: pick the 12 most-used flows, walk through each one in the legacy app, count every decision a customer had to make. Not every screen — every decision. A screen with a single "Continue" button is one decision. A screen with three radio options and four input fields is five decisions.

What we found:

  • Apply for Business Loan: 14 decisions across 9 screens. Half of those decisions were re-asking for KYC data the bank already had.
  • Cross-currency transfer: 11 decisions across 6 screens. Three of them were technical jargon (correspondent bank, charge bearer, swift code) the customer couldn't possibly know.
  • EMI prepayment: 8 decisions, but worse — 3 of them were trick questions. If you picked "partial prepayment," you had to fill three more fields. If you picked "full," none. The path mattered.

The reframe: stop redesigning screens. Redesign decisions. Every flow audit started with the same question — "what's the minimum number of decisions a customer should make to complete this?" — and worked backward from there.

Step reduction · worked example

The headline win: Apply for Business Loan went from 14 decisions to 6. Same regulatory shell, same disclosures, same outcome — fewer decisions because most of them weren't decisions, they were data the bank already had.

Before
14
  1. Pick loan type
  2. Re-enter PAN
  3. Re-enter Aadhaar
  4. Re-confirm address
  5. Re-enter business name
  6. Pick GST type
  7. Enter GST number
  8. Re-enter date of incorporation
  9. Pick business category
  10. Enter loan amount
  11. Pick tenure
  12. Pick repayment mode
  13. Upload P&L
  14. Confirm + submit
After
6
  1. Pick loan type
  2. Confirm pre-filled KYC + business details (one screen, all chips)
  3. Enter loan amount + tenure (live EMI shown)
  4. Pick repayment mode (3 chips, smart default)
  5. Upload P&L (auto-detected from connected accounts where possible)
  6. Review & submit

The seven decisions that disappeared weren't simplified — they were moved off the customer's plate entirely. KYC re-entry, address re-confirm, GST/business details — all data the bank already had. We replaced the input fields with confirmation chips: "Use this PAN" / "Use this address." Customer taps once instead of typing.

"Needs your attention"

The home dashboard was where most customer journeys started — and where most of them got stuck. Pending approvals piled up because customers didn't know they were pending. Incomplete loan applications timed out because no one nudged the customer back. EMIs went into arrears because the reminder lived in email, not in the app.

The "Needs your attention" strip is a single home-dashboard primitive that surfaces exactly what blocks the customer's progress. It has three rules:

  • Action-led, not status-led. Not "Loan application status: 50% complete." Instead: "Continue your business loan — 4 fields left."
  • One-tap to resolve. Tapping the chip lands the customer exactly on the field that needs them — not on the start of the form.
  • Quiet when there's nothing. If nothing needs attention, the strip disappears. No "All caught up!" trophy. The empty state is silence.

The strip caught items that would have otherwise gone to call-center or branch. Pending-action drift — the most common bug class on the legacy app — dropped sharply in the first release cycle.

Pre-fill + smart defaults

The path-of-least-thinking is fewer steps with smart defaults — not more steps with hand-holding. Three patterns we ran across every flow:

  • Confirmation chips, not input fields. Where data exists (KYC, address, account number, beneficiary), present it as a chip the customer taps to confirm — not as a blank field they re-type. The path is "Use this" or "Change."
  • Smart defaults that match the customer's history. If 8 of the customer's last 10 transfers were to the same beneficiary, it's the default. If they always pay rent on the 1st, that's pre-selected.
  • Live computation, not "Continue." Loan EMI updates as the customer changes amount or tenure — visible on the same screen. No "click Calculate" button. The number moves with the input.

Killed: a "wizard mode" with separate step-by-step screens for every complex flow. Tested with users — felt patronising on simple steps, confusing on complex ones. Replaced with progressive disclosure inside one continuous frame.

System foundation

INDIE shipped on top of a unified design system — semantic tokens, ~120 components, mobile + web from the same library. The system is the means; the flow simplification is the headline. Brief mention because some things deserve their own case study (more on this in the Torrent Design System page, where the system is the headline).

One detail that mattered: tokens flow from Tokens Studio (Figma) → Style Dictionary (CI/CD) → platform outputs (CSS variables, XML, JSON). Designers change a token; engineering picks up the diff in a PR. Component reuse hit ~85% across mobile + web.

The AI Figma plugins I now use across PwC engagements (Validator, CLAUDE.md Exporter, Generator) were all born on this engagement — built because manual review across 6 consumer designers wasn't scaling.

Trade-offs

Killing the wizard-mode meant some genuinely complex flows now ask customers to think a little more in a single step. We accepted it — the path-of-least-thinking is fewer steps with smart defaults, not more steps with hand-holding.

Pre-fill works only when the data is right. We invested in a "this looks wrong, let me change it" affordance on every chip — but the first month had a small spike in support tickets when stale KYC data surfaced incorrectly. Worth it; the volume dropped sharply once data quality improved.

Outcome

~85%
Component reuse across mobile + web
↓ Sharp
Drop in pending-action drift (the legacy bug class)
↓ Steps
High-friction flows compressed (e.g., 14 → 6 steps for business loan)
3
AI Figma plugins built and shipped from this engagement

The clearest outcome isn't on the metric tiles: the system survives without me. Designers who've never met me are shipping inside it. That's the bar.

What I'd change

I'd have written the governance doc on day one, not month three. We had drift across the team's outputs until we sat down and articulated "what counts as a system decision vs. a vertical decision." Cost us ~2 weeks of consolidation. The doc itself is six bullet points; writing it earlier would have been free.

And: I'd have invested in contribution tooling (PR templates, automated changelogs, contribution rituals) sooner. We did them in month four. Done at month one, the contribution velocity would have been double.