DESIGNING LOANS FOR FIRST-TIME BORROWERS

01 — Context

Two loan products, three lending partners, one architecture

Education loans in India sit at an awkward intersection between first-time borrowers (often students or parents), high emotional stakes, complex eligibility logic, and partner-by-partner variation in what's even being financed.

At Northern Arc, I led the design of a loan application architecture that served two distinct products
1. School loans (where parents borrow on behalf of students)
2. Career upgradation loans (where working professionals or their parents borrow for upskilling) across three lending partners: Upgrad's 180+ course catalog, HCL's 3-course program and Capacita's 4-course program.

The same flow had to feel personal whether you were a parent applying for your child's school admission, a 32-year-old salaried professional upskilling or a student about to start a course they'd repay only after placement.

02 — The Real Problem

Completion is the design problem

HOW MIGHT WE

…help first-time borrowers complete a high-stakes financial application without abandoning at the first sign of complexity?

That question carries two frictions inside it:

One. Eligibility branches based on age and employment: A 20-year-old can't be the primary applicant, an unemployed major has different requirements, and the flow has to handle each path without making any of them feel like an afterthought.

Two. Each lending partner's loan model is structurally different: Repayment, applicant role, document requirements, and field sets all vary so the form can't be static.

03 — Role & Constraints

What I owned, and what was in the way

Role:

Product designer

Timeline:

5 weeks from kickoff to first partner launch (Upgrad), with HCL and Capacita onboarded in subsequent phases

Team:

1 Product Manager · 2 engineers · Compliance Head

Constraints:

Stakeholder alignment shifted multiple times during the project, the journey was revised end-to-end more than once based on partner requirements and internal review. Worked under tight delivery pressure with field-level variation between partners. Mid-project, an insurance provider (CARE) was onboarded into the journey, requiring re-architecting of the later flow stages.

04 — How I Approached It

Three decisions that shaped the architecture

The work came down to two real decisions - applicant logic and partner variability.

Decision 01

Mapping the branching applicant logic

Before designing screens, I mapped the applicant decision tree across two distinct loan products that the team handled under one design system: school loans and career upgradation loans. They sound similar but structurally they're inverses of each other.

In school loans, the parent is the primary applicant and the student is the co-applicant. The parent carries the financial responsibility and the student is the beneficiary. In career upgradation loans, the model flips: if the applicant is an employed major, they are the primary applicant on their own income; if they're unemployed or under 21, the flow pivots to a co-applicant (typically a parent) as the primary borrower, with the original applicant becoming the co-applicant. Same product family but opposite role assignments.

The flow had to handle both cleanly without making confusing the users. I designed it as a single architectural pattern with a role-assignment step early in the journey that determined which person the rest of the flow was speaking to. Once role was assigned, every downstream screen, i.e. basic details, employment, bank and personal details adapted its copy and field set to whoever was actually the primary borrower at that moment.

A high level education loan structure workflow map (as seen below):

Decision 02

Designing the flow to absorb partner variability

Within career upgradation alone, the flow had to serve three lending partners with structurally different loan models:

Upgrad (180+ Courses)

180+ courses, primary applicant is either the working professional themselves or the co-applicant (parent) if the applicant is unemployed or a minor. Standard EMI repayment.

HCL (3 Courses)

Students are the applicants, loan is repaid post-placement once the student begins earning. This shifted the entire conversation around employment and bank details — at application time, the applicant has no income.

Capacita (4 Courses)

Similar post-placement repayment model to HCL but with different field requirements and document types.

Three partners, three different relationships between who is applying and who will pay. If I designed a bespoke flow per partner, the team would be redesigning every time business signed a new lender. Instead, I designed the flow as a modular sequence of field-groups with basic details, employment, bank, co-applicant and repayment terms where each group could be turned on, turned off, or have its content modified per partner without breaking the journey's overall shape. The work here was less about pixels and more about defining a flow contract that engineering and business could plug new partners into.

05 — The CARE Flow

The CARE insurance integration

Mid-project, the business onboarded CARE as an insurance provider, meaning insurance now had to be woven into the loan application itself.

The instinct from stakeholders was to add it to flow while selecting the course but I had a different take on this.

Layering a second financial decision onto users who hadn't yet completed their first one would tank completion. We negotiated to a model where insurance is presented at a moment of commitment after the user has already psychologically committed to the loan, not before.

"The decision wasn't about the insurance product. It was about where in the user's emotional arc a second commitment can land without breaking the first one." Add it too early, and you lose a potential customer. Add it at the right moment, and it becomes an extension of the decision the user has already made.

06 — Outcomes

What shipped, and what the architecture absorbed

The flow shipped to Upgrad first and was extended to HCL and Capacita in subsequent phases. Within the design process itself, the branching applicant logic eliminated three previously redundant screens for under-21 applicants and consolidated the co-applicant journey into the primary flow.

The modular flow architecture has since absorbed partner additions without requiring full redesigns, which was the structural goal. Post-launch funnel performance was tracked by the business analytics team and my direct involvement ended at hand-off and iteration support.

What we observed in internal usability sessions

• First-time borrowers paused at the co-applicant step, the term wasn't familiar without context.

• Course selection felt overwhelming on long catalogs (Upgrad's 180+), so users wanted a search for browsing.

• The moratorium models were difficult to understand and the first-time users did not understand the term moratorium.

07 — What I'd Do Differently

Two lessons, in order of weight

01 Push earlier for moderated testing with real first-time borrowers.

The partner-variability problem (Upgrad vs HCL vs Capacita) absorbed more design cycles than user research did, and that ratio should have been vice-versa. Internal proxies are useful but they don't surface the moments where unfamiliar jargons stop a user, only real first-time borrowers do that.

02 Instrument the funnel during build, not after launch.

I'd work with engineering during the build phase to wire up funnel analytics, so design hypotheses could be validated against real data within the first sprint of release rather than weeks later. Design is faster when it can read its own results.

Want to know more about Education Loan? Check out https://www.northernarc.com/education-loans