Everyday Programmer
Work with Jimmy
Field Notes

A Design System Cannot Protect Apps That Don't Use Its Safeguards

Component-level visual tests prove the library is healthy — not that the apps composing it are. Layered verification has to cross the boundary.

3 min readfield notes, design systems, visual regression, testing
A Design System Cannot Protect Apps That Don't Use Its Safeguards

The design system was exemplary: every component in Storybook, every story covered by Chromatic, tokens enforced, accessibility checks green. And three months after its biggest consumer shipped a redesign, a marketing page shipped with a broken responsive layout and a journey-breaking form — none of which any design-system test could see.

The lesson is uncomfortable for platform teams: component-level confidence is incomplete when consuming apps don't test composition.

What Storybook and Chromatic prove — and what they don't

Isolated component tests prove each brick is sound: variants render, props work, contrast passes, baselines match.

They cannot prove anything about walls. They don't know:

  • That the consuming app renders <Button> inside its own 300px sidebar grid, where the label truncates
  • That a page combines four components in an order the library never anticipated
  • That the checkout journey still works end to end

Where the regressions actually showed up

Regression type

Caught by DS tests?

Caught by app tests?

Component variant broken

Yes

Yes

Component misused in context

No

Yes — page-level visual tests

Responsive layout collapse

No

Yes — viewport coverage

Critical journey broken (signup, checkout)

No

Yes — E2E

Token change ripples unexpectedly

Partially

Yes

The bottom two rows are where production incidents lived.

The ownership gap

This is organizational as much as technical. The platform team owns the library; the product teams own the apps. When the dashboard breaks at 768px, both teams point at the other's test suite — and the gap between them has no owner.

The fix we landed on:

  1. Platform team keeps component-level coverage and publishes what it does and doesn't guarantee — in writing, in the DS docs
  2. App teams own page-level visual regression on their critical routes and the E2E journeys that make them money
  3. The DS ships a starter config — Playwright viewports, baseline setup, recommended Chromatic project settings — so "we didn't know how" stops being the reason app teams skip it

A layered visual-testing strategy

test-layers.txt
text

Layer 4 is the one most organizations miss: when the design system releases, the consuming apps run their suites against the release candidate. That closes the loop — and it's where a token change that ripples unexpectedly gets caught before it ships.

A design system's safeguards protect the library. The apps need their own — and the DS's real job is making those easy to build.

Keep reading

Related articles