A status colour is never just a status colour in airline software.
Green may mean commercially approved, operationally ready, paid, synchronised or merely “nothing has complained recently”. Red may signal a blocked workflow, a failed integration, an overdue task or a warning somebody decided should look energetic. The hexadecimal value is the least interesting part of the decision.
Design tokens began as a practical way to name and distribute visual values. Instead of copying `#1F5EFF` into 200 files, teams referenced a shared token. Typography, spacing, radius, elevation and motion followed. The system became easier to theme, maintain and translate between design and code.
AI makes the next step both possible and necessary. Tokens are becoming product infrastructure: stable semantic references that help people and agents understand not only how an interface should appear, but what its states mean and how they should behave.
Raw values travel badly
A raw token describes an ingredient. `blue-500` tells us which blue. `spacing-16` tells us how much space. These names are useful at the foundation, but they do not explain why a value appears in the product.
Semantic tokens name the job:
`text-secondary`
`surface-raised`
`border-focus`
`status-warning`
`action-destructive`
Now the value can change by theme, context or accessibility mode while the intent remains stable. The interface is no longer coupled to a particular shade or measurement.
For AI-generated UI, this matters enormously. An agent told to use `orange-400` must infer what orange means. An agent given `status-at-risk` has a product concept it can apply, document and verify.
But even `status-at-risk` is incomplete unless the system defines risk. Does it mean a deadline is approaching? Required data is missing? A financial threshold has been exceeded? An aircraft option is no longer available? Different forms of risk may share visual treatment while requiring different actions.
The token becomes infrastructure when it connects presentation to agreed behaviour.
Tokens can encode a contract
Consider a semantic state called `workflow-blocked`.
At the visual level it may map to a colour, icon and surface treatment. At the component level it can require:
a reason;
the affected object;
a named owner;
the action needed to continue;
an escalation route when the user cannot resolve it.
At the content level it can prohibit vague copy such as “Something went wrong”. At the analytics level it can identify blocked duration. At the accessibility level it can ensure the state is announced without relying on colour.
The token now represents a small contract between design, code and product behaviour.
This does not mean putting business logic inside a colour variable. It means creating stable semantic concepts that components, documentation and workflow rules can share. The visual token is one expression of the concept, not its entire biography.
Readiness is more useful than greenness
Operational products frequently compress several conditions into a state users can act upon.
“Ready to contract” might require:
quote approval;
valid customer details;
an authorised signatory;
completed tax information;
no unresolved pricing errors.
The interface may display one readiness state, but the design system should connect it to the underlying definition. An AI agent designing the contract area can then show the status consistently, reveal unmet conditions and choose the correct next action.
Without that semantic model, the agent may interpret readiness as a green badge supplied by the API. It cannot explain why the work is not ready or what the user must do.
Tokens such as `readiness-incomplete`, `readiness-review` and `readiness-ready` can coordinate visual treatment across a list, detail view, notification and report. The workflow definition supplies the reasons. The component ensures every surface tells the same truth.
This is product infrastructure because multiple teams and systems depend on the shared meaning.
Provenance needs a token vocabulary
AI-generated and integrated data introduce questions of origin.
A value may be:
entered by a user;
imported from a customer request;
calculated from a pricing formula;
retrieved from an enterprise system;
generated or summarised by AI;
manually overridden;
stale because its source changed.
Displaying every origin with a different visual flourish would make the interface resemble an evidence-themed advent calendar. Ignoring origin entirely makes important values appear equally authoritative.
A semantic provenance system can define when origin must be visible and how detail appears on demand. For example:
`source-system` identifies authoritative integrated data;
`source-calculated` exposes inputs and formula context;
`source-generated` requires a review state and accessible provenance;
`source-overridden` preserves the previous value, author and reason;
`source-stale` warns that the source has changed since capture.
Components can use these tokens to apply consistent indicators, tooltips, disclosures and review actions. An AI agent gains a vocabulary for treating generated information responsibly rather than attaching a sparkle icon to anything it finds interesting.
Approval is a semantic system
Approval often appears as a button and a status. In reality it combines authority, evidence, scope and consequence.
A useful token model might distinguish:
`approval-not-required`
`approval-required`
`approval-pending`
`approval-changes-requested`
`approval-approved`
`approval-expired`
Each state should define allowed transitions and required information. `approval-pending` needs an owner and submission time. `approval-changes-requested` needs a reason and route back to revision. `approval-expired` needs the condition that invalidated the previous decision.
These definitions help an agent generate consistent approval experiences across pricing, contracts and invoices. The same semantic state can adapt visually to a table row, timeline or decision panel without changing meaning.
The benefit is not simply consistency. It is auditability. When interface states map to explicit domain concepts, design conversations become easier to connect to system events and business rules.
Motion tokens can describe consequence
Motion systems commonly define duration and easing tokens. That is useful, particularly when libraries such as Motion, Motion Primitives and Anime.js make sophisticated animation easy to implement.
Semantic motion goes further:
`motion-state-change` preserves continuity when content updates;
`motion-confirmation` acknowledges a completed local action;
`motion-attention` indicates a new exception without looping indefinitely;
`motion-progress` communicates genuinely continuing work;
`motion-reduced` supplies the non-animated equivalent.
The token names the communicative job. Components can then use an appropriate implementation for the platform and user preference.
An AI agent asked to animate a panel no longer needs to improvise. It can determine whether the transition explains navigation, confirms causality or merely adds movement. The system permits the first two and asks the third to produce references.
Tokens connect design and code—but also language
The typical token pipeline moves values from a source into Figma, code and documentation. Product-semantic tokens should also connect to content.
For `status-integration-failed`, the system might specify:
label pattern: “[Destination] update failed”;
required detail: affected record and last successful step;
action priority: retry when safe, otherwise escalate;
technical disclosure: available but secondary;
notification rule: alert the current owner, not the entire organisation.
The visual token, content rule and behaviour now share one semantic reference. This makes it easier for AI to generate the complete state rather than a styled container with generic copy.
Controlled language is particularly important across documents and exports. If the product uses `quote-issued`, the customer PDF, activity history and internal screen should describe that event consistently. Semantic infrastructure prevents the website from saying “Sent” while the invoice system insists “Released” and support calls it “the blue stage”.
What belongs in a token—and what does not
There is a risk of turning every idea into a token until the system resembles an unusually bureaucratic thesaurus.
A concept deserves shared semantic infrastructure when it:
Appears across multiple features or surfaces.
Must retain stable meaning.
Influences presentation or interaction.
Benefits from central governance.
Can be named without hiding essential context.
One-off workflow rules may remain in domain specifications. Complex calculations belong in application logic. Tokens should connect systems, not replace them.
The naming also needs discipline. `status-bad` is admirably concise and almost entirely useless. Names should express the product concept and remain independent of one visual treatment.
Layering helps:
foundation tokens define raw values;
semantic interface tokens define general purpose;
product-semantic tokens define recurring domain meaning;
components and workflows apply those tokens in context.
This preserves flexibility without asking a single token to carry the weight of the organisation.
AI makes token quality visible
Human designers often compensate for weak token systems through experience. They know that `warning-orange` is used for deadlines but not pricing risk, despite nobody having documented this distinction since 2022.
AI agents expose the ambiguity. They apply what is written and available. If token names describe appearance rather than intent, generation becomes visually consistent but semantically loose.
That exposure is useful. It shows where the system relies on tribal knowledge.
An audit can ask:
Which raw tokens appear directly in product components?
Which semantic names have multiple conflicting uses?
Which recurring states lack shared tokens?
Which tokens describe colour when they should describe purpose?
Which components add local status logic?
Which meanings differ between design, code and content?
AI can assist by scanning implementations and clustering usage. Humans decide the appropriate semantic model. Frequency alone cannot determine whether a pattern is correct; sometimes it merely identifies the most successful inconsistency.
Infrastructure needs ownership
Once tokens carry product meaning, changing them is not a cosmetic task.
Renaming a state, altering its requirements or merging two concepts can affect workflows, analytics, documents and integrations. Ownership should therefore include product and domain expertise alongside design and engineering.
Changes need versioning and migration guidance. Deprecated tokens should point to replacements. Examples and tests should update with the definition. AI agents must receive the current version rather than whatever token list happened to be copied into a prompt six months earlier.
This sounds heavier than choosing a colour because it is a different category of work. The reward is a product that can evolve without renegotiating meaning on every surface.
In my design-system case studies, the strongest systems created leverage when their foundations connected to real product decisions. Visual consistency was visible; shared understanding was the more valuable infrastructure underneath.
From styling values to shared meaning
Design tokens will continue to control colour, type, spacing and motion. Those foundations remain essential, and tools collected through Design Engineer Tools make increasingly sophisticated systems accessible.
The next opportunity is semantic depth.
When risk, readiness, approval and provenance have stable definitions, interfaces become easier to generate and harder to misunderstand. AI agents can select patterns using purpose rather than appearance. Designers can vary presentation without changing meaning. Engineers can connect states to production behaviour. Product teams can discuss one concept across screens, documents and systems.
The status colour still matters. It simply stops pretending to be the whole decision.
