When I joined in August 2025, there was no design system and no component audit. The need was understood, but the reality was scattered Figma files, components that duplicated each other, interfaces that broke often, accessibility that did not meet WCAG, and a web product that was not responsive.

The cost was not aesthetics. Every team was rebuilding the same interface parts by hand, each slightly differently, with no shared source to pull from. Inconsistency slowed handoff, and the accessibility gaps were a standing risk, not a polish item. The platform needed a system before it needed better screens.

I architected the system, its token structure, contribution model, and quality gates, and I design the components. Governance of the library is shared: the Product Design Lead co-owns it and owns the Storybook product. I design in Figma and submit pull requests to Storybook to update documentation; developers implement the component in code.

The inventory made the pattern impossible to miss: the same job was being solved many times over, inconsistently, with accessibility failing across the board. Some parts carried hardcoded styles rather than tokens (bg white, padding 4px 14px, font black), which is why nothing stayed consistent as the product grew.

A clear example was 13 separate dropdown components, some near-duplicates, some overrides of each other, none passing the accessibility check. That single pattern showed what the whole system was doing at scale, and it is the kind of finding the audit surfaced repeatedly across categories.

Three decisions in the architecture. Each one shows the choice, the alternative, and the tradeoff I accepted. These are the calls that make the system hold together as it grows.

Components then sit in one of three tiers: Native, the platform component themed with Redzone foundations; Hybrid, a native component modified to add Redzone behavior; and Custom, built from scratch. I keep each component in the lowest tier it can live in, because every step up costs maintenance across three platforms. Native where it works, custom only where the experience demands it.

The tokens make this executable rather than aspirational. They are platform-agnostic by construction and exported per platform, so the same decision resolves natively on each one.

Foundations. Colors, typography, spacing and grids, elevations, motion, content, logo and iconography.

Token architecture. Two layers. A global layer holds the full palette and the raw scales, every value the system could use. A semantic layer names each token by its role in the interface, so a component consumes intent rather than a raw value.

The naming convention carries the logic: foundation / property / category, then an intensity level, with optional levels only where they earn their place. property is the thing being set (background, text, border, height, padding). The category is the load-bearing part. It groups tokens by use (control, field, selection, container, surface) and it is what decides which components are density-aware and how they respond to dark mode. A control reacts to density; a container does not. That behavior is set once at the category level, not component by component.

The intensity level is named for what it controls: scale for dimensions, a scale ramp from xs to 2xl, and emphasis for color, a prominence ramp from subtlest to bold.

Color runs on three axes that never collapse into each other. Emphasis answers how visible something is (color / background / control / bold). State answers what the user is doing, default, hover, active, disabled, and only interactive categories carry it. Feedback answers what the system is telling you, and it sits on its own path, color / text / feedback / error, separate from the prominence ramp. A component can be bold, hovered, and in an error state at once without the three fighting each other.

The token pipeline. Tokens live in Tokens Studio as the single source of truth, structured to export cleanly into Style Dictionary, which generates the platform-specific outputs. That is what makes one token definition usable on web, Android, and iOS without maintaining three parallel sets by hand. The source of truth sits in design, not in any one platform’s implementation.

A component graduates to Version 2 in Figma when it consumes only tokens and styles, responds to density modes, has complete states, is documented, passes the accessibility checks measurable in Figma, and has been tested. It graduates to stable in Storybook when its CSS properties, states, token alignment, accessibility, and props are audited on the published component. A component can be Version 2 in Figma and not yet exist in code. The two gates are parallel by design, not a single ladder.

Documentation. I built the Storybook documentation template the whole system uses: Usage, Code, Accessibility, Specs, Resources, and Changelog, with a status badge on each component.

So I automated it. Using Figma MCPto read the component’s source spec and Playwright MCP to read computed styles from the live story inside the Storybook preview iframe, I generate a property-by-property parity report per component. Values are normalized to one format before comparing, so a hex and an rgb of the same color are not counted as a difference.

The report covers three layers:

For example on the Split Button, the audit returned 16 of 18 properties in parity on the default state, and all six state variants matched on background, text, and border gradient. Two deviations: a missing 48px minimum width on the leading button, and a trailing button rendering 1px over its 32px spec.

The finding that mattered was neither of those. Six of twelve properties resolved to the correct value under a different token name. Figma’s size/CTA/md against a coded --global-typography-font-size-text-md. Figma’s height/control/md against --split-btn-height, a component-scoped variable rather than a system token.

The values were faithful. The taxonomy had diverged. That is the class of drift a visual review cannot catch: the component looks correct, so it passes, and the divergence compounds silently until a token change stops propagating to the place it should reach. Automating the comparison is what makes it visible.

From zero, in 11 months:

The system is now the single source that the product design team, four product modules, three platforms, and ChampionAI’s design team build from. That last one matters: the library is consumed by the team building Redzone’s agentic product, so the system already serves an AI-native surface as a first-class consumer.

I measure two different things and it is worth separating them. Adoption is measured on the design side through Figma Analytics: insertion rates tell me which components get used, and detach rates flag which ones are not covering a real need. Conformance on the code side is measured through the MCP parity audit, per component, on demand. What is still missing is code-side adoption telemetry: how many times a component ships and how many overrides exist across the codebase. That gap is structural rather than a skill gap, since I do not have developers reporting into me. It is the next layer of instrumentation, not a claim I make today.