Structural Design

Design Token

A design token is a named, reusable value that represents a design decision, such as color, spacing, typography, border radius, elevation, or motion, so it can be shared across design tools, codebases, and platforms.

Concept facts

A design token is a named, reusable value that represents a design decision, such as color, spacing, typography, border radius, elevation, or motion, so it can be shared across design tools, codebases, and platforms.

Also known as
Token, design variable, semantic token, style token, component token.
Used in
Design systems, front-end implementation, UI design, component libraries, theming, accessibility review, brand systems, and design-to-code workflows.
Interpret with
Design system, component, visual consistency, component variant, design specification, implementation fidelity, and front-end implementation quality.

Plain-language explanation

A design token turns a design decision into a reusable named value.

Instead of repeatedly using a specific color code, font size, spacing value, or border radius in different places, a team can define a token once and reuse it across components and pages. For example, a service may use tokens for primary button color, body text size, focus outline, form spacing, or error-state color.

Design tokens help design and code speak the same language. They reduce the risk that a design looks correct in one place but changes slightly somewhere else because values were copied manually.

Why it matters

Inconsistent design values create interface drift. Colors, spacing, typography, focus indicators, and component states may gradually differ across pages, templates, or products.

For users, this can create confusion, weak visual hierarchy, accessibility problems, and reduced trust. For teams, it creates maintenance burden, duplicated work, QA issues, and design-to-code mismatch.

In high-friction digital services, design tokens can help keep critical states such as error, warning, success, focus, disabled, selected, and active states consistent across forms, dashboards, applications, and service portals.

Use contexts

Design tokens are used when:

  • a design system needs shared visual and interaction values
  • teams maintain components across multiple pages or products
  • design and front-end teams need consistent implementation values
  • accessibility-sensitive values need control, such as contrast, focus, and spacing
  • a service supports themes, brands, modes, or platform variations
  • design changes need to be updated consistently across a system
  • implementation teams need to avoid hard-coded or duplicated style values

Application guidance

Define tokens around design intent, not only raw values. A token named for purpose is easier to maintain than a token named only for a color code.

Separate global tokens, semantic tokens, and component-specific tokens where the design system requires that structure.

Use tokens for values that need consistency across the system. Do not tokenize every one-off design decision unnecessarily.

Make accessibility-sensitive tokens reviewable. Color, focus, text size, spacing, and state tokens can affect accessibility.

Document how tokens should be used. Designers and developers need to know which token applies to which context.

Test design-token changes before release. A token update can affect many components and pages at once.

Practical example

A public-service application portal uses slightly different red shades for form errors, alert banners, and document-rejection states because each page was implemented separately.

A design-token approach defines shared semantic tokens for error text, error border, error background, focus outline, and warning state. The tokens are used across components and templates.

The UX consequence is more consistent error recognition, lower accessibility risk, reduced implementation drift, and easier QA before release.

Interpretive boundaries

A design token is not the same as a design system. It is one structural part of a design system.

A design token is not only a CSS variable. It is a named design decision that may be used across design tools, code, documentation, and platforms.

A design token should not be treated as a purely technical artifact. Poor token naming, governance, or documentation can create UX inconsistency and implementation risk.

Applied at Userhub

Userhub treats design tokens as a practical foundation for design-system implementation consistency.

In applied design-system work, tokens can help maintain consistent spacing, typography, color, state styling, and accessibility-sensitive values across pages, templates, and components.

See Userhub UX Lab for applied UX research and evaluation context.

Sources and references

W3C Design Tokens Community Group. (n.d.). Design Tokens Community Group. https://www.w3.org/community/design-tokens/

Design Tokens Community Group. (2025). Design Tokens Format Module. https://www.designtokens.org/TR/2025.10/format/

Material Design. (n.d.). Design tokens. https://m3.material.io/foundations/design-tokens

Government Digital Service. (n.d.). GOV.UK Design System. https://design-system.service.gov.uk/

Cite this entry

APA

Userhub. (2026). Design Token. UX Reference. https://userhub.com.bd/reference/design-token/