Five design systems, five different answers

The constraint. Enormous data density, and a client who needed the product to look modern and striking rather than like a spreadsheet with ambitions.

The answer. An extremely tight system that used relatively heavy contrast between elements to hold structure. Contrast did the work that whitespace usually does, so views could stay dense without turning into an undifferentiated grid.

What it taught me. Density and visual quality are not opposed. They're opposed if you only have spacing to separate things with.

The constraint. The product generated simulations, and those simulations were the reason anyone opened it. The interface around them had to feel clinical and stay out of the way.

The answer. A deliberately recessive system. We also tuned the simulation visuals to sit inside the design language rather than beside it, but always so the simulation held the view.

What it taught me. Sometimes a design system's job is to be unnoticeable. That's harder than making one that announces itself, and it's a different success criterion entirely.

The constraint. An AI-driven customer communications analytics product, dashboard-heavy, where most of the real design problem was data visualisation rather than layout.

The answer. Built on Material UI, with the majority of the system work going into visualisation patterns: how findings are represented, compared, and made scannable at different levels of detail.

What it taught me. In a data product, the visualisation patterns are the design system. Buttons and forms are the easy part.

The constraint. A 1000-person company, around 12 core products, and no shared system. I built the company's first.

The answer. Getting it resourced took two arguments. For the business: our rarely-used specialist tools looking as good as our flagships would say something real about us, that nothing here is treated as trivial. For engineering: the system removed pixel-level round trips they disliked, and let them push their own ideas without booking a designer first, because anything they built would look credible enough to show a PO immediately.

What happened. Adopted across all new products, and still in place a decade later.

What it taught me. Adoption is a separate discipline from construction, and the arguments that work are the ones aimed at what each group already wants.

The constraint. Users migrating from legacy systems where a spare white pixel was considered waste, a React MUI front end, and AI tooling that needed to produce shippable work rather than plausible-looking work.

The answer. Built on Material UI, customised heavily. Spacing tightened toward efficiency without losing legibility — a decision I've had to justify more than once. MUI's two-colour model overloaded to carry three, adding brand alongside primary and secondary. Dynamic components for core entities: a vehicle, customer or trade case renders by context, from full focus page down to cards, list rows and dropdown items, so one entity has one definition across every surface.

And the system exists twice: an annotated Figma library, and a machine-readable version that Claude Design and Claude Code build against directly, with skills mapping it to the front-end component library.

What it taught me. Once the system is machine-readable, the tools change places. Figma stopped being where I explore and became where decisions are documented and versioned. Exploration happens through AI-assisted channels; Figma holds the resolved outcome.