86% of Lendee's investors are American men between 30 and 55. It lets people invest money into two categories: Account Receivables (investors buy discounted invoices from vetted businesses and earn the margin when they're paid back) and Peer Microfunding (investors fund individuals directly, with any fee left entirely up to them).

This entire project started with the app's poor performance. The PM had already benchmarked me against published fintech investing research: even a year after launch, activation and repeat funding were both stuck well below where that research put industry norms.

Three signals pointed three different places before one of them held.

I used Claude to cluster the raw observations from both homes side by side, so I could read all seven at once instead of home by home. Two explanations covered most of them. A third explained what those two kept leaving out.

That leaves two findings neither frame can reach. 6/8 didn't find the activity feed convincing, and only 2/8 found the overdue messaging reassuring. Nobody misunderstood those screens, and nobody failed to find them. They read them correctly and still didn't believe them.

These three principles are the summary of everything the research found. Even so, I slipped on the first one, and testing caught it later.

Structuring both homes came down to the same three questions: does it earn trust or spend it, does it belong on this screen at all, and what order it belongs in, shown here as a diagram, not the original files. The structure kept changing as new challenges came up. This section shows the structuring itself. The sections that follow explain why each choice was made, and the approaches I tried that got rejected.

The first-time home has one job: turn a new user into an informed first investment. The old screen optimized for the opposite: pressure over understanding.

For a returning investor, the home has to answer important money-related questions without confusion. The old home didn't answer either of them directly, and buried what it did show in data that wasn't easy to understand.

Lendee's referral program isn't well engineered yet: the reward is stated as a flat cash amount with no real explanation behind it, in practice, just an extra dollar sitting in the wallet. Surfacing it prominently on a home built around trust felt premature to me.

• The PM held firm that a Refer & Earn nudge needed to be in front view for the growth loop it drives, regardless of the program's maturity, so it shipped there.

I understand production data alone can't isolate every factor behind a shift like this, seasonality or marketing could play a part, but the usability testing earlier already tied the behavior directly to the redesign itself.

Both numbers are still under industry benchmark: 5.0% against 8-12% for activation, 29% against 40%+ for repeat funding. Two months is early, but there's another thing to improve after the home fixes: the detail pages of both categories, where 67% on Account Receivables and 53% on Peer Microfunding never continued to fund after opening one.

In a major redesign like this, I'd get the first version of a risky direction in front of users as early as possible, accepting going in that it won't be close to final and will draw a lot of feedback. That's exactly what was missing when the stepper direction only got tested after the full redesign was done, costing two more weeks.

Denefits is the platform a healthcare business uses to put its own customers on a payment plan, so they can pay for treatment over time instead of all at once. It has two sides: the business side, where plans are created, managed, and money is watched arriving, and the customer side, where a customer checks what they owe and what's due next. Each side ships as both a mobile app and a web panel, so the system has four surfaces to hold together, not one.

That was the brief. Not make it prettier, but make it a system two very different readers could follow the same way: a designer picking a token, and an agent parsing the rules as context.

Everything else, spacing, typography discipline, components, and how any of it should actually be used, was mine to define.

I worked alongside Claude, connected directly to Figma through an MCP server, which gave it live read and write access to the file.

It is genuinely capable at the repetitive, fixed parts of this project, and that is the big part of it. Work like this, done properly, at this scale, usually takes a small team months. Directing the agent instead of doing it by hand is what got it done solo, in under a month.

There was already a design system, in name. A colour palette existed. A type scale existed. Spacing tokens and components did not exist at all.

The first thing I put the agent on was the audit, to find out how far the file had actually drifted. Generated rather than eyeballed, and the numbers it came back with were the true starting point.

Even the parts that did exist were not being followed, because nothing said how to use them. There was no written guidance for a designer, and over years of different people touching the same file, the palette and the type scale were broken in more and more places, until the design system was closer to a memory than a constraint. And following it wouldn't have saved anyone: the palette itself carried a defect nobody had measured, so a designer who used it correctly still ended up with an inconsistent result.

None of this runs on taste. All five of them governed the entire process, and every one of them bound the agent exactly as hard as it bound me.

Colour is the foundation the rest of the system stands on. It has to land before anything built on top of it can make sense, and it is the only layer dark mode actually needs.

A typeface is the one foundation a user reads every second they're on the screen, and the only one that can quietly make a product feel wrong without anybody being able to say why. Pick it on the thing your product actually does, and it stops being decoration.

Getting these wrong makes the entire product cluttered and hard to scan, which nobody wants.

Pick a library first and the spec just gets reverse-engineered from whatever arrived. So I wrote the rules first, proved them against eight icons drawn to stress the spec, and only then let a real library take the test.

Every property below, fill, ink, border, height, padding, radius and the icon it carries, resolves to a token already declared in the semantic layer built earlier in this case study. Nothing here invents a value; the component only asks the layer beneath it to answer.

Six deep dives is already a lot to ask of a reader. These six aren't walked through, and every one went through the same cycle as the ones that were: build, measure against a gate, publish a dated certification.

None of this is a finished set, and it isn't meant to be. The system is built to scale on purpose: every foundation and every component is its own page with its own gate and its own date, so whatever the product asks for next, more components, a density mode, a second brand, a real motion spec, arrives as another page rather than a rebuild of what's already there.

Colour was tested against colour. Typography against typography. Spacing against spacing. Every one of those checks is the system marking its own homework, and a gate that only ever tests one thing at a time can't see what happens when five of them share a screen. So the last test ran the system against real, existing Denefits screens.

Screens are the only consumer that asks for things a component never will. When the icon set was chosen, the demand was read off these real screens rather than from a list of popular icons, and five icons exist only because they asked for them: Signature, Bank, ArrowUpRight, ArrowDownRight and Retry. None was in the first draft.

A system nobody can read is a system of one. Everything above is worth nothing the moment a new designer or an AI agent has to work inside it and can't find out how it was built, how it behaves, or what breaks if they change something. Documentation isn't the write-up at the end; it's the part that makes the rest usable.

Part II is the one that matters most now that the system isn't mine alone to touch. Another designer, an engineer or QA can propose a change; the standard for accepting it is the same one the audit itself runs on: a token has to earn its place, or it doesn't get added.

They all were built first, then removed. That's the part I'd point at. Deleting your own finished work is harder than not starting it, and it's the only way a scale stays honest.

This system was built, certified, and then handed off. The business side's Collections view is the first surface built entirely from it by someone other than me, with more queued as each surface comes up for its own update. It shows what disappeared, and what replaced it: how much a designer or an agent had to choose, guess or ask about before, and how little now.

In a system like this, I'd schedule a full re-audit after every foundation and component ships, not assume the rules hold on their own. That's exactly what was missing when a certified button shipped with an icon toggle wired to nothing, passing every gate for weeks before anyone actually tried using it.