Beyond AI-ready design systems: Towards AI-ready product knowledge
Design systems are only part of the puzzle
I recently read an article about why AI-generated UI needs a design system that can enforce its rules. It connected surprisingly well with something I have been thinking about while working on design systems.
We usually talk about design systems as a way to create consistency. They give designers and developers shared components, tokens and patterns, reduce repetitive work and make changes easier to manage across a product. But AI introduces another user of the design system, the machine. And machines need things to be much more explicit. Perhaps the question is bigger than how to make a design system AI-ready. What would it mean to make product knowledge itself AI-ready?
From reusable components to rules
AI can generate a button, table or form remarkably quickly. But generating UI is not really the difficult part. The difficult questions are different.
Which component should be used in this situation? Which variants are valid? Which components can be combined? What does a particular state mean? When should a warning appear instead of a normal confirmation? What should happen when the user cancels an action?
For a human designer, some of these decisions may be based on experience, context or knowledge that has never been formally documented, but AI cannot reliably work from that kind of implicit knowledge. This changes what a design system needs to communicate.
A component library describes the building blocks available to us. A more mature design system also starts to describe the rules for constructing interfaces from those blocks.
In that sense, a design system begins to resemble a grammar.
Designing a language that can be interpreted
This makes seemingly small structural decisions increasingly important. Tokens should not only contain values. They should communicate meaning. Components should not simply contain every variation that has accumulated over time. Their properties and states should represent meaningful differences in behaviour. Documentation should explain not only what a component looks like, but why it exists, when it should be used and what constraints apply to it.
The clearer this structure becomes, the less an AI needs to guess. This is an interesting shift because AI is often discussed as something that gives us more freedom to generate interfaces. I wonder whether the more valuable direction is almost the opposite. Perhaps we should become better at defining the boundaries within which generation can happen.
This becomes even more important in complex products
This question becomes particularly interesting in complex and regulated products. Visual consistency is important, but it is only one layer of a correct interface. A UI may also need to meet product and accessibility requirements, follow interaction rules, accommodate technical constraints and support safety-related behaviour.
Knowing that a warning dialog component exists is not enough. AI also needs access to the knowledge that determines when a warning is required, what action triggers it, what the consequences of continuing are and what must happen if the user cancels. That knowledge may live partly in the design system, partly in requirements and partly elsewhere in product documentation.
This suggests that an AI-ready design system may eventually be about more than making component libraries machine-readable. The interesting challenge is connecting different kinds of knowledge.
Requirements define what the product must do.
Interaction rules define how users can act within it.
The design system defines the available interface language.
AI can potentially compose solutions within those constraints.
But in a regulated product, there is another layer. It may not be enough to know that a design decision is valid. We may also need to know why it was made.
A valid interface also needs a reason
In medical device development, UI design decisions do not exist in isolation. They are connected to requirements, usability engineering, risk management, implementation and verification.
This makes traceability particularly interesting in the context of AI-generated UI. It may not be enough for an AI to select an approved component and configure it correctly. If an AI adds a warning dialog, for example, can we trace that decision back to the requirement, risk or design rationale that makes the warning necessary? And can the resulting behaviour later be verified against the same source?
This suggests that machine-readable design systems may eventually need to connect to something larger than component libraries:
user needs → requirements → interaction rules → UI components → implementation → verification
(Simplified conceptual model. In practice, these activities are interconnected and iterative, with feedback loops between usability engineering, risk management, design, software development and verification.)
The challenge is no longer only generating valid UI. It is preserving the reasoning behind it.
Less guessing may be the real opportunity
All of this has changed how I look at some of the less glamorous parts of design system work. Defining primitives, using semantic tokens, simplifying component structures, naming properties carefully and documenting usage rules can easily look like maintenance work. But these decisions make implicit design knowledge explicit.
The same principle may apply beyond the design system. Requirements, interaction rules, design decisions and verification already contain different parts of the knowledge needed to understand a product. AI may simply make a problem that already exists more visible. The challenge is making the relationships between them explicit enough to follow.
That matters to designers. It matters to developers, testers and everyone maintaining the product. And increasingly, it may matter to AI systems participating in the same workflow.
Perhaps the goal is not to teach AI to design more freely, but to create an environment in which it needs to guess less. And in a regulated product, less guessing is only part of the equation. We should also be able to explain why the resulting design is there.
