By now you can define a token, name it, and structure it in three tiers inside Figma. That is the design half. The other half is a build problem, and it is where most systems quietly rot. The token layer in the design file and the hand-typed values in the codebase drift apart because nothing connects them. The pipeline is what connects them: a one-directional supply chain that carries a decision from the place designers make it to every place code consumes it. It is what keeps a system true instead of turning it into a museum of what the brand used to look like.
It is also the commercial spine of the tier. When you sell a design system you are not selling a Figma file, you are selling a pipeline and an asset the client keeps. Get the plumbing right and the same four brands you built in Lecture 7 re-skin themselves from a JSON file. Get it wrong and you have sold a very expensive picture.
The pipeline in four hops
The end-to-end path has four hops. Each hop has one job, and the seams between them are where portability and automation live. Read it as a supply chain running from the raw decision to the shipped platform code.
| Hop | Artefact | What it is, and its one job |
|---|---|---|
| 1 · Author | Figma variables (primitives + semantic collections, brand as mode) | The human decision surface. Designers pick and re-point values here; nothing downstream is edited by hand. |
| 2 · Export | DTCG JSON (.tokens.json) | The vendor-neutral source of truth. $type / $value, aliases preserved as {group.token}. This is the asset the client owns. |
| 3 · Transform | Style Dictionary config + build | The engine. Reads the DTCG file, resolves aliases, and emits one output per platform. Runs in CI, never by hand. |
| 4 · Consume | CSS custom properties · Tailwind theme · Storybook | Platform code. Components bind to these; they never see a raw hex or a Figma URL. |
The key property of this chain is that each hop only knows about the artefact immediately before it. Style Dictionary does not know Figma exists, it reads JSON. Your React components do not know Style Dictionary exists, they read CSS variables. That decoupling is what lets you swap any hop, change design tool, change transform engine, or add a platform, without rewriting the others. It is the same separation-of-concerns instinct Godbolt built his architecture on, applied to the value supply chain.
Hop 2, and why it must be DTCG
The single most important decision in the pipeline is the format of hop 2. It could be any JSON you invent, but it should be the W3C Design Tokens Community Group format, which reached its first stable version, Design Tokens Format Module 2025.10, on 28 October 2025. Be precise with clients about its status. It is a Community Group Report, not yet a formal W3C Recommendation, but it is the format the whole tool ecosystem has converged on.
A DTCG token is JSON with a reserved $type and $value, an optional $description, and aliases written as curly-brace references. Frost's three tiers become data:
"color-bg-action": { "$value": "{color.blue.600}", "$type": "color" }: the semantic token ships the alias, not a resolved hex. Style Dictionary resolves {color.blue.600} at build time. That indirection survives every hop of the pipeline.
The format covers primitive types (color, dimension, font family, font weight, duration, cubic-bezier, number) and composite types (shadow, border, transition, stroke style, gradient, typography), and it speaks modern colour spaces such as Display P3 and Oklch. Figma, Tokens Studio, Style Dictionary, Penpot, Sketch, Terrazzo and Framer all adopt it, which is why it makes the right seam: it is the one artefact every other tool already reads and writes.
The selling and handoff argument. This is the core of the commercial pitch, not a technical nicety, so learn to say it plainly. A DTCG file is not locked to Figma and not locked to your agency. Figma exports and imports it natively, and any transform engine consumes it. When you hand a client a .tokens.json, you hand over a portable asset the client owns, not a dependency on you. A proprietary export tied to one plugin or one studio is lock-in dressed as a deliverable. DTCG lets you sell a client their own design language rather than rent it to them. On enterprise work this line wins the contract, because procurement understands owning an asset far better than owning a Figma file.
Hop 3: Style Dictionary, and the Theo lineage
The transform engine is where a single source value becomes many platform values. Its history matters, because it tells you this is a solved, mature problem rather than a bet. The category was invented at Salesforce, where Jina Anne's team coined design tokens (c. 2014) and Sönke Rohde built Theo, the first transform tool. Style Dictionary is Theo's successor, the modern framework-agnostic build system that reads tokens and emits platform-specific output. When Jina says tokens are a methodology and not just variables, this hop is what she means: store the value once, transform it per platform.
Concretely, one DTCG source drives a fan-out. The same color-bg-action becomes a CSS custom property (--color-bg-action: #2563eb;), a Tailwind theme entry, an SCSS variable, an iOS or Android constant, whatever platforms you register, from one file, in one build. Adding a target means adding an output format to the config, not a new copy of the values. Style Dictionary resolves the aliases, applies transforms (hex to rgba, px to rem, name casing), and writes the files. This is also why Frost calls tokens the tech-agnostic layer: keep them in a standalone DTCG file, transform with Style Dictionary to any target, and the token layer outlives whichever framework you happen to ship this year.
When native export is not enough: Tokens Studio
Figma's native DTCG export handles a straightforward primitives-plus-semantic setup fine. Reach for Tokens Studio (the Figma plugin) when the native path hits its limits, which happens in three cases:
- Composite tokens. Typography, shadow, border and gradient tokens that bundle several sub-values into one named entity are Tokens Studio's home turf and map directly onto DTCG composite types.
- Token set inheritance. Tokens Studio organises tokens into sets that can be layered and overridden, which is a cleaner model for brand-on-base and mode-on-brand composition than raw Figma collections when the theming graph gets deep.
- Git sync. Tokens Studio can push and pull the token JSON directly to a GitHub (or GitLab) repository, which is the feature that makes the next section's decision, source of truth, actually enforceable.
The rule: start native, and adopt Tokens Studio once composite tokens, set inheritance or Git sync earn their keep. It sits at hop 1.5, between authoring and the JSON, and its output is still DTCG, so it changes the ergonomics of feeding the pipeline without changing its shape.
Source of truth: Figma or Git, pick one
The pipeline has two plausible starting points, and the fatal mistake is allowing both. Either Figma is the source of truth and the JSON is generated from it, or Git is the source of truth and Figma is fed from it. Let both edit the tokens independently and they will diverge, and you are back to the drift the pipeline existed to kill.
| Model | Source of truth | Flow, and who it fits |
|---|---|---|
| Design-led | Figma variables | Designers edit in Figma; export regenerates the JSON; Git is downstream. Fits design-driven teams and the solo/junior case. Round-trip edits into Figma are the risk. |
| Code-led | Git .tokens.json | Tokens edited as JSON (often via Tokens Studio + Git sync), Figma pulls them in. Fits engineering-heavy orgs where CI owns the truth. |
This is where one-way versus round-trip gets decided. A one-way pipeline (Figma to JSON to code, and never back) is far simpler and is the correct default: fewer moving parts, no reconciliation, no merge conflicts between a designer's edit and a git commit. Round-tripping, keeping Figma and Git bidirectionally in sync, is genuinely hard and worth attempting only once a clear owner and a conflict-resolution rule exist. For most client work, and certainly for a solo build, choose Figma as source of truth and a one-way flow. The pipeline is simpler, the failure modes are fewer, and the drift is still gone because nobody hand-edits downstream.
Automate the transform in CI
A pipeline that a human has to remember to run is really just a chore, and chores get skipped under deadline. The transform must run automatically. This is the heart of Godbolt's process pillar: a build system exists not only to codify the process but to enforce it.
The task runner empowers frontend architects to create a blueprint for the site's creation. Each of the four pillars is wrapped in automation, because it is through automation that we can not only codify our process, but also enforce it.
Micah Godbolt“Frontend Architecture for Design Systems”, O'Reilly, 2016: The Task RunnerIn practice: the exported DTCG file is committed to the repo; a CI job (GitHub Actions, or Jenkins/TravisCI in Godbolt's day) runs the Style Dictionary build on every change; the generated CSS/Tailwind/Storybook outputs come out of the pipeline, never edited by hand, and ideally never even committed by hand. A token change becomes a pull request whose diff you can review. That is the payoff: a colour decision is now a versioned, reviewable, automatically-propagated event, not a rumour passed between a designer and a developer.
Naming must survive the pipeline
Every hop is a serialisation. A Figma variable named color/action/background becomes a JSON path color.action.background becomes a CSS custom property --color-action-background becomes a Tailwind key. If your names are appearance-based (color-blue) or inconsistent in delimiter and case, the pipeline carries the mess faithfully all the way to production, and Style Dictionary's name transforms can only paper over so much. This is Lecture 3's taxonomy cashing out. A name is an identifier, not a label, and it has to stay stable and machine-legible across four representations. Decide the casing and delimiter convention once, at hop 1, and let the transform derive every platform's variant deterministically. Rename a token casually and you have silently broken every consumer downstream.
Godbolt's four pillars, and what has aged
Godbolt's 2016 Frontend Architecture for Design Systems predates Figma variables, DTCG and Style Dictionary, yet its skeleton is the skeleton of everything above. His frame is four pillars of frontend architecture, in his words “the foundation of a scalable and sustainable design system.”
These pillars in no way prescribe the only way to do something, or even the best way to do something. Each decision needs to be made in the context of the project that you are in. Sometimes the decision will be to not do anything!
Micah Godbolt“Frontend Architecture for Design Systems”: Working with the Four PillarsThe four are code (how you approach the HTML, CSS and JavaScript of a system), process (the build tools and workflow that make it efficient and error-proof), testing (ensuring “any code we wrote yesterday isn't devalued by the code we write today”), and documentation, which he insists be “written at the same time as the process or artifact being developed,” not in the panic when a key person is about to leave. They map onto the pipeline cleanly: the DTCG format and naming are the code pillar, CI is the process pillar, visual regression is the testing pillar, and a living token reference is the documentation pillar.
Now the honest part, which is the part clients pay you for. Some of the 2016 specifics have aged. The architecture underneath has not.
| Aged (the specific 2016 tooling) | Timeless (the principle it served) |
|---|---|
Grunt/Gulp task runners; his own @micahgodbolt/grunt-phantomcss | Automate and enforce the build in CI. The runner changed; the mandate did not. |
| Hand-authored Sass partials, OOCSS / SMACSS / BEM class conventions | Modular, single-source-of-truth styling: “every class can be traced back to a single set of CSS properties.” Tokens are the same idea one layer up. |
| PhantomCSS with a headless browser for pixel diffs | Visual regression as a merge gate: capture the approved pixels, block any unapproved deviation before commit. |
| Hologram pulling docs from Sass comment blocks | Documentation generated from the source, written alongside the artefact, never bolted on later. |
Godbolt's most durable contribution is the testing pillar applied to appearance. His argument for visual regression testing is exactly the guarantee a token pipeline needs. You are not asserting that a function returns the right value, you are “capturing the visual appearance of an approved design system and validating that we have not deviated from that system.” Wire visual regression onto the end of your pipeline and a token change that accidentally makes a button unreadable fails the build. That closes the loop: the pipeline propagates the change, and the test proves it was safe.
The four pillars are the seam Tier III is built along. Lecture 8 is Godbolt's code and process pillars (format, naming, CI). Lecture 10 is his documentation pillar. Governance in Lecture 11 is testing-as-gate. The 2016 tools are gone; the four conversations he says every project must have are the same ones you will have on every build.
✕ The five ways the pipeline breaks
- Two sources of truth. Both Figma and Git editable independently. They diverge, and drift is back. Pick one.
- Hand-editing generated output. Someone tweaks the built CSS directly; the next build silently reverts it. Generated files are read-only by convention.
- Attempting round-trip too early. Bidirectional Figma/Git sync without an owner and a conflict rule creates more work than manual retyping ever did.
- Proprietary export as the handoff. A plugin-locked format instead of DTCG hands the client lock-in, not an asset, and kills the commercial argument.
- Unstable names. A casual rename at hop 1 breaks every downstream consumer, because the name is the contract across all four representations.
The panel: where the pipeline authorities agree and diverge
Godbolt supplies the architecture: four pillars, automation that enforces, visual regression as the merge gate, vendor-agnostic by design. Jina Anne supplies the doctrine that tokens are a methodology transformed per platform, not variables, which is the whole justification for hop 3. Frost supplies the tiering the DTCG aliases encode and insists the token layer stay tech-agnostic in its own repo. The DTCG spec supplies the neutral format that makes the chain portable and the client's asset ownable. The tension to carry is that Godbolt leans code-and-CI-first (a Git-leaning source of truth) while a Figma-led design team keeps the source of truth in the design file. Both work, but pick one per project and never both. For a solo or junior build, go Figma-source, one-way, native export first, and adopt Tokens Studio only when composite tokens or Git sync demand it.
The pipeline is a one-way supply chain, Figma to DTCG to Style Dictionary to platform code, automated in CI so a colour decision propagates to every target without a human retyping a hex; the DTCG file is the vendor-neutral asset the client owns, which is why it also wins the contract.