A design system as product infrastructure

A design system fails in one of two ways. It’s too thin to be trusted, so people work around it. Or it’s too rigid to absorb new products, so it ages into a constraint everyone resents. Building one that avoids both — across a growing multi-product ecosystem, as the sole designer for the first stretch — is the work I’m proudest of.

V1: earning trust before enforcing it

When I built the first version, the region had very few mature systems to learn from. The temptation was to over-engineer. I didn’t. V1’s job was adoption, not completeness. It had to be good enough that designers and engineers reached for it instinctively, and humble enough that it didn’t break when the product line widened.

It worked because it was treated as a product with users — its users were my own team and engineering — and like any product, it had to earn its adoption rather than mandate it.

The decision point: extend or rebuild

As the ecosystem grew from one product toward a full lifecycle of them, V1 started showing its seams. The honest call — and it’s an uncomfortable one to make about your own work — was that incremental patching would produce a system that technically covered everything and helped with nothing.

So V2 was a rebuild on a different foundation:

• Tokens and variables as the source of truth, so theming and multi-product variation are properties of the system rather than exceptions to it.
• Accessibility built in, not audited in — a near-complete WCAG-aligned color and contrast model, so the right choice is the default choice.
• Broad, real coverage — the components teams actually need, at the fidelity they actually need, maintained as the product surface grows.
• AI-integrated workflows layered on the system’s structure, which is only possible because the structure is consistent enough for AI to operate against reliably.

A system isn’t mature when it’s comprehensive. It’s mature when the easiest path and the correct path are the same path.

Governance without bureaucracy

The hardest part of a system at this scale isn’t the components — it’s keeping it coherent while more than one person contributes and the product keeps moving. I run this through weekly design critique and clear ownership, not a heavy approval process. The bar is held in conversation and in the system’s defaults, which is more durable than a gate.

Honest scope

The system is mature and collaboratively maintained now — but its foundation, its craft bar, and the harder calls are mine to own. The one that actually matters: knowing when to extend the system and when to rebuild it. Most systems decay because no one is willing to make the second call. I’ve made it, deliberately, and the system is better for it.