01 · The problem
Leadership knew onboarding was too slow. Nobody had the capacity to take apart why.
The symptom was clear to everyone: signing a new lending client and getting them live took months. The diagnosis was the part that kept getting deferred. The director of design could see the shape of the problem but did not have room to pull it apart and rebuild it. That was the job I was hired into.
Underneath sat a fragmented Figma estate. There was no true design system, only components that had been copied, forked and re-forked across client work until no one could say which version was canonical. The cost surfaced every time anything needed to change: one update meant hunting down every place a component had been reused and editing each instance by hand, which created a backlog on work that should have taken an afternoon.
Every client we signed made that web denser. The company was selling speed, and the design foundation was the thing slowing it down.
02 · Constraints
What made this harder than a normal system rebuild
- Regulatory nuance is not decoration. Requirements shift by loan product and by lender, and the same conceptual step can need materially different UI depending on the product and that lender's compliance posture. That is why the library landed in the hundreds of components rather than the dozens. A tidy, generic system would not have survived contact with the work.
- Nothing could go dark. Three client brands were live, two agent portals were in daily use by call center and servicing staff, and the roadmap kept moving. The rebuild had to happen alongside all of it.
- Two designers, eight developers. Anything that depended on designer availability to scale was not a real solution.
03 · Approach
Three layers, not one component library
I built the foundation as tokens rather than as components. Color, type, spacing, elevation and state live as primitives, then map to semantic roles so a component never references a raw value. Changing what "primary action" means becomes one edit instead of a search across files.
On top of that, each client brand gets its own master Figma library carrying their branding, and a theme file applies it. Component structure and behavior stay identical across brands. Only the theme changes. That is the piece that makes a white label real rather than aspirational: a designer is not rebuilding an application flow for a new client, they are theming one that already exists and adjusting only where that client's products or compliance requirements genuinely differ.
The same structure carried into engineering. Instead of building a client from scratch, developers took the brand design Figma and updated it per brand. QA changed shape too. Rather than testing an entirely new build, they were checking two things: compliance and brand.
04 · The tradeoff
Freezing the three brands we already had
The hardest decision on this project was not a technical one.
When the white label launched we had three existing client brands built the old way. The instinct in the room was to migrate them immediately and retire the legacy files. I argued for the opposite: put the rebuild of those three on hold and spend the capacity on expanding what the white label could actually offer.
Migrating what we had would have made the system look finished. Expanding it made the system worth migrating to.
The cost was real. It meant continuing to maintain the legacy web of Figma files and pushing changes to those three brands individually, by hand, for months. It also meant that for a stretch, our three most visible client experiences did not represent the trajectory of the company or the offerings it could now support.
What it bought was worth more. Those clients stayed up and stable with no disruption to their revenue. Each brand's migration could then be sequenced deliberately on the product roadmap instead of happening all at once. And it gave the PMs and leadership room to scope and pitch each migration as its own piece of work, rather than absorbing it as invisible overhead the design team quietly ate.
05 · Accessibility
A WCAG 2.1 AA audit across web, mobile and agent services
I ran the audit four ways, because each method catches a class of failure the others miss:
- Manual review against the standard, for structural and semantic issues that tools read as passing.
- Automated compliance checkers, to clear the high-volume mechanical failures quickly.
- Screen readers, to hear the gap between what the markup claims and what a user actually gets.
- A friction dashboard I built with Claude and FullStory, to surface friction points that were invisible at an overview scanning level. Session data shows you where people struggle, but it does not tell you which struggles are accessibility failures. Pairing it with the other three methods is what made it useful.
Three findings mattered most:
- Contrast failures on key interactive elements, buttons in particular. The elements users most needed to find were among the hardest to see.
- Images carrying little or no metadata, leaving screen reader users without meaningful context on surfaces where context is the whole point.
- No source of truth. Designers had nothing to check new work against, so inclusive design depended on who happened to know what.
The first two were remediations. The third was the one that would have kept regenerating the first two, so the rebuilt system had to become the source of truth that was missing: accessible defaults carried in the components themselves, so meeting the standard is the default path rather than something each designer has to remember to do.
06 · Outcomes
What changed
Approvals moved faster across the board, and WCAG 2.1 AA was validated across web, mobile and agent services rather than on the consumer surfaces alone.
07 · Retrospective
What I would do differently
I would question the legacy processes earlier.
A lot of the flows and designs that went into the white label were adapted from work originally built for a specific existing client. It was the fastest starting point, and for a while it felt like the responsible one. But a flow that was the right answer for one lender is not automatically the right answer for a system that has to serve many, and several of them were not. We found that out late, which meant reworking flows and retesting them mid-project.
When you generalize something purpose-built, inherited decisions deserve more scrutiny than new ones, not less. They arrive with the credibility of having already shipped, and that is exactly what makes them easy to wave through.