Design Systems
Design tokens guide AI. They don't govern the interface.
·5 min read
Updated
Design tokens can give an AI tool the right colors, spacing and typography. They do not, by themselves, make it choose the right component, preserve an interaction or recognize when a new pattern needs approval.
For a B2B product team, the practical requirement is a usable design system around those values: approved components, examples from real workflows and someone responsible for exceptions. A token file is part of that system. It is not an automatic approval mechanism.
Why the distinction matters now
A recent discussion in r/UXDesign asks what system designers should own when agents can perform more maintenance. The useful disagreement concerns judgment: which decisions can be automated, when a variation should become a standard, and whether components have been evaluated in the features that use them. These are practitioner views from one discussion, not a survey of the industry.
There are concrete operating examples, too. In an October 21 account of Harvey's marketing workflow, Gabe Pereyra and Shawn Farsai describe using visual guidelines, worked examples and reusable product and motion libraries alongside written instructions. Their account illustrates the value of supplying relationships and context, beyond isolated values. It does not establish that another team will achieve the same results.
The Design Tokens Community Group's format specification defines a way to exchange token data between tools. That interoperability is useful. It is not a guarantee that an AI-generated interface follows a design system.
The right red can still produce the wrong action
Consider an illustrative admin workflow: someone selects several members of a shared workspace and removes their access. This is a hypothetical example, not a Studio Melamed client result.
The action may use the approved color, font and corner radius while leaving essential questions unanswered. Which members are affected? Does the person performing it have permission? What happens if only some removals succeed? Can the action be reversed?
A token can supply the intended action color. A component can supply consistent loading and disabled states. The feature's interaction rules must still explain the scope, outcome and recovery path. Those responsibilities belong in the brief and implementation, not in an assumption that matching colors mean matching behavior.
What needs to accompany the tokens
A useful handoff gives the agent evidence for the decisions it is expected to make. For a design-system engagement, ask what each deliverable enables the product team to reuse.
Swipe sideways to view every column.
| Supply | What it helps decide | What it cannot settle alone |
|---|---|---|
| Semantic tokens | Which shared value represents an action, surface or state | Whether the action belongs in this workflow |
| Approved components and their usage rules | Which implementation and states to reuse | Whether an existing component covers a new requirement |
| Working feature examples | How components behave together with realistic content | Whether a similar-looking feature has the same permissions or consequences |
| A named owner for exceptions | Who can approve a new pattern and update the shared guidance | Whether the proposed solution works for users |
This is our recommended division of responsibilities, not a claim that every tool can consume every source. Give the tool access only to the references and environments appropriate for the task. Confirm what it actually used.
Miro's October 23 account by Ale Contini describes agents inventing components despite existing guardrails. Their response combined source code, live interface states and system documentation with a specification reviewed before building. The account also distinguishes experimental prototypes from the code engineers take into production. It is a useful example of additional context and review, not proof that tokens or prompts can eliminate errors.
Try the handoff on one real workflow
Before expanding an agent workflow across a product, use one bounded feature to expose gaps in the system. For the workspace example, the brief could specify:
- Scope: remove selected members from one workspace; do not change organization-wide accounts.
- References: the current member-management flow, approved bulk-action component and relevant semantic tokens.
- Expected behavior: show the selected scope, handle partial failure and explain whether access can be restored.
- Uncertainty: identify missing states or unsupported requirements before inventing a new component.
- Approval: name who reviews the interaction and who can accept a shared-pattern change.
These are illustrative requirements to adapt with the product team. They do not replace its authorization model or actual recovery constraints.
Ask for a short explanation of which existing components were reused and what remains unresolved. Then inspect the running workflow. Our AI-generated UI review checklist covers the broader task, accessibility and release checks.
Make exceptions visible
Sometimes the existing system genuinely lacks the pattern a feature needs. Forcing a poor fit can be just as unhelpful as allowing every generated screen to invent its own variation.
Record the proposed exception, why an existing pattern is insufficient, who owns the decision and where the accepted guidance will live. Keep the decision tied to a user task. A new component is not justified merely because an agent produced a convincing preview.
For a buyer, this changes what to ask for: a design system should explain both reuse and change. Our guide to brand guidelines and design systems helps separate that scope from the wider brand foundation.
If you are commissioning this work, bring one live flow, the current library and a known inconsistency. Studio Melamed's brand and digital product design services can help define the components, interaction rules and visual direction the team needs. Contact the studio to discuss the scope.