Next-Gen Mobile App for Field Agent Loan Origination (FOS)

Role

UX Designer

Team

4 PM's, 20 Engineers

Duration

6 months

Tools

Figma, Claude Design & Code

Context & Framing

Spandana Spoorty Financial Limited (SSFL) needed a mobile-first Loan Origination System (LOS), used internally by Loan Officers, Branch Managers, and Branch Credit Managers to run the entire assisted loan lifecycle on a phone. Includes lead generation, KYC, application, sanction, disbursement, and ongoing maintenance.

I designed end-to-end. I was in the room for initial requirement-gathering at the client's Hyderabad office, ran the ideation and IA-solutioning workshops that shaped the product, worked directly with Engineering on data mapping and API sequencing to optimize flows, designed the full journeys, and stayed involved through developer handoff, testing, and stakeholder sign-off.

The Problem, Backed by Data

The existing application had broken flows and no user-centered design. Loan Officers had no way to track daily tasks, and most of the process defaulted to offline or manual workarounds, which meant poor record-keeping and inconsistent data.

  • Completing a single loan application took 60–80 minutes by loan officer on the old system.

  • SSFL's annual disbursement had dropped from ₹12,000 crore to ₹4,000 crore a direct consequence of field-level friction slowing branch operations while competitors moved faster.

Research & Discovery

Field research (Jaipur & rural Rajasthan branches):
Field research (Jaipur & rural Rajasthan branches):

I spent two full days living a Loan Officer's and Branch Manager's actual workday — not interviewing them in a conference room, but shadowing them through customer visits, watching how they used the existing app, and seeing firsthand how poor network connectivity in remote areas broke their workflow.

I also held structured discussions with 6 Loan Officers, 2 Branch Managers, and 2 Branch Credit Managers, surfacing recurring themes

Business & operations research (Hyderabad)
Business & operations research (Hyderabad)

Back at the client's business, product, and support teams, I traced the same symptoms to their root causes.

Field-level friction was directly limiting SSFL's ability to expand while competitors scaled faster.

The app was collecting a large number of unnecessary legacy data points, which caused applications to stall or get stuck.

The most striking insight every application generated an average of 4–5 queries back to Quality Check, adding 5–6 hours to completion time. This single bottleneck was significant enough that SSFL maintained a 150+ person support team just to manage it.

Explore

Decision point: Dashboard / landing screen

The dashboard was the single toughest design problem. The primary landing surface for every user role, needing to show multiple live data points and tasks at once without overloading the system or slowing the app down in low-bandwidth areas.

Option A — Product-wise dashboard

Organized around loan products first. Rejected, didn't match how officers actually think about their day (task-first, not product-first)

Option B — Full data load on landing

Every data point loaded immediately on open. Rejected, created heavy system load and slow performance, directly conflicting with the rural-network constraint.

Option C (chosen) — Partial load, progressive fetch:

Critical data loads immediately; secondary data/APIs load on demand as the user interacts. This traded a small amount of extra clicks for dramatically better real-world performance — a deliberate system-friendliness-over-convenience tradeoff.

Decision point: KYC flow

This flow had to satisfy two different constraints simultaneously. RBI's KYC regulations and SSFL's internal document policy.

Full auto-population:

After the first KYC document, the system auto-populates the next required document. Faster, but risked violating RBI's principle that users must have full control over document choice for KYC purposes.

On closer reading of RBI guidance, I found the actual constraint only applies to the first KYC document which the user must have full control there. Subsequent document requirements can be governed by policy logic without breaching KYC intent.

Converge & Decide

The unifying design principle across the app was performance-first UX for low-bandwidth, high-stakes field use.

Auto-save on every click, so a dropped connection never costs a Loan Officer their progress of the work.

Real-time LMS sync. Data stays consistent between the field app and the core SSFL system.

Lightweight UI system. Minimal PNG/SVG usage, illustrations used only when essential, micro-interactions reserved for major components only.

TTF icon fonts instead of image-based (PNG or SVG) icons for the smaller app size, faster load

Every one of these was a direct response to the rural-network reality surfaced in research, this is where "frontend principles" weren't a nice-to-have, they were core to whether the app would work at all in the field.

Cross-Functional Collaboration

The clearest example of real negotiation was the smart search feature. Engineering proposed a 4-step search flow to keep development scope and system load manageable. From my field research, I knew a 4-step search was unrealistic for a Loan Officer who often doesn't know the exact right entry point on the first try — it risked wasted time or dead-end searches.

Rather than simply pushing back

I designed a semi-smart search with filters — users first select a search scope (Customer / Group / Center / Branch / ID), then type within that scope, with smart filters assisting further.

This got the flow down to 2 steps instead of 4 (not the ideal 1, but a real compromise). Respecting engineering's system/time constraints while still meaningfully improving the user experience. Both sides got a flow they could live with.

Visual & System Craft

I built a complete design system from tokens up to 20+ core components and foundational elements, designed and structured in Figma.

To scale this system efficiently across the app's many loan-type flows, I documented the system as a structured reference file and used it as a working skill within Claude Ai so that once I'd designed a component's foundation (e.g., a card layout), I could generate consistent, on-brand variants of it quickly for the many contexts the app needed (different loan types, different data states) without redesigning each one from scratch.

I set the components, tokens, and aesthetic rules, the tool helped scale consistent execution across a large surface area, which mattered given the app spans lead gen through disbursement and maintenance across multiple loan products.

Validation

AI-persona testing (pre-handoff)

Using detailed personas built from my field research, I tested design flows against an AI-driven Loan Officer/Branch Manager persona before handoff. Surfacing an early signal that task completion time could realistically drop from 60+ minutes to roughly 20–35 minutes, along with additional suggestions I triaged and incorporated where feasible.

"Customer Zero" testing

I ran 3–5 test sessions for major module, split between new users (no prior knowledge of the journeys) and my own project team (who already understood the flows), acting as the "customer" in each session myself.

  • New users completed the end-to-end journey in 30–35 minutes, with minor, recoverable errors.

  • Experienced users completed it in ~22 minutes with zero errors — showing a real but manageable learning curve.

UAT Environment

Tested with live API timing against the finalized design, with detailed tickets raised and tracked for every discrepancy found.

Day 1 on live APIs took an unexpectedly long ~2 hours per application. A real-world surprise driven by new-API performance issues, not design. By Day 7, with those issues resolved, real-user completion time on the live product settled at an average of ~30-40 minutes which validating the original design target

Outcome & Impact

As a fully client-owned engagement, specific post-launch business metrics (completion rates, drop-off reduction, branch-vs-digital split) aren't available for external sharing.

~30 min

Application time reduced from 60–80 minutes

30 min

Application time reduced from 60–80 minutes

~40%

reduction in clicks to complete new application

~40%

Reduction in clicks

0 error

Zero-error completion for experienced users,

~40%

Reduction in clicks

Leadership & Influence

I directed a assigned designer through the project by assigning modules, teaching the flow logic, and reviewing every new component or flow against the design system to keep branding and interaction patterns consistent as the app grew across many loan types.

On the stakeholder side, I repeatedly made the case for user-centered decisions to Business, Sales, and leadership. Using persona-driven storytelling to make the Loan Officer's real day-to-day tangible to people who don't sit in branches. This mattered most when a UX-first choice added system load.

Reflection

The tradeoff I'm least fully satisfied with is in the navigation architecture. Ideally, contextual actions (like editing a customer's mobile number, or initiating a re-KYC) should live directly inside the relevant object's own page. The customer detail page, the application page, and so on so the system structure mirrors the user's mental model.

Because of time constraints and the load implications of making every entry point fully dynamic across a large API surface, I had to consolidate these actions into a single, unified menu rather than the ideal distributed architecture. To limit the UX cost of that compromise, I made sure relevant contextual tasks still surface proactively. For example, a pending re-KYC for a customer shows up directly in the Loan Officer's dashboard under pending tasks, rather than requiring them to know it exists and go search for it manually.

With great UX comes great responsibility.