On this page · 8 sections
Summary. On 28 October 2025 the Design Tokens Community Group announced the first stable version of the Design Tokens Specification, version 2025.10, developed by more than 20 editors and authors from organisations including Adobe, Google, Microsoft, Meta, Salesforce, Shopify, Figma and Sony. Reference implementations exist in Style Dictionary, Tokens Studio and Terrazzo, and more than 10 design tools including Figma, Sketch, Framer, Penpot, Knapsack, Supernova and zeroheight support or are implementing it. That changes what a design engagement should deliver. WCAG 2.2 was published on 5 October 2023, updated on 12 December 2024, and approved as ISO/IEC 40500:2025; the European Accessibility Act took effect on 28 June 2025; India's GIGW 3.0, issued by the National Informatics Centre under MeitY, requires conformance with WCAG 2.1 Level AA for government websites under the Rights of Persons with Disabilities Act, 2016. Design work scoped as screens fails all three tests. Design work scoped as tokens, component contracts and conformance evidence passes them.
The gap between a beautiful Figma file and a shipped product is not talent. It is the statement of work.
Why "screens" is the wrong unit
A design engagement priced per screen produces exactly what it is priced for: screens. Engineering then reverse-engineers intent from pixels, invents the values the file did not specify, and the two artefacts drift apart within one sprint. Every team that has run this loop knows the symptoms. Three greys that should have been one. A button that is 40 pixels tall in six places and 44 in the seventh. A dark mode that was never designed and gets approximated in code.
None of that is a designer failing. It is a specification failing. Screens describe instances; software needs the rules that generate them.
The Design Tokens Community Group put the problem plainly in its announcement: design tokens "have long been fragmented across proprietary formats. Teams maintaining multi-brand design systems often juggle dozens or even hundreds of token files manually, leading to drift, errors, and maintenance overhead."
"The specification unlocks interoperability across design tools and code," said Kaelig Deloumeau-Prigent, co-chair of the Design Tokens Community Group. "Design systems teams can now maintain one source of truth that works everywhere, from design to production code across iOS, Android, and web."
One accuracy note that most coverage skips: the Design Tokens Specification is published by a W3C Community Group. It is not a W3C Standard and it is not on the W3C Standards Track. It is an open, vendor-neutral industry specification with broad tool support, which is what matters commercially, but do not write "W3C standard" into a contract.
The seven deliverables
1. a token file, in the stable format
Not a colour palette image. A machine-readable token file in the 2025.10 format, checked into the repository the application is built from, with a build step that generates platform code from it.
Version 2025.10 added the capabilities that make this practical at scale: theming and multi-brand support so light mode, dark mode, accessibility variants and brand themes live in one system rather than duplicated files; full support for Display P3, Oklch and the CSS Color Module 4 spaces; inheritance, aliases and component-level references; and cross-platform generation for iOS, Android, web and Flutter from a single file.
"By solving multi-file support, theming, and including advanced color support, it unlocks an agnostic design systems and tooling ecosystem," said Mike Kamminga from Tokens Studio.
Acceptance test for this deliverable: an engineer changes one token value, runs the build, and the change appears on web, iOS and Android without anyone editing a stylesheet.
2. a component contract, not a component picture
For each component, the states, the variants, the responsive behaviour and the failure modes. Empty state, loading state, error state, long-content state, and the specific translated strings that will break the layout. Designers reliably deliver the happy path; the other four states are where engineering estimates go wrong.
Write the contract as a table your developers can check off. If a component ships without its error state designed, that is a defect in the design deliverable, not a "polish item" for later.
3. Accessibility conformance, with evidence
This is now a legal deliverable in three jurisdictions that Indian product teams routinely sell into.
| Framework | Status and date | What it references | Who it binds |
|---|---|---|---|
| WCAG 2.2 | Published 5 Oct 2023, updated 12 Dec 2024 | The guidelines themselves | Voluntary baseline globally |
| ISO/IEC 40500:2025 | WCAG 2.2 approved as an ISO/IEC standard | WCAG 2.2 | Referenced in procurement |
| European Accessibility Act | In effect 28 June 2025 | EN 301 549 | Products and services on the EU market |
| EN 301 549 | Update process started | WCAG 2.1 at time of writing | The harmonised EU standard |
| GIGW 3.0 (India) | Issued by NIC under MeitY | WCAG 2.1 Level AA | Indian government websites and apps |
Two things follow. First, the EU harmonised standard and the newest WCAG version are not the same thing; EN 301 549 references WCAG 2.1 and the update process to a later version has started but was not complete at the time of writing. Design to WCAG 2.2 Level AA and you clear both. Second, "we followed accessibility best practice" is not evidence. The deliverable is an audit report against numbered success criteria with pass, fail or not-applicable per criterion.
Colour contrast is the criterion that most often forces a token change late, which is precisely why it belongs in deliverable one rather than a remediation project afterwards. We cover the remediation path in our note on accessibility audits and remediation.
4. a library decision, made once, in writing
Which component library the tokens compile into is a decision with a five-year tail, and it should be made deliberately in week one rather than defaulted by whoever writes the first component. We laid out the trade-offs in our comparison of Astryx, shadcn/ui and MUI for React design systems, and for cross-platform work the same question recurs in our note on the Material and Cupertino package migration in Flutter.
5. Performance budgets attached to design decisions
A hero image specification, a font loading strategy and an animation budget, agreed before the design is signed off rather than negotiated during a Core Web Vitals panic. Typography choices in particular are a performance decision disguised as an aesthetic one: every additional weight and script is a font file. Our Core Web Vitals engagement notes cover the measurement side.
6. Content and localisation rules
Maximum string lengths per component, the languages in scope, and whether the layout has to survive Devanagari, Tamil and a right-to-left script. For an Indian consumer product this is not a nice-to-have; it is the difference between one design system and three.
7. a maintenance model with a named owner
Who merges a token change. What the review looks like. How a breaking change is versioned and communicated. A design system without an owner reverts to screenshots within two quarters, and the investment is written off quietly.
What a well-scoped engagement actually looks like
| Phase | Duration guide | Primary output | How you know it worked |
|---|---|---|---|
| Discovery and audit | 1 to 2 weeks | Inventory of existing patterns, accessibility baseline | You can count the greys and the button heights |
| Foundations | 2 to 3 weeks | Token file in the 2025.10 format, build pipeline | One token change propagates to all platforms |
| Core components | 4 to 8 weeks | Component contracts and built components | Contracts include all five states |
| Application design | Varies by surface | Screens, composed from the system | Zero one-off values introduced |
| Conformance | 1 to 2 weeks | WCAG 2.2 AA audit report per criterion | Pass, fail or N/A recorded for every criterion |
| Handover | 1 week | Documentation, ownership model, versioning policy | A named owner exists |
The order matters more than the durations. Application screens designed before the tokens exist will contain values that are not in the system, and every one of those becomes a negotiation later. Teams that insist on seeing screens in week one usually pay for the foundations phase twice.
The honest counterpoint: if you are building a single-surface prototype to test a hypothesis, all of this is overhead. Design the screens, ship, learn. The system pays for itself at roughly the point where you have two surfaces, two platforms or two brands, and not before. Our SaaS MVP engagements deliberately skip most of the list.
India-specific considerations
Indian product teams sit in an unusual position: building for a domestic market with no comprehensive private-sector digital accessibility mandate, while frequently selling into markets that have one.
GIGW 3.0, issued by the National Informatics Centre under the Ministry of Electronics and Information Technology, requires conformance with WCAG 2.1 Level AA and covers web accessibility, mobile app accessibility and cybersecurity. It aligns with the Rights of Persons with Disabilities Act, 2016, under which Section 42 requires appropriate government bodies to ensure information and communication technology is accessible to persons with disabilities. If you sell to government, this is your floor.
If you sell into the European Union, the European Accessibility Act has been in effect since 28 June 2025 and reaches products and services placed on the EU market, which includes an app built in Gurugram and sold in Berlin. Scope for the stricter of the two from the start; retrofitting accessibility into a shipped design system costs several times what designing to it costs.
Language coverage is the other India-specific line item. A component library validated only against Latin script will break on Devanagari ascenders and Tamil line heights. Put the scripts in the statement of work, and test them during the foundations phase rather than at launch.
And on data: where a design collects personal information, the consent and notice patterns are design work, not legal work handed to design at the end. The Digital Personal Data Protection Act 2023 obligations shape form flows, and it is cheaper to design them once than to bolt a consent modal onto a completed journey.
What we get wrong, and what we have learned
The most expensive mistake we see is starting the token file after the screens are approved. It feels efficient because stakeholders get to see something quickly, and it guarantees a reconciliation phase nobody budgeted for.
The second is treating accessibility as a QA gate rather than a design constraint. By the time a build reaches QA, the contrast failures are in the brand palette, and fixing them is a brand conversation, not a bug fix.
The third is the unowned system. A design system is a product with users, and products without owners decay. The maintenance model is the deliverable that determines whether the other six still exist in a year.
Design that survives engineering is not prettier design. It is design that arrives as a specification.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based technology consultancy, founded in 2021 and assessed at CMMI Level 5, with senior-led multi-disciplinary teams that design and build production software rather than handing over files. We scope design engagements around tokens, component contracts and conformance evidence, build the pipeline that compiles them onto web, iOS, Android and Flutter, and design applications aligned with WCAG 2.2 Level AA and Digital Personal Data Protection Act requirements. If you are commissioning product design or trying to rescue a design system that stopped being used, talk to our team. We also run accessibility audit and remediation and QA and test automation engagements.
References
- Design Tokens specification reaches first stable version, Design Tokens Community Group, W3C, 28 October 2025.
- Design Tokens Format Module 2025.10, Design Tokens Community Group.
- Design Tokens Technical Reports, Design Tokens Community Group.
- Design Tokens Community Group home, Design Tokens Community Group.
- WCAG 2 Overview, W3C Web Accessibility Initiative.
- Web Accessibility Laws and Policies: European Union, W3C Web Accessibility Initiative.
- Web Accessibility Directive: Standards and harmonisation, European Commission.
- The EAA comes into effect in June 2025. Are you ready?, AccessibleEU, European Commission, 31 January 2025.
- What's new in the Design Tokens spec, zeroheight.
- Plans and pricing, Figma.
Last updated: 23 July 2026.
