Design Tokens for Product Managers: The Invisible Layer That Governs Consistency

Design tokens are the named, reusable variables — things like color-brand-primary or space-md — that store a design system's visual decisions once so they can be referenced everywhere: Figma files, CSS, iOS code, Android code. For a PM, the payoff isn't aesthetic. It's knowing whether a "small" visual request touches one button or cascades through hundreds of screens.

Quick answer: Design tokens are layered variables — primitive, semantic, and component — that sit between raw design values and the UI that consumes them. Which layer a request touches determines whether it's a five-minute fix or a theme-wide rewrite.

What Design Tokens Actually Are

A design token is the smallest unit of a design system: a single named value for a color, spacing increment, font size, radius, or motion curve, stored once and consumed by every surface that needs it. Instead of a button's CSS having background-color: #2563EB hard-coded, it references button-primary-bg, which in turn points somewhere else. Change the reference target, and every button updates.

The term itself has a real origin. Designer Jina Anne is widely credited with coining "design token" while working on Salesforce's Lightning Design System around 2014-2015 — one of the first large public systems to formalize a token architecture rather than a static style guide. The idea borrows from Brad Frost's Atomic Design methodology, which described UI as atoms, molecules, and organisms; tokens are the atoms beneath even the atoms — the raw decisions a component is built from.

Tokens aren't a design-only artifact. They're built and shipped like code. Amazon's open-source Style Dictionary tool, for example, takes a single set of token definitions and compiles them into whatever format each platform needs — CSS custom properties for web, XML for Android, Swift for iOS. That's the mechanism that makes "define once" actually true across a multi-platform product.

Three tiers matter for a PM's purposes:

1. Primitive (or global) tokens — raw values with no assigned meaning, like color.blue.500 or space.4.
2. Semantic (or alias) tokens — primitives given a purpose, like color-text-primary or color-danger.
3. Component tokens — semantics scoped to one UI element, like button-primary-bg or input-border-radius.

Since 2022, the W3C Design Tokens Community Group (DTCG) has been standardizing a shared file format ($value, $type, $description) so tools like Figma, Style Dictionary, and design-to-code plugins can read the same token file without custom translation layers. That standardization effort is itself a signal of how mainstream token architecture has become — it's no longer a boutique practice at a handful of companies.

Naming Isn't Bikeshedding

Token names look like a place where a PM could roll their eyes at a naming debate. They're not — the name is the interface. A component references button-primary-bg by name, not by the hex value behind it, so renaming a token without updating every reference silently breaks the chain.

Most systems settle on one of two conventions: dot notation (color.brand.primary) for token-definition files, and kebab-case (color-brand-primary) for the CSS custom properties it compiles into. Neither is objectively better; consistency within one system is what matters, because tooling and search both depend on the pattern holding.

The Mental Shift: Consistency Is a Data Model, Not a Style Guide

A style guide is documentation — a PDF or Figma page a reviewer can eyeball and compare against a shipped screen. A token system is executable data: change one value, and every consuming surface updates automatically, with no human re-checking each screen. That difference is the real mental shift for a PM. Consistency stops being a review activity and becomes an architecture property.

A style guide is checked. A token system is enforced. That's the difference between hoping for consistency and architecting it.

This matters because it relocates the risk. In a style-guide world, an inconsistency is a QA catch — someone notices the wrong blue on screen 40 and files a ticket. In a token world, an inconsistency is either everywhere (because it's baked into a shared primitive) or nowhere (because the reference chain is correct). There's very little "slightly off in one place" — tokens tend to fail in bulk, not in isolation.

It also changes who can safely touch what. A designer editing a component's fill color in a token-driven file might be quietly repointing a reference that forty other components share. Figma Variables, introduced in 2023, made this concrete for design tools specifically — bindable properties that mirror the primitive/semantic/component structure, closing the gap between what a designer sees in a file and what an engineer ships in code. The convenience is real; so is the ability to make a much bigger change than intended by editing what looks like a small thing.

For platform and design-system-adjacent PMs, this is exactly the kind of shared-vocabulary problem that a healthy product trio operating model exists to solve — design, engineering, and product all need to reason about the same token graph, not just the same Figma comp.

There's also a single-source-of-truth question worth asking directly: where does the canonical token file actually live? In mature setups it's a versioned repository that design tools and codebases both pull from, so a token change ships through the same review and release process as any other code change — pull request, diff, approval. If the "source of truth" is instead a Figma file that engineers periodically re-copy by hand, drift between design and production is a matter of when, not if.

Primitive vs. Semantic vs. Component Tokens: A Worked Example

Here's the same three-tier chain applied to color and spacing, because seeing it side by side is more useful than defining it in the abstract. The primitive is a raw value with no opinion attached. The semantic layer gives that value a job. The component layer scopes the job to one place it's used.

The semantic layer is the shock absorber. It lets you rename or swap a primitive (say, moving from one blue to a slightly different blue for accessibility contrast) without rewriting every component, because components reference the semantic name, not the primitive directly. This layered-indirection principle is the same one covered in more general terms in a complete guide to design systems — tokens are simply where that principle gets concrete and machine-readable.

Real systems confirm the pattern rather than inventing it. Salesforce's Lightning Design System, Adobe's Spectrum, and Google's Material Design 3 all document some version of this three-tier (or near-identical) structure, even when their naming differs slightly. Design-systems consultant Nathan Curtis, through his work at EightShapes, has written extensively about this exact global-to-alias-to-component breakdown and is one of the most cited voices for why the middle, semantic layer is the one teams most often get wrong or skip.

The same chain applies to typography, which is worth naming explicitly because PMs tend to think of type scale as "just a font list." A primitive might be font-size.6 = 24px; a semantic token like text-heading-md maps to it; a component token like card-title-size maps to the semantic. Request "make headings feel bigger" and you're back to the same tier question — one heading style, one semantic role, or the entire primitive scale.

Nielsen Norman Group's research on design systems has repeatedly observed that organizations underestimate this layering up front and pay for it later — teams that skip the semantic tier tend to accumulate one-off component overrides that quietly diverge from the system within a year or two, which is the exact drift a semantic layer exists to prevent.

Why "Just Change the Blue" Is Never a Five-Minute Request

A request phrased as "make the primary button a bit more blue" sounds like a component-level tweak. But if that blue is a primitive referenced by dozens of semantic aliases — links, focus rings, chart series, brand marks — changing it recolors the whole product, not just the button. This is the theming blast radius problem, and it's the most common way a "small" design ask blows up a sprint.

The wording of a request tells you almost nothing about which tier it actually touches — you have to trace the reference chain to know.

Two things multiply the blast radius further. First, cross-platform builds: if tokens flow through a pipeline like Style Dictionary into separate web, iOS, and Android codebases, a primitive change isn't a CSS edit — it's a new package version that three teams need to consume and release, which is the kind of dependency chain covered in a broader look at technical foundations for product decisions.

Second, accessibility contrast: changing a primitive blue can silently break WCAG contrast ratios wherever that blue sits behind text, since a color that looks fine on a button might fail contrast as a link on a white background. That's not a hypothetical edge case — it's the default risk of any primitive-level recolor.

Because a primitive-level change touches conversion-sensitive surfaces like CTAs and nav, it shouldn't ship as a quiet "visual polish" PR. It deserves the same before/after measurement discipline covered in an experimentation-focused approach to product changes — visual regression testing at minimum, and ideally a monitored rollout rather than a flat cutover.

Google's own Material Design 3 is a useful reference point here, since its "dynamic color" system generates an entire semantic palette algorithmically from a single seed color. That's a deliberate architectural choice to make theming cheap — most product teams don't have that infrastructure, which is exactly why a manual primitive-level recolor costs so much more for everyone else.

How to Scope a "Small" Visual Request Like a Token-Literate PM

Before promising a timeline on any visual request, a token-literate PM asks three questions instead of one. The goal isn't to become the design system's engineer — it's to know which of three very different conversations you're actually having.

1. Which tier does this touch — component, semantic, or primitive? Ask the designer or engineer directly; don't guess from the request's phrasing.
2. How many things alias to it? A component token used in one place is a five-minute change. A primitive with 30 semantic tokens pointing at it is not.
3. Does it cross platforms or repos? If the token pipeline pushes to web, iOS, and Android separately, the "change" is really three coordinated releases.

A simple triage follows from those answers:

• Component-level ask → hours, one owner, ship it.
• Semantic-level ask → days, needs design + QA sign-off, likely touches multiple components.
• Primitive/theme-level ask → its own scoped project, with a rollout plan, contrast re-check, and explicit stakeholder sign-off — not a line item on an existing sprint.

Getting the actual usage count — "this token is consumed by 47 components across 3 platforms" — is the single fastest way to right-size a request, and it's the same evidence-first instinct that governs good analytics instrumentation: don't estimate impact, measure it before you commit to a date. Most design tooling can surface a token's usage count directly; if a PM doesn't have access to that view, asking a design-systems engineer for it takes minutes and changes the entire conversation.

This is also, fundamentally, a UX collaboration skill, not a coding one. Designers already reason in these tiers inside their tools; a PM's job is to build the same radar without needing to open the Figma layers panel personally, which is part of the broader collaboration model covered in a complete guide to product design and UX.

In practice, the conversation can be as short as this: "Is this a component override, or does it change a shared token? If shared, what else references it, and does it cross our web, iOS, and Android builds?" Asking that out loud in a planning meeting, before a ticket gets sized, is usually enough to surface whether you're looking at an afternoon or a milestone.

Where Prodinja Fits: Grounding Token Talk in an Actual Layout

Token conversations go abstract fast — a debate about color.blue.500 versus color-brand-primary can happen entirely divorced from any real screen. Prodinja's Wireframing lo-fi composer is built for the opposite: it lets a PM sketch a screen's structure quickly, so a conversation about "should this button recolor" happens against an actual layout instead of a hex code in a chat thread.

That's a modest, honest claim — the composer helps a PM produce a fast, structural sketch to anchor a discussion; it doesn't manage a token library or generate a theme. But keeping the conversation tethered to a real layout is often the difference between a five-minute scoping call and a week of back-and-forth about what "the blue" even refers to.

Key Takeaways

• Design tokens are layered variables — primitive (raw values), semantic (purpose-based aliases), and component (scoped to one UI element) — not a single flat list of colors.
• Consistency becomes a data-model property, not a documentation-review activity: change a shared value once, and every consuming surface updates without anyone re-checking screens by hand.
• The semantic layer is the shock absorber that lets primitives change without rewriting every component — and it's the layer teams most often skip or get wrong.
• The wording of a request doesn't reveal its tier. "Just change the blue" can be a component edit or a full-theme rewrite; you have to trace the reference chain to know which.
• Cross-platform token pipelines multiply scope: a primitive change often means separate releases across web, iOS, and Android, not one CSS edit.
• Ask for the usage count before quoting a timeline. Knowing a token feeds 3 components versus 40 changes the entire scoping conversation.