There is a particular kind of design-system website that resembles a very tasteful museum. Buttons sit under flattering lighting. Colour tokens are arranged with the confidence of expensive paint samples. A date picker waits patiently for somebody to appreciate its anatomy. Everything is immaculate, documented and slightly removed from the unruly product it was built to serve.
That version of the design system was already becoming insufficient. AI makes the gap impossible to ignore.
An agent asked to design or build a feature does not merely need the correct shade of blue. It needs to understand what the product means by “approved”, which actions require evidence, how generated content is identified, when a user may reverse a change and what happens when an integration fails halfway through a workflow. It needs components, certainly, but it also needs the decisions that make those components appropriate.
The design system is evolving from a Figma library into a form of product intelligence: a shared, structured account of how the software should look, speak and behave.
The library solved a real problem
It is worth resisting the fashionable habit of declaring the previous era dead. Component libraries transformed product delivery for good reasons. They reduced repeated design work, aligned design and engineering, improved accessibility and gave teams a common visual vocabulary.
A well-made library answers practical questions quickly. Which spacing token belongs between a field and its help text? How does a compact table row differ from a comfortable one? What does focus look like? Which icon size sits inside a small button? These details matter because inconsistency turns ordinary use into low-level negotiation.
Libraries also create implementation leverage. A repaired component can improve dozens of product surfaces. A token change can update a theme without asking every screen to participate in a scavenger hunt. Work such as Great UI, Motion Primitives and Interface Craft demonstrates the increasing quality and availability of reusable interface patterns.
But a component library usually explains the object more clearly than the situation. It can show an alert. It may not explain whether an overdue financial approval is an alert, a blocking state or an escalation. It can provide a modal. It cannot decide whether sending a charter contract deserves one.
That missing layer is where product intelligence begins.
Components are nouns; workflows need grammar
Imagine an AI agent assembling a quote-approval experience. It finds a card, a status chip, a currency field, an avatar and two buttons. Every component is approved. The resulting interface can still be wrong.
Perhaps the agent gives equal visual weight to “Approve” and “Request changes” even though one creates a commercial commitment. Perhaps it hides the pricing assumptions in a disclosure because the card looks cleaner. Perhaps it displays “Pending” without naming the approver. Perhaps it permits approval while the tax calculation is stale.
The problem is not component quality. The problem is that components are nouns while the workflow requires grammar.
A mature system therefore documents patterns such as approval, revision, reconciliation and recovery. The approval pattern specifies required evidence, authority, consequence and history. The revision pattern explains how proposed changes differ from committed values. The recovery pattern identifies affected work, ownership and safe next steps.
Now the agent has more than ingredients. It has a model of the meal, including the useful instruction not to serve the invoice before the pricing calculation has finished.
Product language belongs in the system
Visual inconsistency is easy to spot. Semantic inconsistency is often more damaging and better dressed.
One part of a product says “Quote sent”. Another says “Submitted”. A third says “Shared with customer”. The team may intend all three to describe the same event. Users cannot safely assume that they do.
In operational software, status language affects decisions. “Booked” might mean commercially agreed, operationally confirmed or entered into a downstream system. Those are not typographic variants. They are different realities.
An AI-ready design system should therefore contain controlled vocabulary alongside visual assets. Each important state needs a definition, entry criteria, permitted transitions, ownership and display guidance. The status token should connect the label, colour, icon and behaviour to the underlying domain meaning.
For example:
Awaiting financial approval means pricing is complete, required data is present and a named financial approver owns the next action.
Ready to contract means commercial approval is complete but no customer commitment has yet been issued.
Integration failed means the source record remains valid, a downstream update did not complete and retry or escalation is required.
Once written, these definitions help designers, engineers, support teams and AI agents make the same decision. The design system becomes less like a paint catalogue and more like a compact operating manual.
Machine-readable does not mean machine-written
The rise of files such as `DESIGN.md` is a useful development. Guidance stored in structured Markdown can travel with a project, appear in code review and become available to an agent at the moment it makes a change. Refero Styles reflects this broader movement towards design instructions that AI can consume directly.
The format is not the breakthrough by itself. A vague rule becomes machine-readable vagueness with admirable efficiency.
“Use cards consistently” does not help an agent decide whether a set of values belongs in a card. “Use the Decision Summary pattern when a user must compare evidence before committing an irreversible or externally visible action” is actionable. It names intent, context and consequence.
Useful documentation should answer five questions:
What problem does this pattern solve?
When should it be used – and avoided?
What information and states are required?
How does it behave across devices, permissions and failure?
Which production component implements it?
Examples should include awkward cases. A pristine form with valid data teaches less than a form containing an unavailable customer record, an expired price and a user who can edit but not approve. AI learns the system’s boundaries from the examples the team bothers to preserve.
Tokens can carry intent
The earliest design tokens encoded visual decisions: colour, type, spacing, radius and shadow. Semantic tokens made them more resilient by naming purpose rather than value. `text-muted` survives a theme change better than `grey-500` because it describes a job.
The same approach can extend into product meaning.
A risk state may connect colour, iconography, content requirements and interaction behaviour. An AI-generated value may require a provenance indicator and a review action. A financially material change may trigger a stronger confirmation pattern. Operational readiness may combine multiple underlying conditions while displaying one comprehensible state.
This does not mean turning every business rule into CSS. It means giving interface decisions stable semantic hooks. The system can then tell an agent that `status.blocked` requires an owner and recovery message, not merely a red dot.
In my design-system case studies, this is where reusable systems create the greatest value. The visual foundation improves consistency; the semantic layer improves decisions. Teams can move faster because they are no longer rediscovering the meaning of the workflow on every screen.
The design system becomes context
AI tools work best when they have relevant context rather than increasingly emotional prompts. A productive context stack might include:
brand and accessibility foundations;
semantic tokens;
production component APIs;
workflow and content patterns;
domain vocabulary;
representative product screens;
permissions and business rules;
tests and acceptance criteria.
With that context, an agent can propose a screen using real components, explain why a pattern applies and check its output against known constraints. Without it, the agent produces a reasonable approximation of software in general.
That difference is strategic. Generic generation is becoming widely available. Product-specific coherence remains difficult because it depends on accumulated judgment. A company that structures that judgment can reuse it through people and machines. A company that leaves it scattered across Figma comments, old tickets and the memory of one senior designer will continue paying archaeology costs.
Documentation must remain alive
Calling the design system “product intelligence” creates an obligation. Intelligence that stopped learning three releases ago is usually called documentation.
The system needs a feedback loop from real product work. When an AI-generated feature exposes a missing state, the team should decide whether the state is unique or a reusable pattern. When two teams solve the same exception differently, the system should absorb the better rule. When support repeatedly explains terminology, the vocabulary needs repair.
Usage data can help. Which components are being detached or overridden? Which patterns generate accessibility defects? Where do teams invent local status colours? These signals reveal where the documented system and the working product have separated.
AI can assist here too. It can identify duplicated patterns, compare implementation against guidance and suggest documentation updates. It should not quietly redefine the system. Governance remains human because the rules encode product and organisational judgment, not merely statistical regularity.
A source of truth that can answer back
The next generation of design systems will still contain buttons, tokens and lovingly documented date pickers. It will also contain the product’s recurring decisions in a form that can be searched, tested and applied.
Designers will use it to explore without losing coherence. Engineers will use it to implement without translating screenshots. Product teams will use it to make language and workflow explicit. AI agents will use it as context for generation and review.
The goal is not to automate taste. It is to stop wasting taste on questions the organisation has already answered.
A Figma library shows what the product is made from. Product intelligence explains why those pieces belong together. That is the evolution AI accelerates: from a collection of reusable objects to a living system of reusable judgment.
