For years, design tokens sounded simple: replace a hex value with a name and call it a system. In practice, teams ended up with three sources of truth—a Figma library, a code repository, and a spreadsheet nobody wanted to delete.
That era is finally starting to close. The Design Tokens Community Group released the first stable version of its specification, 2025.10. The format is vendor-neutral and designed to move decisions across design tools, web, iOS, Android, and other platforms. The interesting part is not the JSON. It is what standardization lets product teams stop arguing about.
Tokens are decisions, not colors
A token should explain intent. blue-500 describes a value. color.action.primary describes a job. That difference becomes critical the moment a product supports dark mode, multiple brands, accessibility themes, or a visual refresh.
Atlassian’s design system frames tokens as a single source of truth for repeatable design decisions. Its guidance is practical: choose tokens based on meaning, not because two colors happen to look alike. A semantic name survives redesigns; a visual name usually becomes technical debt.
A three-layer architecture that scales
The most useful token systems separate decisions into three layers:
- Primitive tokens hold raw values such as color, spacing, radius, typography, and motion.
- Semantic tokens describe purpose: surface, text, border, action, success, warning, or danger.
- Component tokens capture intentional exceptions for a button, input, card, or navigation pattern.
This structure gives teams a controlled escape hatch. Most components consume semantic tokens. Component-level tokens appear only when a pattern genuinely needs its own contract. The result is flexibility without turning every pixel into a global API.
A healthy token system makes the correct decision easier than the locally convenient one.
Accessibility belongs in the source of truth
Accessibility checks should happen before tokens reach components. WCAG 2.2 requires at least 4.5:1 contrast for normal text and 3:1 for large text under Level AA. The official W3C contrast guidance also warns that threshold values should not be rounded.
That makes token validation far more valuable than auditing hundreds of screens after release. A pipeline can reject an inaccessible text-and-surface pairing once, before it spreads through every product.
The governance loop matters more than the file format
A design system becomes dependable when contribution is predictable. Every token proposal should answer four questions:
- What user or product problem does this decision solve?
- Is an existing semantic token already appropriate?
- How does the change behave across themes and platforms?
- Who owns migration, documentation, and eventual deprecation?
Pair that review with automated naming checks, reference validation, visual regression tests, and release notes. Governance should feel like a paved road, not a committee meeting.
A practical 30-day rollout
Week 1: inventory repeated decisions and hard-coded values. Do not tokenize everything.
Week 2: define primitives and a small semantic layer around text, surfaces, borders, and actions.
Week 3: connect one design library and one production surface through an automated transformation pipeline.
Week 4: validate accessibility, document contribution rules, and measure adoption.
The real milestone
The stable DTCG release supports richer relationships, theming, modern color spaces, and cross-platform consistency. It is an important foundation—but a specification cannot create trust on its own.
The best design systems make change safe. When a product team can update a decision once, understand its impact, and ship it everywhere with confidence, tokens have done their job. At that point they become boring infrastructure—and that is exactly the goal.