Design Systems: From Figma File to Production Infrastructure

You know this story because you’ve lived it. Your organization spent over a year building a design system. Designers poured months into the Figma library. The launch blog post was great. And within six months, only two product teams were actually using it. Everyone else forked their own button components. The official version didn’t support the variants they needed. A patch update broke their layouts with no changelog. The contribution process had a six-week review queue that nobody was assigned to run. Three strikes and the teams walked.

Brad Frost’s Atomic Design defines the composition model. But most design systems don’t die because the composition model was wrong. They die because nobody treated the component library as production infrastructure.

Design Tokens as the Foundation

If you take one thing from this article, make it this: design tokens must be the source of truth for all visual decisions. Not #1A2980 but --color-brand-primary. Not 16px but --spacing-md. Token values can change freely. Semantic names should not.

The distinction between semantic and literal token names is load-bearing. Semantic names (--color-interactive-primary) let you swap entire themes by remapping references. Literal names (--color-blue-500) bake a specific value into every consumer, forcing code changes when the brand evolves. One approach scales. The other creates cross-platform drift that compounds with every new surface.

Components reference semantic tokens only. Theme switches swap the resolution layer. No component code changes.

Style Dictionary generates CSS, Swift, and Android outputs from one source. The design tokens guide covers the full pipeline.

Component Library Versioning

An unversioned library where teams pull from main is a ticking time bomb. One engineer changes button padding. Forty teams inherit the change. Three of those teams have pixel-perfect layouts that break. None of them opted in.

“Non-breaking” is harder for components than APIs. A spacing change doesn’t break compilation but breaks layout. Changesets tooling forces explicit categorization per change, and that categorization is what keeps the contract honest. Without it, every minor feels like Russian roulette.

For major versions, run parallel (v3 + v4) during a 3-6 month migration window. Codemods automate the bulk of mechanical changes. The remainder, the handful of edge cases that defy mechanical transformation, is where real design conversations happen.

Visual Regression Testing

A spacing change in Button silently breaks 10 applications. Without visual regression, nobody hears about it for three weeks, when some team’s QA finds a layout shifted and opens a bug nobody connects to the upstream change.

// Playwright visual regression test for Button component
test('Button renders correctly across all variants', async ({ page }) => {
  await page.goto('/storybook/iframe.html?id=button--primary');
  await expect(page).toHaveScreenshot('button-primary.png', {
    maxDiffPixelRatio: 0.01,  // 1% pixel tolerance
  });

  await page.goto('/storybook/iframe.html?id=button--secondary');
  await expect(page).toHaveScreenshot('button-secondary.png');

  await page.goto('/storybook/iframe.html?id=button--disabled');
  await expect(page).toHaveScreenshot('button-disabled.png');
});

Chromatic and Percy capture every Storybook state per PR. But coverage is only as good as your stories. No story for the error state means no visual baseline for the error state. Track story completeness alongside code coverage. Mature UI/UX engineering treats edge case stories (long text, empty content, RTL) as the surface where regressions actually hide. The normal states look fine. The weird states break silently.

Accessibility as a CI Gate

Axe-core in Storybook catches 30-40% of WCAG issues automatically. Missing alt text, insufficient contrast, improper ARIA roles. The rest, keyboard navigation patterns, screen reader announcement quality, focus trap behavior, requires documented manual acceptance criteria per component type. For accessibility engineering , these criteria are a non-negotiable definition of done.

Automated checks create a floor. Manual review raises the ceiling. Neither works alone. A component that passes axe-core but traps keyboard focus in a modal with no escape route is technically “accessible” by the linter and completely unusable by a screen reader user.

Governance Without Bottleneck

The core team owns the platform, the quality standards, and 30-50 foundational components. Product teams contribute domain components through CI gates. No ticket queue. No review committee. PR passes the gates, it merges.

This only works if the gates are comprehensive and fast. Accessibility, visual regression, documentation coverage, and unit test thresholds all enforced automatically. If the automation catches regressions reliably, the human bottleneck evaporates. If the automation is thin, you’re back to manual review queues that stretch to six weeks.

ADRs (Architecture Decision Records) for significant choices prevent quarterly relitigating by newcomers who weren’t in the room when the decision was made. CI/CD gates enforce standards that committees only debate.

Two teams using the system six months after launch. The Figma was never the problem. No semver. No visual regression. No contribution path. Design systems that survive are production infrastructure with the engineering to match. Build that engineering or watch adoption flatline.