Product design scoping in 2026: 7 deliverables that decide whether design survives engineering

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

What is the Design Tokens Specification and is it a standard?

It is an open, vendor-neutral format for expressing design decisions such as colour, typography and spacing so they can move between design tools and code. The Design Tokens Community Group announced version 2025.10 as the first stable version on 28 October 2025. It is a W3C Community Group specification, not a W3C Standard.

Which tools support the stable design token format?

Reference implementations exist in Style Dictionary, Tokens Studio and Terrazzo. The October 2025 announcement states that more than 10 design tools and open-source projects already support or are implementing the standard, naming Penpot, Figma, Sketch, Framer, Knapsack, Supernova and zeroheight among them. Check current support before committing to a pipeline.

Do we have to meet WCAG 2.2 or WCAG 2.1?

It depends on the jurisdiction. The European harmonised standard EN 301 549 referenced WCAG 2.1 at the time of writing, with an update process started. India's GIGW 3.0 requires WCAG 2.1 Level AA. Designing to WCAG 2.2 Level AA clears both, since 2.2 builds on 2.1.

Does the European Accessibility Act apply to an Indian company?

It applies to products and services placed on the European Union market, so an application built in India and sold to European customers falls within scope. The Act took effect on 28 June 2025. Scope accessibility to the stricter of your target markets rather than to your home market.

How long does a design system engagement take?

For a typical multi-surface product, discovery and audit take one to two weeks, foundations two to three, core components four to eight, conformance one to two, and handover one. Application screen design runs alongside and varies by surface count. The sequencing matters more than the durations.

When is a design system not worth building?

For a single-surface prototype testing a hypothesis, it is overhead. The investment starts paying back at roughly two surfaces, two platforms or two brands. Below that threshold, design the screens, ship them, and revisit the system when the second surface appears.

Who should own the design system after handover?

A named person inside your organisation, with a documented merge and review process for token changes and a versioning policy for breaking changes. Systems without an owner revert to screenshot-driven design within about two quarters, and the earlier investment is lost.

What should be in the statement of work?

Seven items: a token file in the 2025.10 format with a working build pipeline, component contracts covering all states, a WCAG 2.2 Level AA audit report per criterion, a written component library decision, performance budgets, content and localisation rules including scripts, and a maintenance model with a named owner.

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.