UX Design System – UX Expertise and AI

Anyone who develops digital products knows the problem: a button looks different on one page than it does on the next. A form field has different spacing, an error message uses different wording. Each deviation seems small. Together, they lead to interfaces that are difficult to understand and teams that spend a lot of time on rework. This is exactly where a UX design system comes in. It bundles rules, building blocks, and documentation in one place. Creating a UX design system requires more than just design knowledge. At the same time, a question arises that is currently occupying many teams: if AI can generate interfaces and code, are UX designers still needed to build a UX design system? The short answer is: yes. The longer answer shows which tasks remain with humans and where AI can provide useful support.

‍

What a UX design system achieves

A UX design system is more than just a collection of colors and fonts. It describes how a product looks, how it behaves, and why it is designed that way. This includes reusable building blocks, guidelines for their use, and documentation that makes decisions transparent. Teams rely on this when building new features. They don't have to start from scratch for every page. This saves time and reduces discrepancies between products and teams.

Two terms are central here: design tokens and component libraries. Design tokens are named values, for example for colors, spacing, or font sizes. They are independent of specific technology and can be used in Figma just as they can in code. A component library is the collection of reusable UI building blocks, such as buttons, input fields, or dialogs. Both terms are often used interchangeably in everyday work, but they are not the same. The tokens form the foundation, and the components are built upon them. Before teams define UX design tokens, they should review existing values and resolve duplicates.

The building blocks at a glance

• Design tokens:named values for colors, spacing, and typography
• Component library:UI building blocks with defined variants
• Patterns and guidelines:rules for when to use which building block
• Documentation:purpose, behavior, accessibility, and examples for each component
• Governance:defining who reviews and approves changes

‍

Creating a design system: the process

Development rarely starts with a blank file. Usually, there are already interfaces that have grown over the years. The first steps are therefore consultation with the client and an inventory: what requirements and needs does the client have for the design system? Which building blocks appear most frequently, and where do they differ for no apparent reason? This determines which tokens and components should be defined first. Often, the system is initially created in Figma before being transferred to code. For many teams, a Figma design system is the starting point because the tool defines their daily work.

There is a reason for this sequence. Those who build components without first knowing the client's needs are merely documenting coincidences later on. Building a system is therefore a professional task, not a purely technical one. Only then can teams create the component library that builds on these values.

Furthermore, development requires coordination with the engineering team. Designers and developers must agree on names, states, and variants. If they are not in sync, two separate systems will emerge. This shows that a UX design system is a shared tool, not a document that is handed over just once.

‍

Why decisions need humans

Every component is a decision. A button needs variants for primary and secondary actions. An input field needs an error message that explains what to do. Such decisions depend on who is using the interface, in what situation, and with what goal. UX designers gather this context through research, interviews, and observation. An AI can suggest variants. However, the team must clarify through testing whether a variant works for specific users in a concrete task. Without this step, every component remains an assumption.

Where UX expertise is indispensable

• Target audiences and tasks:Which users are working with the system, and what are their goals?
• Accessibility:Which contrasts, focus states, and labels are necessary?
• Workflow fit:Does a component integrate into existing usage patterns?
• Exceptions: When is a deviation from the system appropriate, and how should it be documented?

These questions cannot be derived from a repository of interfaces. They require knowledge about people and their context. This very knowledge makes the difference between a library that many teams use and one that they bypass.

‍

Documentation as a foundation for AI

AI models work with the information they are given. If tokens, components, and rules are clearly named and described, they can generate interfaces more consistently. If this foundation is missing, they will invent values that do not exist in the system or choose components that do not fit the context. The quality of the results therefore depends directly on the quality of the documentation. Documenting a UX design system therefore means recording decisions in such a way that both humans and models can understand them.

Good documentation answers three questions: what is a building block intended for, how does it behave, and when should it not be used? Clean documentation is not a chore to be completed at the end of a project. It is the prerequisite for AI to be able to contribute meaningfully.

Detecting and organizing errors

AI can help with maintenance. For example, it can find color values that do not originate from the tokens or duplicate components with similar names. Such deviations can be sorted and grouped so that teams can see more quickly where action is needed. However, humans must make the decisions: is the deviation an error or a conscious exception? This requires knowledge of the product, the users, and the reasons for previous decisions. AI verification is therefore a suggestion, not a final check.

‍

Maintenance and governance

A UX design system is never finished. Products evolve, new requirements arise, and components need adjustments. Maintaining a UX design system means reviewing, documenting, and publishing changes in an orderly fashion. This requires clear responsibilities. In practice, a fixed cycle helps, such as a regular review where pending changes are examined. How often this rhythm makes sense depends on the size of the team and the number of products. There is no one-size-fits-all number for this.

This is where governance comes into play. It defines who submits proposals, who evaluates them professionally, and who gives final approval. Without these rules, parallel variants emerge that become indistinguishable after a while. Lean UX design system governance with fixed processes prevents this and keeps the system stable even when teams change.

‍

Requirements in regulated environments

In medical technology, additional requirements apply. The IEC 62366-1 standard describes the usability engineering process for medical devices. ISO 14971 regulates risk management, and ISO 13485 covers quality management requirements. A design system touches these areas as soon as components influence operation. In such cases, changes must be traceable, approved, and documented. Which requirements apply in an individual case depends on the product and the organization.

‍

Conclusion

A UX design system is not created by tools alone. It requires clear decisions based on users, tasks, and accessibility. UX design and UX research provide this foundation and verify it through testing and design expertise. A cleanly documented basis also helps AI models work more reliably. AI can find and organize deviations. However, the responsibility for the decisions remains with the designers on the team.

‍