Design systems in the AI era: what makes a product recognizable?

Someone opens an AI tool and asks: “Create a SaaS dashboard with a side menu, metrics, a chart and a table.” In a few minutes, a plausible interface appears. It works, has reasonable hierarchy and looks professional.

The problem is elsewhere. That interface could belong to almost any product. The cards sit in the right places, the chart looks trustworthy and the table behaves as expected. Still, almost nothing reveals who the product is for, which problem it prioritizes or which decisions the brand is willing to defend.

When producing an acceptable first version stops being hard, the differentiator is no longer only shipping screens. The challenge becomes creating recognizable products that cohere with the brand, fit user context and express their own decisions.

In the AI era, a design system is not only there to repeat components. It is there to keep speed from erasing identity.

This article focuses on the homogenization of AI-generated interfaces, the loss of identity and the design system as a product language. Figma, discussing systems in the AI era, reinforces that a strong system can encode a team’s taste and creative identity without giving up scale.

AI does not only create speed. It also multiplies patterns

Generative models work from what already exists. Without their own context, they tend to produce safe, recognizable solutions that resemble what shows up often in libraries, templates and digital products.

That does not mean AI cannot produce quality. It means that, without direction, it chooses the most probable option, not necessarily the most suitable one for that product, brand or audience.

The result is often an interface that “looks like a product,” but does not look like this product. The same side navigation, the same metric cards, the same neutral dashboard tone. Speed increases, and with it the chance of repeating the obvious at scale.

An interface built only from the most common patterns can be technically correct, visually pleasant and still feel generic, predictable and easy to ignore.

Working is not the same as creating recognition

Familiarity reduces learning effort. Standardization organizes recurring decisions. Homogenization removes important particularities. Identity is what makes a product feel coherent with its proposition and the people who use it.

The differentiation that matters is not reinventing buttons, forms, navigation or feedback only to look different. Known conventions remain essential for usability. A button should look like a button. A form should be understandable. An alert should communicate risk clearly.

Identity shows up in hierarchy, density, typography, color use, tone of voice, microcopy, iconography, motion, flow organization, how states are presented and domain-specific patterns. In short: intent, context and knowledge about who uses the product.

This is not about making the interface extravagant. It is about making visible that someone decided, with criteria, what should feel familiar and what should feel distinctive.

The design system as the product’s language

A design system should not be only a collection of components. It is the systematized expression of how an organization creates digital experiences.

It can record principles, tokens, components, interaction patterns, content rules, tone of voice, accessibility, motion, states, examples, anti-patterns and criteria for exceptions. In other words: not only what exists, but how and why it should be used.

If components are available words, principles and rules determine how those words combine to produce meaning. Without that grammar, the team (and AI) can assemble correct sentences that say almost nothing about the product.

That is why a mature system is not just a beautiful library. It reduces ambiguity. It helps the team discuss trade-offs with a shared vocabulary. And it gives the product continuity that survives changes in people, tools and delivery pace.

From documentation for humans to context for agents

Traditional documentation still matters. Now, part of those decisions also needs to be machine-readable.

Structured tokens, coded components, well-documented properties and states, real examples, project rules, files like DESIGN.md, library integrations and automated validations help AI work with explicit limits, relationships and intent. The Design Tokens Community Group specification reinforces that direction: visual decisions can circulate as interoperable data, not only as styles locked to one tool.

Storybook, for example, stops being only a component showcase. Stories, properties, states and tests start working as operational evidence of the system. The same goes for MCPs and other integrations: they do not replace human judgment, but they lower the cost of delivering good context at generation time.

Providing only a palette is not enough. The agent needs to understand the role of colors, when to use each component, which combinations are allowed and which decisions should be avoided. As Brad Frost notes, AI is a natural consumer of design systems, but strategic and critical decisions remain human.

The design system as memory of decisions

A good system preserves the team’s accumulated reasoning. It records answers to questions already debated: how to present destructive actions, how to organize dense interfaces, how to communicate risk, how to write errors, how to balance beginners and experts, how to keep accessibility and what makes the product recognizable.

Without that context, an agent can use the right components and still produce an inadequate experience. It can build a correct table with the wrong density. It can emit a visually consistent alert with a message that fails to communicate consequence. It can follow the design system and still fail the product.

Figma describes this shift well: systems start encoding a team’s taste and creative identity, enabling scale without erasing what makes the product specific. Instead of only accelerating screen production, the system starts protecting the criteria behind those screens.

What I learned from systems for complex products

I have worked in design for more than 11 years. I have helped build and evolve design systems, created one from scratch at Azion and spent much of that time on complex products for developers and technical users. My proximity to front-end helped me bring design decisions closer to implementation.

In those contexts, visual consistency was never enough. The system also needed to record decisions about density, states, risks, permissions, bulk actions, complex tables, configuration flows and the consequences of actions. A technical product does not lose trust only because it “looks inconsistent.” It loses trust when the interface hides risk, dilutes hierarchy or forces people to reinterpret the same pattern on every screen.

That is where the designer’s role became clearer to me. It is not only about drawing screens. It is about defining decisions, criteria and constraints that other people (and now agents) can apply with quality.

When any interface can be generated, the advantage is no longer only producing screens. It is encoding good decisions.

The first step is not drawing every component

Starting a design system does not mean immediately building dozens of components. The more realistic path begins with what already exists, the decisions that repeat and the criteria missing when the team needs to choose quickly.

Brad Frost describes the interface inventory as a powerful starting point for exactly that reason: it makes visible what the product already practices, including contradictions. Figma, in its guides for building systems, reinforces the same logic: audit, align design and code, and grow from real decisions rather than an idealized library.

No tool replaces poorly defined decisions. Tokens, Storybook, MCP or DESIGN.md only amplify the quality of what the team has already made explicit. If the criteria are vague, AI simply reproduces that vagueness faster.

Direction matters more than speed alone

AI lowers the cost of execution and raises the importance of direction. It generates possibilities quickly. The design system helps determine which possibilities belong to the product.

That shifts the center of the work. Less time negotiating every screen from scratch. More time defining what should repeat, what should vary, what communicates risk, what expresses brand and what respects the context of the people who use it.

The future will not be defined only by who can generate more interfaces. It will be defined by who can teach people and machines to make decisions coherent with a product, a brand and its users.