Building an enterprise design system from legacy chaos.

Start with tokens, not components.

The fastest way to fake a design system is to build a dozen components and call it done. The system looks finished; nothing underneath actually changed.

I argued for starting with the layer underneath: a single source of truth for color, typography, spacing, radii, and elevation, generated into code rather than hand-maintained in three places at once. The audit had already shown what happens without that discipline — a brand color existing as two different hex values because of one mistyped character, copy-pasted across products for years. One generated token file makes that kind of drift structurally impossible, not just discouraged.

Tokens are unglamorous — you ship them and no screen visibly changes. But once they're in place, every component built after is consistent by construction, and the whole system themes from a single file.

Plan in Figma, build with engineering.

I designed every primitive and pattern atomically in Figma first — the same layered hierarchy the system now enforces in code, just designed before a line of React existed. Working that way meant every component arrived at engineering already validated as a composition of smaller, reusable parts, instead of a one-off screen that needed reverse-engineering into the system later.

I'm a product designer, not a frontend engineer, so standing up the actual codebase — the build pipeline, the token compiler, the linting rules that enforce the architecture — was a partnership. I worked closely with a senior frontend developer to translate the Figma-side atomic structure into a matching layered system in code, where each layer is only allowed to depend on the one below it.

Let evidence pick the variants, not opinion.

Tabs had been reinvented independently across the platform — different products, different frameworks, most with their accessibility semantics stripped out. Rather than inventing a “correct” set of variants, I read every real implementation on the platform and asked what people had actually converged on without ever coordinating. The answer was exactly two visual languages: an underline style and a segmented-pill style. That became the entire Tabs API — not because I decided two was the right number, but because two is what six independent teams had already decided, without knowing it.

Tables got the same treatment at a much larger scale — the single most duplicated pattern on the platform. A dozen-plus hand-rolled implementations became one system built on a proven table engine, and a five-hundred-line hand-rolled table could collapse into a column model and a handful of props.

Accessibility as a default, not a pass.

The easy path is to ship components first and audit them for accessibility later. That path produces patches. The hard path is to make accessibility a condition of shipping.

Every component in the system has keyboard support, focus management, ARIA labels, and contrast-checked tokens baked in at the component level. The system supports both a compact and a comfortable density mode for data-heavy screens, but accessibility isn't a mode — when a density choice and a contrast requirement conflict, accessibility wins, every time.

When an outside architecture review came back with real findings — a legacy stylesheet documentation claimed was removed but was still shipping in every build, a single Escape key closing an entire stack of modals — we treated it exactly like our own internal audits: fix it, log the decision, move on. Getting reviewed by someone else was part of the plan, not a failure of it.

Documentation and adoption over completeness.

Most design system docs tell you what a component looks like and what props it takes. The documentation I pushed for answers a different question: when should you use this component, and when should you not? Every component carries a maturity signal — stable, beta, experimental, deprecated — so nobody has to guess whether it's safe to build on, and every systemic decision gets logged with its context and consequence, so the same argument doesn't happen again next quarter.

A design system that isn't used isn't a design system — it's a Figma file. I prioritized what teams reached for every day — buttons, inputs, modals, tables, form patterns — over exotic components nobody had asked for yet, and stayed close to the teams adopting the system: pairing during implementation, fixing friction fast.