Designing the first borrower portal for people with no U.S. credit file
ROLE
Founding Product Designer
SCOPE
Research, systems architecture, borrower-facing UI
USERS SERVED
2,000+ active borrowers
MARKET
$200B+ expat credit market

OVERVIEW
The assignment
LendKoi builds AI-native credit infrastructure for a market traditional lenders can't underwrite: qualified immigrants with income and repayment history abroad, but no U.S. credit file. Borrowers could already apply for a loan — but once funded, they had no way to manage it. No dashboard, no payment history, no self-service of any kind. Every post-approval question ran through support. As founding designer, I was hired to build that portal from nothing.
The brief was simple: give borrowers a place to manage their loans and understand their risk. What made the work interesting was discovering that the portal's absence wasn't a backlog problem — nobody had yet diagnosed what borrowers actually needed from one.
WHY THIS CASE STUDY
Most case studies redesign something broken. This one is a 0-to-1 build, where the research had to happen without a live product to test — and the real risk was shipping the wrong first version of a pattern the whole company would inherit.
THE PROBLEM
Two problems, one surface
There was no portal to be confusing — that was the point. But two problems made its absence costly, and each demanded a different response.
The user problem

Once funded, borrowers could only check status, confirm a payment, or understand loan terms via automated Sendgrid emails. Unfamiliar terminology and low baseline trust in U.S. institutions meant those questions came from real anxiety, not simple confusion.
The business problem

For an early-stage fintech, trust is the primary conversion lever. Every application drop-off is lost revenue, and every support ticket after funding is a cost with no ceiling as the borrower base grows. Leadership needed the first portal to solve the right layer of that problem, not just look finished.
THE RISK OF GUESSING WRONG
The default reflex for a first release is polish: clean forms, a tidy dashboard, clear labels. Applied without diagnosing what actually drove anxiety and support load, that reflex ships a well-designed portal that solves the wrong problem — permanently, since alpha-stage patterns are hard to unwind later.
RESEARCH METHOD
Turning anecdote into evidence
There was no portal to test, so the research came from the closest real signals available: the live application flow borrowers were already using, and the support tickets generated by everything that happened after it.
I coded Hotjar sessions across the application funnel — landing, eligibility check, application form, document upload, soft credit pull, decision, funding — tagging each by friction type: hesitation, rage clicks, abandonment. In parallel, I taxonomized six months of post-funding support tickets by intent, not just topic. Together they described the shape of a portal that didn't exist yet: where trust broke down pre-funding, and what borrowers needed to self-serve after it.


We segmented by funnel stage: landing, eligibility check, application form, document upload, soft credit pull, decision, funding, repayment. This turned anecdote into signal. Instead of "users seem to struggle here," we could say "38% of sessions show 10+ seconds of hesitation at this specific step."
FINDINGS
Four findings, one shape
Read together, these describe one pattern: borrowers needed proof the system could be trusted, before they had any way to check it themselves.
FINDING 01
Reassurance arrives too late
The application's highest-hesitation moment was the soft credit pull. Copy reassuring users it wouldn't affect their credit score existed — but appeared after the anxiety spike, not before it.
FINDING 02
"Abandonment" was often comparison shopping, not failure
Some drop-off was borrowers leaving to compare LendKoi against other lenders, then returning to convert. But with no save state, returning meant starting over — turning a motivated second visit into a reason to abandon for good.
FINDING 03
No portal meant every question became a ticket
Six months of post-funding support tickets were almost entirely status check-ins: "did this go through," "is my payment confirmed," etc. Borrowers weren't asking for features — they were asking for somewhere to look this up themselves. The strongest signal yet that the first portal's job was visibility, not functionality.
FINDING 04
Not every user is comfortable in English
30+ application sessions showed users manually triggering their browser's translate feature — a workaround for a gap the product hadn't accounted for.
THE CORE INSIGHT
This is a trust-calibration problem, not a usability problem
The obvious brief for a first portal is a usability one: clean dashboard, clear labels, simple forms. That would have been the wrong target. The research pointed elsewhere — borrowers needed trust calibrated at specific moments, not an interface polished everywhere.
Reframed, the question became: what does a first-time U.S. borrower need from this system, structurally, to act with confidence? Three requirements fell out of the research:
The right signal, at the right moment, before a high-stakes decision — not after it.
Confirmation the system is behaving as expected, without having to ask.
Language calibrated to the user's real familiarity with U.S. financial norms, not assumed fluency.
None of these are screen-level fixes — each is a property the whole system needs, everywhere a borrower meets uncertainty. That distinction shaped every decision that followed.
FROM INSIGHT TO SYSTEM
Three reusable patterns, not one dashboard
Since nothing existed yet, every choice became a default for LendKoi's future. A dashboard alone would have solved today's support volume. Three reusable components solve it for every surface LendKoi builds next — servicing, referrals, new loan products — without a new spec each time.

01 Trust-moment component
A pattern for any moment a borrower is about to commit to something unfamiliar: a soft credit check, a fee, an income disclosure. It pairs a plain-language explanation with a direct reassurance signal, sequenced before the action — never after.
Trust-moment component: plain-language explanation + reassurance signal + “what happens next,” positioned before the commit action.
02 Status indicator system





Monthly payment
Scheduled
Jan 11, 2026
$342.50
Late fee
Dec 27, 2025
$15.50
Some status badges
Autopay on
Payment overdue
Resolved
Open
Payment question
One visual language — color, shape, tone — for application, payment, and account status. The bar: a returning borrower knows within two seconds if everything's fine, without reading a sentence. It's the direct answer to the ticket data: return questions are anxiety, not intent, resolved by glanceable confirmation, not more content.
03 Inline comprehension component

Why not a glossary page?
A help center nobody visits doesn't fix comprehension at the moment of decision.
In-flow, not a redirect
Opens in place. User never leaves the screen they were about to commit on.
One reusable component
Drops into any screen with a term and plain definition — no new design spec per term.
Written at a 6th-grade reading level
No assumed fluency in US financial norms.
Comprehension = trust
A user who doesn't understand what they're agreeing to will not agree to it.
CANDIDATES OBSERVED IN RESEARCH
APR · origination fee · soft inquiry · principal balance
A lightweight definition that appears in-flow, right when a term like APR or origination fee shows up — no help page nobody reads. One reusable spec drops into any screen without new design work per term. Comprehension and trust are the same problem: a borrower who doesn't understand what they're agreeing to won't agree to it.
APPLYING THE SYSTEM
Core design moves, prioritized by leverage
With the components defined, the roadmap was a sequencing question: which surface ships the pattern first. I prioritized by where the research showed the highest concentration of anxiety and unmet need.
Priority 1 A status-first dashboard
The first dashboard LendKoi ships needed one job: answer “is everything fine?” at a glance. Payment status, loan details, and transaction details had to lead — ahead of settings, ahead of options, ahead of upsell. This is where the status system does its highest-value work.
The dashboard leads with a single payment CTA. Transaction history and loan details sit below the fold.
Priority 2 — Ensuring timely payments via autopay
Missing a payment is the highest-stakes failure state for a borrower new to the US credit system — it affects the credit history they came to LendKoi to build. Autopay needed to do more than process transactions. It needed to make the consequence of not setting it up feel real, and the act of setting it up feel simple and safe. Every step in the flow was designed to reduce hesitation, not just reduce friction.
Priority 3 — Making payments as easy as possible
A borrower who finds the payment flow confusing will avoid it. A borrower who avoids it misses payments. The make-a-payment flow had one job: get a confident, informed user to the submit button without second-guessing what they were agreeing to. Payment amount, payment method, processing fee, and total due all had to be visible and legible before the authorization checkbox ever appeared.
Priority 4 — Comprehensive support architecture
Support is where trust either recovers or breaks permanently. For a user who is already anxious about their loan status, a confusing support experience compounds the original problem. The support architecture was designed around the questions borrowers actually ask — not the ones the product assumes they will ask — with clear paths to a real person when the answer isn't self-serve.
WHY THIS SCALES
The system is the deliverable, not the screen
Built as components rather than one-off screens, the three patterns compound. Every surface LendKoi builds after this one — new loan products, servicing, referrals — inherits a working answer to how it surfaces uncertainty and risk, instead of re-litigating that question screen by screen once inconsistency is far costlier to fix.
BUSINESS CONNECTION
Each decision maps to a specific result: lower drop-off at the soft-pull step, fewer status-check tickets, faster comprehension at commitment points. For a first release, that traceability is how design earns ownership of product direction, not just visual execution.
What I'd instrument next
A/B the sequencing change (Priority 2) in isolation, to quantify how much of any drop-off improvement comes from timing versus visibility.
Track trust-moment engagement (expand rate, time-to-continue) as a leading indicator — it moves weeks before funnel metrics do.
Turn the browser-translate workaround into first-class language selection; borrowers already told us what they needed.
Set a threshold for when a term auto-qualifies for an inline definition, so the component scales without a manual audit per product.
KEY TAKEAWAYS
What this project reinforced
Trust is a design surface, not a feeling
Moving one reassurance signal earlier in the application flow mattered more than any dashboard polish. Trust isn't built by looking credible — it's built by giving borrowers the right information at the moment they need to act on it.
The biggest problem wasn't a bad screen — there wasn't one yet
It was emotional hesitation at moments of commitment, and a support queue standing in for a product that didn't exist. Finding that required coding sessions and tickets as data, not anecdote, and asking why, not just where.
Alpha stage is when foundational patterns get set
Building the first version of anything makes every decision a precedent. Getting the trust patterns right before they calcified was the highest-leverage work available — and it meant operating without a brief, close to engineering, deciding what needed to be true before deciding how it should look.
Design decisions should connect to business outcomes
Every decision tied to a specific behavior change and business result — fewer tickets about a named confusion, lower drop-off at a named step — not a better experience in the abstract. That's how design earns ownership at a company shipping its first product.