Design tokens are often used to define colors, typography and other visual attributes. In this article I will explore the idea of extending this principle to define functional languages. Design tokens are not limited to UIs, they expand beyond visuals into motion, accessibility, error handling, notifications, and functional semantics.
Design tokens provide a predictable system that enables consistent communication between designers, developers, and platforms. They can also ensure AI generates personalized interfaces while staying within clear constraints.
Table Of Contents
Beyond Components
I recently worked on few projects where the push for consistency led organizations to centralize UI logic using headless solutions and building libraries as source of truth.
“If everyone uses the same components UIs will always be consistent”
To reduce efforts even the idea of using Web Components to support all platforms emerged. This may work if applied correctly for web only products but when systems expand to multiple platforms(iOS, Android, Windows, Linux) or new requirements such as server-side rendering, accessibility, performance optimization, platform-native features are needed then this approach falls short:
1. Technical
- Web Components don’t integrate naturally with modern server rendering strategies.
- Frameworks (React Native, SwiftUI, Jetpack Compose) can’t use web components directly.
- Every framework needs wrappers and creating duplication and performance issues.
2. Architectural
- Web Components as source of truth ties the product’s future to the limitations of the web component spec preventing adoption of innovations, new patterns and methodologies.
- This encourages building products with different frameworks and libraries which requires more integration tools.
3. UX
- Design evolves with brand, accessibility, and system preferences because they describe intent, not implementation.
- Accessibility isn’t a one-time compliance project, it evolves with regulations, WCAG standards, and user needs.
- Maintaining a color palette or moving to OKLCH for accessibility is trivial with tokens but a major refactor with components as source of truth.
The source of truth cannot be Components(React, Angular, Vue) or Web Components. It must be Design Tokens, not only to define colors and visual preferences but as a categorization system to define the design language, intent and experiences. When defined at that level creating implementation becomes straightforward.
Beyond Design Tokens
Design tokens are often used as variables for colors and typography. But as described above, When used as a design language they become more than just variables. They become the source of truth and primitives for every platform and system.
This means design tokens extend beyond visual attributes to define functional semantics. These can encode motion, accessibility, error handling, notifications, and even product policies.
1. Language Definition
Creating tokens as design language can be challenging at first after all is about abstracting functionality outside of visuals. Classifying them into categories helps describe product experiences and separating concerns.
Here is a basic example that includes visual, motion, accessibility, functional, and policy semantics using JSON(friendly platform agnostic format):
2. System Integration
Design tokens will continue to evolve as new platforms, technologies, and methodologies emerge. The key is to maintain them in a platform-agnostic format(JSON, YAML, XML) with their own packaging and versioning then use transforms to generate platform-specific bindings(CSS, Swift, Kotlin).
3. Functional Implementation
When embracing the same concept as we encode more functionality, the more adaptable and resilient our design system becomes. Functional implementation ensures that tokens are not just static values but dynamic properties that respond to context, user needs, and platform capabilities.
Conclusion
Design tokens should be seen not as static values, but as a semantic framework for systems. By classifying visual, behavioral, and functional semantics in one shared language, tokens become the architecture of product language, bridging design intent, user experience, and functional implementation across every platform.
Implementing design languages help communicate across teams from different areas and create a shared understanding of product behavior and appearance. I think the idea of removing hardcoded values from servers, platforms, frameworks, and libraries to a single repository(JSON design language) is the future of design systems and automation.
Read on my blog:
Beyond Components and Design Tokens – Will Medina
Design tokens started as a method to centralize colors, typography and other visual aspects. The same classification principle applies to how we define interactions, features, and APIs. Design tokens are not limited just to user interface design, they can be used as a categorization system of functional software across platforms.
willyelm.com
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.