Design systems are excellent at standardizing what products look like. As products become more adaptive and AI-enabled, they also need shared principles for how products act, explain decisions, request permission, communicate uncertainty, and return control to users.
Design systems have become one of the most mature areas of digital product design.
We know how to create tokens, components, variants, documentation, accessibility rules, and contribution models. Mature organizations use design systems to improve consistency, speed, quality, and collaboration across many teams, and that work remains as important as ever.
At the same time, I believe products are changing faster than the traditional definition of the design system.
Components are very good at standardizing what is visible, but they are less effective at standardizing how a product behaves. This gap becomes increasingly important as products become more adaptive, data-driven, and AI-enabled.
The same component can support very different experiences
Imagine a simple task application.
The design system may define a task card, a date picker, a confirmation dialog, button hierarchy, typography, spacing, and color. Now imagine that the product notices a user repeatedly missing a task and offers to move it to tomorrow.
The visual system can tell us how that suggestion should look, but many of the decisions that shape the actual experience sit somewhere else. The team still needs to decide when the suggestion should appear, how confident the system needs to be, whether the product should explain its reasoning, and whether it can act automatically or must ask for permission first.
The same is true for recovery. If the product makes a change, the user may need a clear way to undo it, and similar situations elsewhere in the product should probably follow the same logic.
I think these are design-system questions too.
Not because every product decision belongs in a component library, but because some behavioral decisions have the same characteristics as components and tokens: they repeat across teams, require consistent implementation, and create systemic debt when every team solves them differently.
That is the boundary I find useful. A behavioral decision belongs in the system when it is no longer local.
Consistency is behavioral as well as visual
Users learn a product through repetition. They learn what a primary button means, where navigation lives, and what will happen after pressing Save. They also build an equally strong model of how the product behaves.
Over time, users learn whether the product usually waits for permission or makes changes automatically. They notice whether recommendations are explained, whether dismissed suggestions return, whether actions can be undone, and whether AI-generated information is treated differently from verified information.
They also learn how the product behaves when it is uncertain. Some products communicate uncertainty clearly, while others present almost every output with the same degree of confidence.
All of these patterns create expectations. If different teams handle them differently, the product may remain visually consistent while becoming behaviorally unpredictable.
In my view, this is where design systems have an opportunity to evolve.
From component rules to behavioral principles
A behavioral layer should not become a giant rulebook. Over-standardization can create a different problem by making teams afraid to experiment or respond to the needs of their specific domain.
The goal should be to identify decisions that genuinely repeat across the product and establish principles strong enough to guide them without prescribing every possible interaction.
I think of this behavioral layer as a set of reusable principles, constraints, and interaction patterns that govern how a product initiates actions, explains decisions, requests permission, communicates uncertainty, and allows users to recover.
For an AI-enabled product, these principles could cover areas such as suggestion, autonomy, explanation, confidence, confirmation, recovery, memory, and escalation.
A system could define when the product should proactively surface a recommendation and when it should remain passive. It could establish when an automated action is acceptable and when explicit confirmation is required. It could also define expectations around explaining recommendations, communicating uncertainty, providing recovery mechanisms, and returning control to the user when automation is no longer appropriate.
The important shift, I think, is from documenting individual interface patterns to documenting the logic that connects them. Those principles can then be connected to interaction patterns, examples, prototypes, technical requirements, and implementation guidance. In that sense, the design system becomes a bridge between product intent and implementation.
What does this look like in practice?
There is no single correct format for this layer. A small set of product principles may establish the overall philosophy, while decision trees can describe how the system should respond in common situations. Behavioral patterns can document recurring interaction models, and state diagrams can make transitions and edge cases easier to understand.
Prototypes are particularly useful when timing, feedback, or recovery is important because static documentation often cannot communicate those qualities well. Examples of correct and incorrect applications can also help teams understand where a principle applies and where it does not.
Content guidance is another important part of the system because uncertainty, confirmation, explanation, and error are often communicated through language as much as through interface structure. Engineering documentation can then connect these principles to implementation patterns so that the behavioral model does not remain purely conceptual.
What matters most, in my opinion, is that this material is shared. It should not exist only in a designer’s head or in the comments of a single Figma file. It should become part of the product’s operating language across design, product, engineering, content, data, and AI teams. The real value appears when a principle can travel across disciplines: from product intent to interaction pattern, from interaction pattern to implementation, and from implementation to a consistent user expectation.
A design system is an agreement, not just a library
This is already true of traditional design systems. The component library is the most visible part, but the real system is the agreement behind it: this is how we build this product together. A behavioral layer extends that agreement beyond visual structure. It creates shared expectations about how the product asks for permission, how it makes decisions, how it explains itself, how it gives control back to the user, and how it behaves when something goes wrong.
These agreements become especially valuable in large organizations because local decisions accumulate quickly. One team may make an assistant proactive while another makes it passive. One feature may save changes automatically while another requires explicit confirmation. One AI experience may communicate uncertainty clearly while another hides it completely. Each individual decision can be reasonable in isolation. The problem appears when those decisions are combined into one product and users are expected to understand the resulting logic. I believe behavioral consistency is one of the ways a product develops a recognizable character.
Do not standardize everything
There is an obvious danger in extending design systems too far.
Not every product decision should become a system rule. Some behaviors are specific to a feature, some areas need experimentation, and some teams need freedom to respond to their particular domain. The purpose of a design system is not to eliminate design decisions. It is to reduce unnecessary reinvention so that teams can spend more time on problems that are genuinely new. A useful test is whether a decision appears repeatedly across the product and whether inconsistent answers would create confusion, risk, or unnecessary implementation cost. It is also worth asking whether multiple teams would benefit from a shared principle and whether that principle is likely to remain useful as the product evolves.
Repetition alone is not enough. The stronger signal is systemic consequence: inconsistency affects trust, learnability, accessibility, safety, or the product’s overall logic. If those consequences do not exist, the decision probably does not belong in the system.
The goal is not uniformity. It is coherence without freezing the product.
Design systems are becoming product infrastructure
The most mature design systems already extend far beyond Figma. They influence code, accessibility, content, analytics, contribution processes, and product quality.
I see behavior as a natural next layer of that evolution rather than something entirely new.
Behavioral consistency has always mattered in digital products. Autosave, destructive actions, permissions, notifications, defaults, personalization, and recovery have all required shared interaction logic long before AI became a major product category.
What AI changes, in my view, is the cost of getting that logic wrong.
As products gain more intelligence and autonomy, inconsistent behavior becomes more consequential. A small visual inconsistency may be annoying, but inconsistency in when a system acts on a user’s behalf, asks for permission, communicates uncertainty, or allows recovery can affect trust much more directly.
That changes the strategic value of the design system. It becomes not only a way to scale interface production, but also a way to scale recurring product decisions across an organization.
Components still matter, as do tokens, documentation, accessibility, and craft. But the next generation of design systems will increasingly need to preserve something larger: the logic of the product itself.
A mature design system is therefore not only a library of reusable parts. In my view, it is a shared agreement about how the product behaves.