What Is W3C DTCG?
W3C DTCG stands for World Wide Web Consortium Design Token Community Group. In plain English, it's a group of design system practitioners (from companies like Google, Adobe, and Salesforce) who agreed on a standard way to structure and name design tokens so they work across tools and platforms.
Before the standard, every company had their own token naming convention. Figma used one format. React used another. iOS used a third. A token called color.primary.blue in one place might be colorPrimary in another. Translation errors multiplied. Tokens didn't sync.
The W3C DTCG standard says: "Here's the format everyone should use." It's not a law. It's consensus. And more importantly, it's what Figma, Storybook, and most modern tools have built around. Using it means your tokens will work with tools instead of against them.
Why the Standard Matters for Your Fintech Startup
You have three platforms (web, iOS, Android). Each platform has different technical requirements. Without a token standard, your color palette is documented in Figma one way, shipped in React another way, and CSS variables a third way. Changes become a coordination nightmare.
The W3C DTCG standard solves this by defining one canonical token structure. Export tokens from Figma as a tokens.json file, and tools like Tokens Studio automatically convert it to CSS variables, SCSS maps, iOS swiftUI code, and Kotlin enums—all from a single source.
One definition. All platforms. No manual translation. That's the power.
The 3-Tier Token Architecture
The standard defines three tiers of tokens, each serving a different purpose:
Tier 1: Primitive (or Global) Tokens
These are raw values. Colors, spacing units, font sizes, border radius values. They have no semantic meaning. They're just numbers and hex codes.
Tier 2: Semantic (or Semantic) Tokens
These are tokens that reference primitives and have meaning. "Primary text color" (which maps to gray.900). "Border color" (which maps to gray.200). "Success green" (which maps to green.500). Semantic tokens are the bridge between design intent and implementation.
Tier 3: Component Tokens
These are tokens that reference semantic tokens and control individual components. "Button primary background" (which maps to semantic.interactive.primary). "Button primary text color" (which maps to semantic.text.inverse). Component tokens are the contract between your design system and your component library.
This three-tier structure is powerful because changes ripple upward, not downward. If you decide blue needs to be darker, you change one primitive blue.500 value, and every component using semantic.interactive.primary automatically updates. No manual refactoring.
Setting It Up in Figma
Figma doesn't have native token support, but Tokens Studio (a free Figma plugin) speaks W3C DTCG natively. Here's how to set up:
1. Install Tokens Studio
Open Figma, go to Plugins > Browse plugins > search "Tokens Studio" > install.
2. Create your tokens.json file
In your repo, create tokens/tokens.json with the three-tier structure above. Use GitHub or sync it to a design tokens repository.
3. Import into Tokens Studio
Open Tokens Studio in Figma. Link your GitHub tokens.json file. Tokens Studio will read it and expose all tokens as Figma variables.
4. Apply tokens to components
In Figma, select your Button component. In the Tokens Studio panel, apply component.button.primary.background to the button's fill color. Text color gets component.button.primary.text. Now when you export tokens.json, Figma is the single source of truth.
5. Export for code
Tokens Studio has plugins for React, CSS, SCSS, iOS, Android. Pick your targets. Export. Your button component now has CSS variables ready to use:
Exporting to tokens.json
The real magic is when tokens.json becomes your API contract between design and code. Here's the workflow:
Designer changes a token in Figma. They adjust semantic.text.primary from gray.900 to gray.800. They export tokens.json to the repo via GitHub.
Developers pull main. Their CSS variables automatically update. No manual work. No Slack conversations. The change just works.
iOS team does the same. They run their token export script (Tokens Studio has Swift templates), and their swiftUI code gets new color values.
Android team updates their Kotlin enums. Same file, different export template.
One source of truth. Three platforms. No coordination overhead.
Common Pitfalls to Avoid
Pitfall 1: Too many primitives. Naming gray-50, gray-100, gray-200, gray-300... for 15 shades is overkill. For a fintech startup, 4–6 core grays (light, regular, dark, etc.) are enough. Build more only when you need them.
Pitfall 2: Confusing semantics and components. Don't name a semantic token "button-primary-bg"—that's a component token. Semantic tokens describe intent: "interactive.primary", "text.secondary", "border.divider". Component tokens describe use: "button.primary.background".
Pitfall 3: Skipping the middle tier. Some teams jump straight from primitives to component tokens. Big mistake. Semantics are where design decisions live. Without them, changing "all primary buttons" requires touching dozens of component tokens. With semantics, you change one value: interactive.primary.
Pitfall 4: Token explosion. Don't create a token for every possible value. Start with 20–30 tokens. Add more only when a component can't be built with existing tokens. Discipline is the feature.
Getting Started This Week
You don't need a perfect setup to start. Build the three-tier structure for color and typography. Export from Figma. Run through one platform (web). See if it works. Fix it. Scale to the other platforms.
This is how the 7-Day AI Architecture Sprint approaches tokens—practical, incremental, standards-based. You'll have a working token architecture by the end of the week, not a theoretical one.
Standards matter. Use them.