Writing

Design Systems at Scale

NoteAug '263 min read

Notes from governing design across 50+ product teams: what a design system can actually enforce, what it can only influence, and how to tell the difference.

A design system at real scale is a governance problem wearing a component library as a costume. These are my notes on what systems can actually enforce across fifty-plus product teams, what they can only influence, and why confusing the two kills more systems than bad tokens ever did.

The distinction I keep drawing: a system governs mechanics well and judgment badly.

Mechanics are things a machine can check: tokens, type ramps, spacing, focus states, contrast, motion curves. Enforce these absolutely, in the pipeline, not in review. A linter that fails the build on a hardcoded hex beats a hundred critique comments, because it doesn't get tired and doesn't get argued with.

Judgment is everything else: whether this flow needs a wizard or a single form, whether the empty state teaches or apologizes, whether the information hierarchy matches how this user actually thinks. No component library encodes that. I've watched teams assemble screens that were 100% system-compliant and still bad: every part sanctioned, the whole thing wrong. The system had governed the atoms and had nothing to say about the molecule. When leaders promise executives that a design system will "ensure quality," this is the gap they're papering over. It ensures consistency of parts. Quality of wholes still requires designers with taste and the standing to use it.

The structure that survives scale is federated. The core team owns foundations such as tokens, typography, grids, and primitives with something close to constitutional authority. Domain teams own the complex patterns specific to their world, because they're the only ones close enough to get those right. A team building scheduling tools understands a dispatch board's states better than any central team ever will; pretending otherwise just produces a worse board, slower.

The load-bearing wall is semantic token architecture: raw value, semantic alias, component application, in strict layers. Get that right and a domain team can build something wildly specialized that still inherits theme, brand, and dark mode for free, without asking anyone's permission. Tokens are the API between central control and local invention. Most federation failures I've seen were really token failures. The layers leaked, so autonomy meant divergence.

For contribution, pave the cowpaths. Let teams build custom components, watch the codebase, and when three teams independently build the same thing, absorb it: refactor to standard, publish back, credit the originators. Duplication isn't waste; it's the system's demand signal, and it's more honest than any roadmap survey.

The uncomfortable truth: nobody has to use your design system. Mandates produce malicious compliance, with technically adopted components wrapped in overrides. Adoption follows a colder equation: the system must be the fastest way to ship good work, every sprint, or teams route around it and they're right to.

So I stopped measuring component coverage and started measuring the queue. How long from "the system lacks what I need" to "it exists"? That number is the system's real health. When it blows past a sprint, forks stop being a governance failure and start being a rational response. No amount of process reclaims teams who've learned the system is where velocity goes to die. Govern the mechanics ruthlessly, serve the judgment humbly, and keep the queue short. That's the whole job. The org that can actually use a system is a design problem too: org design is product design now.