Design Tokens and Multi-Brand Design Systems: Scaling UI Across Products

“

Meerako — Dallas, TX experts building scalable design systems for multi-product and multi-brand companies.

A design system built for a single product with hardcoded colors, spacing, and typography works fine — until the company launches a second product, a white-label offering, or a rebrand, and every hardcoded value has to be found and changed individually across the codebase. Design tokens — the practice of defining design decisions (color, spacing, typography, radii, motion) as named, reusable variables rather than hardcoded values — are the foundation that makes scaling a design system across multiple brands or products actually manageable, instead of a recurring, error-prone find-and-replace exercise every time the business adds a brand.

The idea itself isn't new, but the tooling around it has matured considerably. Figma's native Variables feature, the W3C Design Tokens Community Group's emerging shared format for interoperable token files, and CSS custom properties as a first-class theming primitive across every modern framework have together turned "design tokens" from a nice-to-have documentation convention into genuine engineering infrastructure that a well-run product or platform team treats with the same rigor as any other shared dependency. This guide covers what tokens actually are at the architecture level, how the token layers support multi-brand theming specifically, what a real design-tool-to-production pipeline looks like, and when this investment is — and isn't — worth making.

• What design tokens actually are, concretely, and why layering matters
• How token architecture supports multi-brand and multi-tenant theming
• The build pipeline that connects design tools to production code
• How dark mode fits into the token model as its own dimension
• Governance and versioning practices for tokens at scale
• When investing in this level of design system maturity is worth it

A design token is a named value representing a single design decision — color.brand.primary, spacing.md, radius.button — used throughout an application instead of a hardcoded hex code or pixel value. The key architectural benefit: changing what color.brand.primary means — the actual hex value it resolves to — updates every place that token is used, without touching individual components. This is the difference between "find and replace every blue in the codebase and hope you caught them all" and "change one value in one file and trust the system to propagate it correctly."

A well-architected multi-brand system separates tokens into layers, and the layering is what actually makes multi-brand theming tractable rather than the tokens themselves. Primitive tokens are raw values — a specific blue at a specific hex value, a spacing scale from 4px to 96px, a type scale — that rarely change and carry no inherent meaning on their own. Semantic tokens — color.brand.primary, color.text.danger, color.surface.elevated — map to primitives and carry actual meaning within the design system; these are the tokens components and designers should actually reference day to day. Component tokens — button.background, card.border, input.focusRing — map to semantic tokens for specific component use, giving individual components a further layer of indirection for cases where a component's styling needs to diverge slightly from the general semantic mapping.

A second brand or theme simply provides a different mapping from semantic tokens to primitives — the components themselves, built against semantic and component tokens rather than primitives directly, don't need to change at all. This is the entire trick: brand B's color.brand.primary points at a completely different primitive than brand A's, but every component that renders a primary button just asks for button.background, which resolves through the semantic layer to whichever brand is currently active, with zero component-level branching logic required.

Modern token workflows connect the design tool — Figma Variables, specifically, which by 2026 has become the standard way most design teams define and organize token values directly inside their design files — to code. Tokens defined in Figma export to a format, often the W3C Design Tokens Community Group's JSON format that's increasingly becoming a shared interchange standard across design tools, and then get run through a build tool like Style Dictionary, which generates the actual CSS custom properties, JavaScript or TypeScript theme objects, iOS and Android platform-specific values, or Tailwind theme configuration consumed by the application.

This pipeline is what prevents design and code from drifting apart over time — a token change in Figma flows through an automated build step to production rather than requiring a designer to manually communicate "change this hex code" to an engineer over Slack, who then has to remember every place it's referenced. Teams that skip this automated pipeline and instead hand-maintain a token file that's supposed to mirror the design tool inevitably drift, usually within a quarter or two, and the drift is expensive to catch because it shows up as subtle visual inconsistency rather than a build failure.

A practical extension of this same architecture handles light and dark mode cleanly: rather than maintaining two entirely separate stylesheets, a well-structured token system treats color scheme as another dimension of the same semantic-token mapping — color.surface.base resolves to a light value in light mode and a dark value in dark mode, through the same mechanism a second brand's tokens resolve differently than the first brand's. CSS custom properties combined with a prefers-color-scheme media query or a data-theme attribute on the root element make this mechanically straightforward once the semantic token layer exists; the harder part, as with multi-brand theming, is disciplined component authorship that references semantic tokens consistently rather than hardcoding a color that only looks right in one mode.

Once a token system spans multiple products or brands, it needs the same governance discipline as any shared library. Mature teams publish their token build output as a versioned package — an npm package for web consumption, distributed through the same internal registry as other shared code — so consuming applications pin a specific token version and upgrade deliberately rather than automatically inheriting every change the design team makes. This matters because a token change that looks purely cosmetic to a designer (a slightly different shade of the brand primary) can have real visual regression implications across dozens of components and multiple products if it ships without review.

Visual regression testing — tools like Chromatic, Percy, or Playwright's built-in screenshot comparison — deserves a place in the token pipeline specifically because token changes are exactly the kind of change that's easy to review incorrectly by eye and easy to catch reliably with automated screenshot diffing across a representative set of components and both light and dark themes.

The most common mistake is skipping the semantic layer entirely and having components reference primitive tokens directly — this technically "uses tokens" but forfeits almost all of the multi-brand and dark-mode benefit, since there's no meaningful indirection layer for a second brand or theme to hook into. A second common mistake is over-tokenizing too early, building an elaborate three-layer token architecture for a single-brand product with no multi-brand plans, which adds real cognitive overhead — more indirection for a designer or engineer to trace through — without a corresponding payoff. A third is letting the Figma source of truth and the generated code drift apart because the export-and-build pipeline isn't actually automated in CI, turning what should be a reliable single source of truth into two systems that slowly disagree. And a fourth is under-communicating token changes to consuming teams — a breaking token rename or a semantic remapping needs the same changelog and migration-guide discipline as any other shared package's breaking change.

Building a genuinely token-driven, multi-brand-ready design system is real upfront investment — worth it clearly when you have multiple products or brands today, or a credible near-term roadmap that includes them: white-labeling, planned sub-brands, multi-tenant theming for enterprise customers who want their own branding applied to a shared product. For a single product with no multi-brand plans, a simpler design system without the full token layering is often sufficient, and the additional architecture — the primitive/semantic/component layering, the automated Figma-to-code pipeline, the versioned package governance — is premature investment that mostly adds friction without a near-term payoff.

A detail that trips up teams adopting tokens mid-project: rolling the system out to an existing, actively developed codebase is a change-management problem as much as a technical one. Engineers who've spent months hardcoding hex values and pixel spacing don't automatically switch habits because a token file now exists — without linting enforcement (a stylelint rule flagging hardcoded colors where a token exists, for instance) and a clear migration guide, adoption stalls at whatever fraction of the codebase happened to get touched during the initial rollout. Teams that succeed here tend to pair the token system's introduction with a genuinely enforced lint rule and a deliberate, tracked migration of the highest-traffic shared components first, rather than hoping the rest of the team adopts the new pattern organically over time.

We architect the token layers — primitive, semantic, and component — deliberately based on your actual multi-brand or multi-product roadmap, not a generic template applied regardless of need, and build the Figma-to-code pipeline so token changes flow through to production reliably via an automated build step rather than manual synchronization. We treat design tokens as real engineering infrastructure, not just a design-tool organizational convenience, which means versioned package publishing, visual regression coverage on token changes, and clear documentation for engineers consuming the semantic layer day to day.

Design tokens are the architectural foundation that makes a design system genuinely scalable across multiple brands or products, rather than a collection of hardcoded values that has to be manually hunted down every time a brand or theme changes. The investment is worth making deliberately, matched to your actual multi-brand roadmap and backed by real pipeline automation and governance, not as a default applied to every project regardless of need.

Scaling a product across multiple brands or a white-label offering? Let's architect a design token system that scales with you.