The token mental model

In Lecture 1 we established that a design system is a shared language and the practices that keep it alive. Tokens are how that language gets written down in a form both a designer and a compiler can read. In the front-end lineage, Micah Godbolt frames the whole enterprise cleanly: a design system is “the programmatic representation of a website’s visual language.” Tokens are the vocabulary of that representation. This lecture builds the mental model you need before you touch a single Figma variable. Get the model right and the tooling in Tier II is trivial; get it wrong and the same tooling works against you.

What a token actually is

The phrase “design tokens” was coined at Salesforce around 2014 by Jina Anne with Jon Levine, and Sönke Rohde built the first transform tool, Theo, to turn one source of truth into per-platform outputs. The origin tells you something: tokens were born as a pipeline idea, not a naming convention. The canonical Salesforce Lightning Design System definition is worth knowing by heart:

Three words in that definition carry the whole idea. Named: the token has an identity independent of its value. Store: it holds a value now, but the value can change without the name changing. In place of hard-coded values: nothing in the interface points at #0B5FFF directly, everything points at the name. That indirection is the entire trick.

Tokens are a methodology, not variables

The most common beginner error is to hear “token” and think “CSS custom property” or “Figma variable.” Those are outputs. Jina Anne is emphatic that a token is a methodology: a single abstract source value that gets transformed, per platform, into whatever that platform needs. The same token color.background.brand becomes a hex string for the web, a UIColor for iOS and an XML color for Android, all generated from one entry. That is why the lineage runs Theo, then Style Dictionary (Amazon), then the DTCG standard. The tool changes and the methodology stays put.

Godbolt describes the underlying move as deconstruction, and his linguistic framing rhymes exactly with Kholmatova’s from Lecture 1:

Tokens are those smallest pieces, plus the rules for putting them back together. You are not naming variables. You are encoding decisions in a portable, transformable data layer.

Options versus decisions: the Curtis frame

Nathan Curtis of EightShapes gave the field the distinction that makes every later tier make sense. In “Tokens in Design Systems” (2016) he splits every token into one of two roles.

color-neutral-42 is an option: it answers “what do I have available.” color-background-disabled is a decision: an option applied to a context. The option layer is raw inventory. The decision layer is where meaning and intent live, and it is what a theme overrides. Curtis distils it into one line, which sits well next to Kholmatova’s from Lecture 1:

Take the three words apart. Decisions, not values. Propagated, meaning the point of a token is that it fans out. Through a system, which is how one edit re-skins an entire product. The decision layer earns its extra indirection because one option can feed many decisions, and you only ever want to author the mapping once.

The payoff is now visible. If the brand hue moves to #1656E0, you edit one option and every decision downstream inherits it. But because the decisions are named by intent, you can also break the link: if legal insists the focus ring go higher-contrast, you repoint color-focus-ring alone, without disturbing links or actions. Options give you consistency, decisions give you divergence you actually meant. That is what a token layer buys you, and it is why binding a component directly to blue-600 and skipping the decision is the cardinal sin we return to below.

Frost’s three tiers

Brad Frost formalised the layering into the model almost every serious system now speaks, in “The Many Faces of Themeable Design Systems” (2022). His exact tier language:

Frost’s Tier 1 and Tier 2 are literally Curtis’s options and decisions, renamed and stacked. Tier 3 is new: a per-component layer, button-primary-background, that reads from Tier 2 rather than Tier 1. The rule that makes the whole stack work is directional and strict: each tier may only reference the tier above it. A component reads a decision, a decision reads an option, an option reads a literal value. Never skip a tier, never point upward. Swap the Tier 2 mapping and every component re-themes without a single component file being touched.

The same idea, four dialects: Material, Polaris, Atlassian, Carbon

Here is where the theory earns its price. The major public systems all accept the token model but disagree, productively, on how many tiers to expose and what to make public. Once you know these dialects you can read any system on sight and pick one for a client.

Material 3 pushes formalism furthest. Its three tiers, md.ref (reference), md.sys (system) and md.comp (component), map one-to-one onto Frost’s option, decision and component. But the reference palette is not chosen by hand. It is generated by the HCT (Hue, Chroma, Tone) color engine from a single source color, so even the option tier is machinery. It is the most complete taxonomy in public existence and also the most over-engineered for a small team.

Polaris is the deliberate opposite. Shopify exposes essentially one flat semantic tier, --p-color-bg-surface, tuned to exactly one product, the Shopify admin. Flatness is the strategy: fewer names, one vocabulary, no ceremony. The 2023 v12 restructure of that flat layer let them re-skin the entire admin in roughly ten weeks, which is about as concrete as an argument gets that a small, well-named decision layer beats a deep taxonomy for a single product.

Atlassian makes the sharpest doctrinal claim: semantic tokens are the only supported API, the raw palette is deliberately backgrounded, and tokens move through a formal lifecycle (active, then deprecated, then deleted). Their guidance names the exact anti-pattern this lecture warns against:

Carbon contributes the layer idea. Its $layer-01, $layer-02, $layer-03 tokens map to how deeply a surface is nested, so a card on a card on a page each gets the correct background without anyone hand-picking greys. v11 also consolidated four themes into variable modes inside a single library, which is the pattern Tier II of this course adopts for multi-brand.

None of these wins outright. The number of tiers is a choice driven by how many products and brands the system serves. One product, go Polaris-flat. Fifteen brands off one engine, go Material-deep. Four event brands off a shared core, which is the running case in this course, means two tiers with brand as a mode, the Carbon shape.

The standard that makes tokens portable: W3C DTCG

Until recently every tool invented its own JSON shape, so a token file from one vendor could not be read by another. The W3C Design Tokens Community Group fixed that. The Design Tokens Format Module reached its first stable version, 2025.10, on 28 October 2025. Be precise when you sell it: it is a Community Group Report, not yet a formal W3C Recommendation. It is already the lingua franca all the same.

A DTCG token is a JSON object with reserved keys. $value holds the value, $type declares what kind of value it is (color, dimension, duration, and so on), and an alias references another token by path in curly braces. That alias syntax is how you express Frost’s tier references in plain data. The decision-references-option pattern looks like this:

The spec is explicit that tools must follow the alias to resolve the real value, which is what lets one edit to an option cascade through every decision that references it. Primitive types include color, dimension, duration, font family, font weight and cubic-bezier. Composites include shadow, border, gradient and typography. Modern color spaces (Display P3, Oklch, CSS Color 4) are first-class.

A standard matters for client work because vendor-neutral tokens are the handoff artefact. When your tokens are DTCG JSON, they flow through Figma, Tokens Studio, Style Dictionary, Penpot, Framer and Terrazzo without a rewrite. You are not selling a Figma file locked to one tool. You are selling a portable source of truth the client owns and can transform to any platform. That portability is the commercial reason the whole pipeline in Tier III is worth building.

Brandable versus constant: the theming contract

Not every token is up for grabs when a brand skins the system. Jina Anne’s most practical governance idea is to split tokens into two classes before theming begins. Some tokens are brandable, meaning a brand may override them: brand color, display typeface, corner radius, imagery treatment. Others are constant, locked system-wide because changing them would break something non-negotiable, like feedback colors users have learned, focus-state visibility, and above all contrast-critical values.

Here accessibility stops being advice and becomes a lock. WCAG 2.2 (now also ISO/IEC 40500:2025) sets 1.4.3 Contrast at 4.5:1 for normal text and 3:1 for large text, and 1.4.11 Non-text Contrast at 3:1 for UI components. A semantic token like color-text-on-primary must encode that ratio by design, not by luck. So the theming contract reads: a brand may repoint color-primary to any hue it likes, but color-text-on-primary is constant machinery that must always resolve to a foreground passing 4.5:1 against whatever color-primary now is. Brandable freedom sits on top of a constant accessibility floor. Writing that one-page brandable-versus-constant list is the first governance deliverable on any real multi-brand engagement.

The anti-patterns

The dissent: Kholmatova on twenty shades of blue

A course that only quotes token enthusiasts is selling you a religion. Alla Kholmatova, whose definition anchored Lecture 1, is pointedly skeptical of starting from variables at all, and she never uses the word “token.” Her argument is that a standardised palette is necessary but nowhere near sufficient, because the hard part is shared use, not shared values:

And the line that names the whole tension:

Read carefully, this is not a rejection of tokens. It is a warning about the order of operations. Building blocks (variables) come last, not first. You start from roles and meaning (“what is blue for here”), audit real instances, define patterns of usage, and only then crystallise the token. A team that opens Figma and starts spinning up blue-100 through blue-900 before deciding what blue means has built an option layer with no decisions. That is the “collection of modules on a web page” failure from Lecture 1, wearing a token hat. Curtis, Frost and Jina would all agree. Kholmatova just says it loudest.

The panel: where the authorities agree and diverge

They agree on the core. Jina, Curtis and Frost all hold that a design system needs a layer of named, purpose-driven values sitting in front of raw literals, and that theming happens by swapping the meaning layer, not the components. Godbolt supplies the framing (deconstruct the visual language into pieces plus rules). Curtis supplies the two roles, options and decisions. Frost stacks them into tiers. Jina makes it a portable, transformable methodology and adds the brandable-versus-constant contract. DTCG makes it a standard.

They diverge on depth and starting point. Curtis is local-first: keep a value inside a component until roughly three components need it, then promote it and assign a curator so the vocabulary does not sprawl. Frost is global-first: define the full option palette up front, then build decisions on top. These are genuinely opposite build orders, and which you pick depends on whether you are extracting a system from live product (Curtis) or standing up a themeable stack deliberately (Frost). On tier count, Material argues for three public tiers and an engine while Polaris argues for one flat tier, and both ship at scale, so tier count is a fit decision, not a correctness one.

Kholmatova sits outside the frame and checks it. Her contribution is the reminder that a token without an agreed meaning is just a variable, and that meaning comes from purpose and shared use, both of which precede any tooling. For client work you will lean on Frost and Curtis for structure, Jina for the pipeline and the contract, DTCG for portability, and Kholmatova for the discipline of not opening the variables panel until you know what each value is for.

Further reading

• Nathan Curtis: “Tokens in Design Systems”
• Jina Anne: “What Are Design Tokens?” (Smashing Podcast)
• W3C Design Tokens Community Group: format spec
• Material 3: design tokens overview