Design Systems Became Governance. Act Accordingly.

Most design systems started as a shared component library with a documentation site. That framing has quietly stopped being sufficient. When a meaningful share of interface code is generated rather than hand-written, the system's job changes: it is no longer a set of parts to pick from, it is the constraint that keeps generated output consistent with everything else.

From suggestion to enforcement

A library documented in a website is a suggestion. Nothing prevents a developer, or a generation tool, from producing a button with the wrong padding and a hard-coded colour. Enforcement means the rules live where the code is checked: tokens that fail a build when a raw hex value appears, linting that rejects arbitrary spacing values, visual tests that catch drift before merge.

This is a shift in posture that design system teams often resist because it feels adversarial. It is the opposite: a system that cannot be violated by accident is a system that stops needing policing by humans in code review.

Tokens are the contract

The durable part of a design system is not the components, which get rewritten every framework cycle. It is the token layer: the names for colour roles, spacing steps, type scale, radii, and motion durations. Get these right and a redesign becomes a token change. Get them wrong, with names like blue-500 instead of surface-accent, and every theme change becomes a search-and-replace across the codebase.

• Name by role, not by appearance.
• Keep the scale small enough that choosing is easy.
• Version the token set and treat a change to it as a breaking change.

Generated interfaces need real components

The single highest-leverage investment for a design system team right now is making the real component library the source that generation tools draw from. Output assembled from your actual primitives inherits your accessibility work, your theming, and your responsive behaviour. Output assembled from generic markup inherits none of it and produces work that looks approximately right and behaves wrong.

A design system is measured by how hard it is to build something inconsistent, not by how many components it documents.

Staffing reality

Systems fail from under-ownership more often than from bad design. A component library with no dedicated maintainer decays into a set of forks within two release cycles. The minimum viable team is someone accountable for the tokens and the release process, with the authority to say no. Without the authority, the role becomes documentation maintenance.