Designing a Loan Origination System that configures itself
CredAble's Loan Origination System looked like one product, but behaved like a new one every time a client signed on. I redesigned it as a configurable platform - cutting client onboarding from 4–8 weeks to under 2, and removing design and engineering from the critical path.
TEAM
1 Designer, 2 Engineer, 1 PM
ROLE
I owned the full design scope - from reframing the problem to shipping patterns across configuration, program management, authentication, and theming. I worked closely with product and engineering to focus design effort where it could scale, instead of solving the same problem again.
PROBLEM
The real problem was scalability
The brief came in as a UX redesign. The actual problem was a scalability failure.
Each client onboarding meant rebuilding from scratch - new flows, new configurations, new design decisions, every time. The system had no shared language between deployments. I reframed the goal: instead of designing screens for every client requirement, we needed a modular UX system that could be configured, not recreated.
That shift - from designing outputs to designing the system that produces outputs - became the foundation for everything that followed.
RESEARCH
Light research, sharp findings
I ran a heuristic review of the existing flow, used the feedback the team already had, and studied similar onboarding patterns to see how others handled government verification.
GST HAND-OFF WAS THE BIGGEST DROP-OFF POINT
Leaving the app to approve details on the government portal created the most confusion in the flow.
Content was adding noise, not clarity
The same information appeared across screens, which increased reading without helping users move forward.
The design needed to work across brands
The flow had to stay flexible for different partner brands, not just look good in one visual style.
The flow wasn't broken in any one obvious place. It was broken in the accumulation of small, unexamined decisions.
DESIGN EXPLORATION
01.
MODULE GENERATOR - BUILDING IT OURSELVES, THEN CHOOSING NOT TO
Problem: Configuring a loan program needed conditional logic and flexible form sections, but nothing off-the-shelf fully matched how CredAble’s programs worked.
What I designed: I first designed a custom module generator built around conditional forms. After reviewing it with the team, we made the harder call: building our own would add complexity and maintenance cost without enough product value.
02.
A CENTRALISED LAYER FOR LOAN PROGRAMS
Problem: Every client’s loan program was being hardcoded as a one-off flow, with no shared structure or reuse across clients.
What I designed: designed a Master Configuration layer where programs could be assembled from reusable components and structured settings instead of custom builds. Selecting a loan program surfaced its full settings, so internal teams could manage variation without starting a new design sprint each time.
03.
FASTER PROGRAM MANAGEMENT
Problem: The existing program management interface was too rigid for daily ops work like scanning data, editing programs, and finding the right columns quickly.
What I designed: I designed a dedicated program management page with customisable, reorderable table columns and faster edit access, so teams could shape the interface around how they worked.
What changed: Daily program management became lighter, faster, and less dependent on unnecessary navigation.
04.
SCALABLE THEME SYSTEM
Problem: White-labelled deployments meant manually adjusting visuals for every client. My first theme system was detailed, but too complex for daily use.
What I designed: I simplified it into a single-colour system: one primary colour generates the full tonal palette and applies it across all UI components.
Single primary colour → auto-generated palette → full UI coverage
05.
MODULE SELECTION - FROM CONFIGURATION TO ASSEMBLY
Problem: Selecting modules for a new program meant moving through static configuration screens, which made setup slower than it needed to be.
What I designed: I designed a drag-and-drop model where users could add, remove, and organise modules directly, with quick actions to create a new module when needed.
06.
ONE ENTRY EXPERIENCE FOR EVERY DEPLOYMENT
Problem: Sign-in and sign-up had to support borrowers, internal teams, and partners without becoming three separate experiences.
What I designed: I redesigned auth as one unified system across all user types. We chose a centre-aligned layout because it adapts better across client brands and leaves a clean foundation for a future AI chatbot.
IMPACT
Less dependency, faster client launches
The redesign turned LOS from a manually customised product into a configurable platform. New clients could be onboarded faster, engineering dependency dropped, and design effort shifted from one-off client work to the system itself.
~75%
Reduction in client onboarding time
~60%
Less repetitive configuration effort
~70%
Fewer theming hours per client
Onboarding time
From 4–8 weeks reduce to ~1–2 weeks
Configuration effort
~60% reduction in repetitive work
Theming per client
~70% less branding effort
Reflections
SCALABILITY MEANS FEWER DECISIONS
The biggest wins weren’t visual. They came from structure - choosing patterns that could scale across clients instead of restarting with every new setup.
NOT BUILDING WAS THE BETTER BUILD DECISION
Exploring a custom module generator helped me understand the problem, but the third-party engine solved the hard part better. The stronger decision was to focus our effort on the UX layer around it.
COMPLEXITY HAS TO EARN ITS PLACE
My first theme system was more powerful, but power wasn’t the real need. The simpler single-colour model worked better because it matched actual use.
WHAT I’D DO DIFFERENTLY
I’d bring engineering into the module-generator decision earlier. We spent design effort on a custom flow before the maintenance cost became clear — a conversation that should have happened sooner.