When teams talk about design token alignment, color dominates the conversation. A designer specifies "primary blue," a developer asks which shade, and the discussion collapses into a color palette comparison. Fix the color tokens, the thinking goes, and alignment is done.
It is not done. Spacing and typography are where alignment breaks down in production, and they break down in ways that are harder to spot precisely because they do not shout at you the way a wrong color does. A button rendered with 14px padding instead of 12px does not look like a bug. It looks like a slightly different design choice. That ambiguity is the problem.
This post is a comparative look at three primitive families, color, spacing, and typography, and how each one fails differently when token alignment is incomplete. The failure modes are not the same, and neither are the fixes.
Color Tokens: The Solved Half
Color token infrastructure is, at this point, well-understood. The pattern of primitive tokens (raw values) aliased through semantic tokens (purpose-named references) is widely documented. --color-blue-600 becomes --color-interactive-default, which is what components actually reference. When that chain is intact, a theme switch or brand update flows through without touching component code.
The reason color gets most of the attention is that violations are visible. A component rendered with the wrong color produces an immediate, obvious mismatch that designers and developers both see. This visibility drives iteration, and teams develop instincts for color token hygiene that they do not always develop for other primitive families.
What stays unsolved in color, even for teams with mature alias chains, is the semantic layer completeness question. Many systems define semantic tokens for brand colors but leave utility colors, warning states, destructive states, and surface overlays as raw hex values scattered across component files. A mockup generator that resolves brand primaries correctly but misses destructive state colors will produce screens that look right until they do not.
Spacing Tokens: The Scale Problem
Spacing is where most token systems have their largest gap between stated intention and actual implementation. A team documents a spacing scale:
--space-1: 4px
--space-2: 8px
--space-3: 12px
--space-4: 16px
--space-6: 24px
--space-8: 32px
--space-12: 48px
--space-16: 64pxThis looks complete. In practice, what happens is that component implementations reference the scale inconsistently. A card component uses --space-4 for internal padding, but the header uses 16px as a hardcoded value because a developer was working fast. A modal uses --space-6 for gaps between sections, but an older input group still has margin-bottom: 20px from before the scale existed.
The mismatch is invisible in isolation. Neither component looks wrong. The problem surfaces in composition: when the modal contains the input group, or when a card sits inside a section with header-level spacing. The visual rhythm breaks because two things that should share a spacing reference do not.
For a brief-to-screen workflow, spacing token drift creates a specific class of problem. A brief might say "a data table with comfortable row padding." Comfortable is not a spacing token. The generator has to make a judgment call, and unless the customer's token file makes the spacing scale explicit with semantic names (--space-comfortable or --space-data-row), that judgment is essentially guessing at the right step on the scale. Getting it wrong by one step, say --space-6 instead of --space-8, produces a screen that is nearly correct but not quite usable as a handoff artifact.
Spacing token completeness audit: what to check
The question to ask about any spacing token system is not whether the scale is documented, but whether the scale is referenced. A token that is defined but not used in component files is not actually part of the system. It is a footnote. The real scale is whatever values are actually used, and that is often not the same as the documented scale.
A useful audit looks at three things. First, what values appear as hardcoded numbers (px, rem, em) in component CSS rather than token references. Second, what steps on the official scale have zero usage in production. Third, where the semantic layer exists at all: does the system have things like --space-inset-default (padding inside components) and --space-stack-default (vertical rhythm between components), or does everything reference the raw numerical scale directly?
Typography Tokens: The Three-Layer Gap
Typography token alignment is arguably the most structurally complex of the three families because typography has three dimensions that each require their own token chain: size, weight, and line height. In most design systems we have looked at, at least one of those three is underdeclared in the token layer.
The common pattern is a size scale that is complete, a weight scale that is partially semantic, and line height either hardcoded or absent from the token system entirely. This creates a specific kind of drift: type looks correct in terms of size hierarchy, but the density and readability feel different from what the designer specified because line height is being interpreted by each component independently.
Consider a system with this token structure:
--type-size-body: 1rem
--type-size-small: 0.875rem
--type-size-heading-2: 1.5rem
--type-weight-regular: 400
--type-weight-medium: 500
--type-weight-bold: 700Looks reasonable. But the missing --type-leading-body and --type-leading-heading tokens mean that line height is being set somewhere else, probably in component CSS, probably inconsistently. A generated mockup that applies the correct font size and weight but uses a default line height will produce screens where the type spacing does not match the system's visual rhythm. That mismatch will need to be corrected manually after handoff.
The weight layer has a different failure mode. Many systems define regular, medium, and bold as weight tokens, but leave interactive state weights (focused input label, active nav item) as hardcoded values. The result is that weight shifts on interaction are implemented differently across components, producing visual inconsistency that is hard to trace back to a missing token because the symptom looks like inconsistent design intent rather than a token coverage gap.
Component Primitives: Where All Three Families Converge
Component primitives sit above the three primitive families and are what most teams think of when they say their design system is "token-based." A button's component tokens reference color tokens, spacing tokens, and typography tokens. A card's tokens do the same. If any of those underlying references are incomplete, the component token layer inherits the gap.
The failure mode at the component level is a kind of false completeness. A team can have a complete component token inventory, things like --button-bg-default, --button-text-default, --button-padding-y, and still produce misaligned screens if any of those component tokens resolve to hardcoded values rather than chaining through the primitive layer.
| Primitive family | Most common gap | How it manifests |
|---|---|---|
| Color | Utility and state colors not in alias chain | Visible immediately: wrong destructive or warning color |
| Spacing | Hardcoded values alongside token references | Subtle: rhythm breaks only in composition, not isolation |
| Typography | Line height and interactive weights underdeclared | Silent: density feels wrong but looks plausible |
| Component | Tokens defined but resolving to hardcoded primitives | Inherited: all of the above, traced to the chain break |
What Token Completeness Actually Requires
We are not saying color alignment is easy or solved. Color semantic layers have their own coverage gaps, particularly around surface states and overlay opacities. The point is that the visibility of color problems drives iteration that does not happen for spacing and type because those problems are quieter.
A complete token system requires that all three primitive families have semantic layers that components actually reference. That means: spacing tokens with semantic names used in component CSS (not just documented in a spec), typography tokens that cover line height and interactive weight states, and a component token layer that chains through the primitive layers rather than hardcoding any value.
For teams working to bring a new design system into a brief-to-screen workflow, the priority order matters. Start with the chain audit: for every component token, trace the reference chain all the way to a CSS custom property value. Anywhere the chain terminates in a hardcoded number rather than a primitive token is a gap. Color gaps are already visible in your current mockups. Spacing and typography gaps are what is producing the subtle wrongness you cannot quite articulate.
Building that chain completeness before feeding a brief to any generation tool, ours or anyone else's, determines whether the output is a usable starting point or another round of cleanup work. That is the actual cost of the gap.
