Most design systems are libraries pretending to be systems
A component library is a set of things you can use. A design system is a set of decisions that have been made. The difference sounds semantic until you watch a team ship a button that is not the button, because the decision was documented but nothing in the workflow made it the path of least resistance.
Most organizations are further along than they think on the first count and further behind than they think on the second. The components exist. The decisions leak.
Where design systems go next is mostly about closing that gap — and the pressure to close it is now arriving from an unexpected direction.
From artifact to specification
The first generation of design systems was a component library plus a documentation site. The second added tokens: color, spacing, type and motion lifted out of components into named values, so a change could propagate instead of being reapplied by hand.
The third generation treats the system as a specification that compiles. Tokens are the source of truth, held in an interchange format rather than a stylesheet — the Design Tokens Community Group format exists precisely to make that portable — and every platform output is generated from them. Web variables, native constants, design tool styles, documentation and increasingly the tests all come from the same input.
This matters for an unglamorous reason. It removes the human step where a value gets transcribed, and nearly every "the design system says X but production does Y" bug is a transcription failure. Generated outputs cannot drift, because there is nothing for them to drift from.
A design system is only as strong as the number of places its values are typed in by hand — and that number should be zero.
Fewer components, stronger primitives
The instinct when a system matures is to add. A team needs something slightly different, so a variant appears, then a variant of the variant. Eventually the library holds forty components, several of which are the same component wearing different names, and nobody can find the right one — which is when people start rebuilding locally, which is when the system starts dying.
The direction of travel is the opposite. A small set of primitives with genuinely composable behavior beats a large catalog of finished pieces. Layout primitives that express spatial relationships rather than named page templates. Unstyled behavioural components — the accessible menu, the focus-trapped dialog — with appearance layered on top, so a visual change never requires re-solving keyboard navigation.
The measure of a good system is not how many things it contains. It is how few things you need to know before you can build something nobody anticipated.
Accessibility stops being guidance
In most systems accessibility lives in the documentation: a section explaining how to use the component correctly. This reliably produces components that are accessible when used as intended and broken the rest of the time.
The alternative is to make it structural. Contrast is guaranteed by the token pairings, so an inaccessible combination is not expressible. Focus management belongs to the component, not to whoever consumes it. Color ramps are generated against a contrast target rather than picked and then checked afterwards. Where a rule genuinely cannot be enforced by construction, it is enforced by a test that runs on every build rather than a paragraph somebody may read.
This is also where the compliance pressure lands. Accessibility obligations for consumer-facing digital services across the EU have tightened, and a design system is the highest-leverage place to respond: fix the primitive once, and every surface built on it inherits the fix.
The new consumer is a machine
Here is the shift almost nobody planned for. A significant and growing share of the code that uses your design system is now written with AI assistance — and an assistant will use your system only if it can find it, read it and trust it.
That changes what good documentation means. A beautiful documentation site optimized for human browsing is close to useless to a tool that never opens it. What actually gets used is this:
- Types that describe intent, not merely shape. A prop union of real variant names is a specification; a loose string is an invitation to invent one.
- Documentation next to the code, in the component source and the type definitions, rather than only on a separate site.
- Examples that are executable, so canonical usage is a file in the repository instead of a snippet in a CMS.
- A machine-readable manifest of what exists: components, variants, tokens, deprecations. If the system cannot describe itself in a file, every consumer has to guess.
- Enforcement in the loop. A lint rule that rejects a raw hex value teaches a generative tool exactly the way it teaches a person: immediately, at the point of the mistake.
Teams that treat their system as a legible, self-describing contract will find AI-assisted development compounds it. Teams that leave it as a human-readable website will find it quietly bypassed.
Governance is the actual product
Every failed design system fails the same way, and it is never technical. There is no owner, so nothing gets decided. There is no deprecation path, so nothing gets removed. There is no adoption measurement, so nobody notices the drift until a redesign surfaces four versions of the same component.
The systems that survive treat governance as a feature set.
- A named owner and a real intake process. Contribution should be a path, not a favor.
- Deprecation as a first-class action — marked in code, warned at build time, with the migration written by the people making the change rather than the people absorbing it.
- Versioning with an explicit contract about what may break and when.
- Adoption as a metric. What share of production surfaces uses the system's primitives, and where is the drift concentrated? Instrument it, or you are guessing.
- A budget for the unglamorous work, because most of the value is in maintenance and none of it is visible.
What to do next
If you have a component library, the next step is not more components. It is extraction: pull the values out into tokens, generate every platform output from them, and delete the places where the same number is written twice.
If you have tokens, the next step is legibility: types that carry intent, documentation that lives with the code, a manifest that describes the system to anything that asks, and lint rules that make the right thing the easy thing.
If you have both, the next step is governance — the least interesting sentence in this article, and the one that determines whether any of the rest is still true in three years.
The future of design systems is not a better component library. It is a system that can explain itself: to a new engineer, to a build pipeline, and to a machine writing code at three in the morning.
