Two token layers are cheap. The third one is where teams start arguing. Design tokens beyond semantics — past primitives and meaning — have to be named, owned, documented and kept in sync, and that maintenance is the real cost of a token structure, not the tooling subscription.
Figma‘s release notes for September 2026 show how much of that structure now lives inside the design file itself. Specify’s own product page describes a different bet: pull tokens from wherever they already are and push them out in whatever shape your codebase wants. Those are two answers to the same question, and the answer you pick decides how many layers you can afford.
What each token layer actually costs
Primitives are raw values. Semantics are meaning. Anything past that — component tokens, theme tokens, brand overrides — is a third layer, and a third layer means a third place a value can be wrong.
The cost isn’t the naming. It’s the sync. Every layer multiplies the number of places a change has to land, and every place a change has to land is a place a designer or engineer has to remember to look.
- One layer: fast to set up, impossible to theme. Fine for a single product with one brand.
- Two layers: the standard advice, and usually the right stopping point for a team under about five designers.
- Three or more: justified when you ship multiple brands, multiple platforms, or a white-label product — and only then.
If you can’t name the specific product or client that needs the third layer, you don’t need it yet. You need a naming convention and a review step.
Where Figma now sits in that structure
Figma has been moving token control into the variables modal. The September 3, 2026 release note describes updating opacity at scale in the variables modal, aliasing opacity while a colour stays linked to its library, and setting opacity on a colour variable using a number variable scoped specifically for colour variables.
That matters for structure because it’s the difference between a value that stays connected to the library and one that gets detached and hand-adjusted. Every detach is a token that quietly stopped being a token. Disabled states, overlays and scrims are the usual casualties.
The same release window also covers generative plugins and shaders — animation and interaction, publishing to the Community, publishing privately to an organisation on Organization and Enterprise plans, a code viewer, and MCP updates so a third-party agent can view and change shaders and generative plugins. If your design system already has a plugin layer, that’s a second surface to keep consistent with your tokens.
Specify’s bet: your tokens, your structure
Specify‘s product page describes centralising tokens from Figma Styles, Figma Variables, Tokens Studio, or your own JSON file, and says it supports over 50 token types. It lists native compatibility with Figma, GitHub, Notion and Raycast, plus a REST API and CLI, and open-source parsers for generating tokens and assets to match company standards.
The pitch is that you keep your structure and Specify moves values through it, including automated pull requests through the GitHub integration. For a team that already has a token shape it likes, that’s the opposite of adopting a tool’s opinion about layers.
What it doesn’t do is decide how many layers you need. No tool does. That’s a team decision, and it’s the one that costs money.
The comparison that actually decides it
All four tools in this space touch tokens. They don’t touch the same part of the problem.
| Tool | What it does with tokens | Best for | The catch |
|---|---|---|---|
| Figma | Variables, aliasing and scoping live in the design file; opacity can be aliased without detaching | Teams whose source of truth is the Figma file | Structure is only as good as the file’s hygiene; detaching still breaks the chain |
| Specify | Centralises tokens from Figma Styles, Variables, Tokens Studio or JSON; 50+ token types; REST API, CLI, GitHub PRs | Teams with an existing token shape and a codebase to feed | You bring the structure — it won’t tell you how many layers you need |
| Supernova | Documentation and token pipeline in one place | Teams that need the docs to ship with the tokens | Another system to keep current when the tokens change |
| Zeroheight | Design-system documentation as the primary artefact | Teams whose bottleneck is explaining the system, not generating it | Documentation drifts the moment nobody owns the update |
Read the table as a question, not a ranking. Where does your system break first — the file, the pipeline, the docs, or the explanation? Fix that one.
What this means if you’re a product designer
You’re the person who’ll be asked why the button is the wrong blue in one place. So the decision rule is blunt.
Stay at two layers if you ship one product, one brand, and one platform. Spend the saved effort on naming and on a review step that catches detached values.
Add a third layer if you can name the second brand, the second platform, or the client who needs the override. Not before.
Pick tooling after the structure, not before. If your tokens already have a shape, Specify’s centralise-and-export model fits. If the Figma file is the source of truth, the variables work is where your leverage is. If nobody can find the rules, Zeroheight or Supernova is the gap.
What to check before you commit
Run one real change through the whole chain and watch where it breaks. Pick a colour that appears in a disabled state, an overlay and a scrim, change it once, and follow it to code.
If it arrives intact, your layer count is right. If you find yourself opening three files and a pull request to fix one value, you’ve found the layer that’s costing you — and it’s usually the one nobody agreed to own.
Sources
- Figma release notes — variables, opacity aliasing, generative plugins and shaders, MCP updates.
- Figma blog — Weave tools and Community publishing context.
- Specify — token sources, 50+ token types, integrations, REST API and CLI.
122 ready-to-use AI prompts — organised by discipline and category, each copyable in one click, free and no sign-up needed. Browse the prompt library →