Theming in Figma: multi-branding no longer requires you to duplicate your collections (what Schema 2025 has changed)

Variables have replaced styles - and here's why

Since their introduction in 2023, Figma variables have transformed the way design systems are conceived. Before, we depended on styles to manage colors, typography and effects. Variables go much further: they store four types of values - Color, Number, String and Boolean - that can be dynamically reused across all your files. It's this foundation that finally makes truly systematic theming possible in Figma.

The real power comes from the ability of variables to reference each other. A semantic token like color/surface/primary points to a primitive color/blue/600, and this relationship is preserved everywhere. Change the primitive, and every reference updates instantly - exactly the behavior that developers know from CSS custom properties. This is what makes variables a natural bridge between design and code. Number variables, on the other hand, are underestimated: by defining a consistent spacing scale (4, 8, 12, 16, 24, 32, 48) applied via variables to the auto-layout gap and padding, you guarantee a spatial consistency that previously required heroic discipline on the part of every designer.

Collections and modes: the mechanics of theming

Variable Collections organize your tokens by logical category: a color collection, a spacing collection, a typographic size collection. This separation is structural, not cosmetic, because modes apply at collection level. If your color collection has a Light mode and a Dark mode, you can toggle the entire palette with a single click, without touching the spacing.

And modes aren't limited to light/dark. I use them regularly for multi-brand variants, interface density levels, responsive breakpoints, even language locales. A Compact mode reduces spacing by 20%, a Brand-B mode replaces the entire palette - without duplicating a single component. But beware: the number of modes depends on your plan, and these limits have moved to Schema 2025.

Plan	Modes by collection
Free / Starter	1 (theming impossible)
Professional	10 (from 4 to Schema 2025)
Organization	20 (statement to Schema 2025)
Enterprise up to 40

Plan your mode strategy around these constraints from the outset. Four modes was the historical wall of the Professional plan - many multi-brand systems stumbled over it. The move to 10 actually changes what an SMB can do without paying for an Organization plan.

Multi-branding no longer requires you to duplicate your collections.

This is the real change of 2025, and it renders obsolete much of what has been written about multi-branding. Historically, managing multiple brands meant either stacking fashions or duplicating entire collections - unmanageable beyond two or three brands. Schema 2025 introduced Extended collections: one team publishes a "white label" version of its system, which the others extend with their own theme. The extension remains linked to the parent system and automatically inherits its updates - new variable, color adjustment - while retaining the values it has explicitly overloaded.

The pattern remains two-layered. The first contains the fundamental decisions - typographic scale, spacing grid. The second contains brand-specific tokens. A Button component works identically for all brands; only its appearance changes. For responsive, I combine breakpoint modes (Mobile, Tablet, Desktop on the spacing collection) with auto-layout: a mode is applied to the parent frame, and all children inherit the correct values - more elegant and maintainable than component variants by screen size.

Scoping and Code Syntax: the bridge to developers

Scoping is an overlooked but fundamental feature. Each variable can be restricted to specific contexts - fills, strokes, corner radius, gap, padding, text, opacity. By restricting a color variable to the fills scope, you prevent it from being mistakenly applied to a stroke or text. This constraint eliminates an entire category of usage errors.

Code Syntax associates each variable with a code name distinct from the name displayed. Your variable is called surface/primary on the designer side and is referenced as --color-surface-primary in CSS, $surface-primary in SCSS or surfacePrimary in JavaScript. In Dev Mode, developers see these code names directly in the context of the inspected component - no more manual mapping table, the link is alive and up to date. And since November 2025, Figma finally offers native import/export of variables, aligned with the stable spec for design tokens: you can move your tokens in and out without relying on a third-party plugin.

Industrialize token management

For a professional-sized system, native variables aren't always enough. The Tokens Studio plugin, which has become a community standard, extends Figma with file-to-file references, mathematical expressions, modular token set management, and full support for the W3C DTCG format; its version 2.0 goes beyond the simple plugin with a stand-alone platform. And here again, a major update: the W3C Design Tokens format is no longer an "emerging" specification. It reached its first stable version, 2025.10, on October 28, 2025 - neutral, supported by more than ten tools. It's a reliable foundation, no longer a moving draft.

My typical workflow combines Tokens Studio for management in Figma, a Git repository for versioning JSON files, and Style Dictionary - now in version 5, aligned with spec 2025.10 - in a CI/CD pipeline for transformation. v5 exports to JSON DTCG by default and natively handles the new color and dimension object types; if you're still running v4, now's the time to plan your migration. Every token modification in Figma synchronizes to Git, which triggers the generation of CSS, Swift or Android code. No more manual intervention between design and production.

Migrate gradually, without breaking the bank

If you have an existing style-based system, there's no need to start from scratch. Figma supports styles and variables in parallel, so you can convert collection by collection without disrupting the work in progress. I always start with colors, because that's where the gain from theming by mode is most immediate and visible, then extend to spacing and typographic sizes as a second step. The rule that has saved me a lot of damage: only migrate a collection when it's stable. Converting a system that's still in motion means condemning yourself to redoing everything two weeks later.

Figma theming reached a milestone in 2025. With mode limits lifted, Extended Collections finally settling multi-branding, native import/export and a stabilized token spec, what was tinkering a year ago has become a solid infrastructure. That leaves the one thing that the tooling will never do for you: your own naming convention and token discipline. Once you've got that, Figma does the rest.