Enterprise lending with real variation.

A loan application journey collects and verifies the following information

• The intent and specifics of borrowing
• The identity of the borrower
• Credit worthiness check (collaterals, co-applicants/guarantors, financials)
• Repayment promise and details

These vary based on earning profiles (salaried, self employed, business, etc.), loan type (secured, unsecured, etc.), lender’s schemes and their credit policies.

Among the clients Biz2X had, the solutions were custom-made out of previous implementations. The next customer’s need was “frankensteined” from forked modules.

Custom journeys were slowing scale and had a weak self-serve completion.

The scaling problem

In practice, Biz2X reused parts of the product but still heavily modified the application journey for each lender. The count of implementation was combinatorial: loan types × program types × client-specific requirements.

That created four issues:

• Design effort went into client-specific rework instead of net-new product problems.
• Engineering kept modifying similar functionality and carrying that maintenance overhead across related streams.
• Sales lacked strong guardrails around what was configurable versus custom.
• New requirements did not consistently strengthen the shared product.

Onboarding a lender to UAT typically took 2–3 months (for a single loan product type), and a large part of that time went into journey alignment, UI revisions, and repeated implementation changes.

Usability gaps

The existing journey also had usability gaps: Weak linear navigation (Next and back)Poor status visibility, and low reassurance, made self-serve completion s tale of drop-offs, especially in longer applications. Clients relied on field agents and in-office teams to complete journeys, adding operational cost. In practice, the customer-facing experience often worked more as a lead-generation layer than a true self-serve application flow.

Three journey types appeared predominantly, but all followed one common structure

To understand whether these journeys were fundamentally different or just differently expressed, I mapped six of the most varied live journeys side by side.

I compared flow order, KYC logic, product-specific requirements, verification methods, and post-eligibility complexity. PMs and credit specialists pressure-tested the pattern with edge cases. The engineering lead pushed on feasibility and surfaced weak spots. Sales grounded the solution in something clients could actually buy into.

A clear pattern emerged: the journeys were different in detail, but not in shape. I identified these three themes:.

• Pre-eligibility: Intent and identity of the borrower
• Eligibility: Credit limit, rate, and duration
• Post-eligibility: Credit-worthiness document, verification, repayment details

Next, a robust framework was required that would allow configuration, satisfying all scenarios.

All possibilities of variations segregated within themes.

I defined the following for each theme to enforce guardrail that ensured a robust journey:

• What it is for (purpose)
• What can change (configured)
• What drives those choices

We now had a framework that could lay out a high-level journey to fulfill a diverse range of client's requirement. But, the real outcome is a UI that is closely tied to this configurable framework.

Pre-eligibility should be quick and snappy, post‑eligibility should have structure and control

Linear navigation: Allow the user to complete the step and move forward. Go back when required. Best for 5-6 single-action steps.

Hub-and-spoke navigation: The user navigates from a central index page to their destination and comes back. Best for multi-action steps (more than 5).

We had a strong guiding principle from the framework.

On pre-eligibility steps, users were still deciding whether to continue, so the design had to reduce hesitation and build momentum. Pre-eligibility had to be short and snappy.

This directly addressed the part of the journey where assisted completion and drop-offs were most visible.

---

The later part behaved differently. Once users reached post-eligibility, the application stopped behaving like a simple form and started behaving like a task system, with multiple collaterals, multiple co-applicants, parallel verification flows, bank linking, and repeated back-and-forth across sessions and actors. Post-eligibility had to offer complete control, visibility, and flexibility.

I shifted to a more task-oriented model with stronger status visibility, so users could manage multiple entities, dependent tasks, and re-entry without losing orientation.

Turn the journey model into a platform capability.

Beyond the configuration of picking and ordering the steps for pre-eligibility and post-eligibility, verification and data storing methods were also configurable.

Here's an example of how PAN verification variations existed

Faster onboarding, higher completion, lower design dependency.

• Reduced lender onboarding to UAT by 60%, from a typical 2–3 month cycle.
• Improved application completion by 3× in the first implementation, benchmarked against other live implementations over a 3-week period.
• Reduced repeated design dependency for new implementations.
• Improved consistency and maintainability across journeys.

For a platform used by major financial institutions and built to support end-to-end lending operations, these improvements matter beyond a single flow. Faster onboarding means new programs can move into implementation with less bespoke effort; stronger completion means more of the borrower journey can stay self-serve instead of falling back to assisted operations.

Measurement note: onboarding time refers to bringing a lender onto the platform through UAT. Completion improvement was benchmarked against other live implementations during the first rollout window.

Platform design starts with the right boundary.

This project taught me that the biggest UX win in enterprise products is often not a better screen, but a better boundary: what should stay fixed, what should vary, and what should remain light customization.

That is what turned repeated custom work into a scalable platform capability.