Multi-brand file organization

Everything in this course has been building toward this file. You have the functional/perceptual split from Lecture 1, the token mental model from Lecture 2, variables and modes from Lecture 4, component architecture from Lecture 5, and auto layout from Lecture 6. Multi-brand organisation is where all of those meet a single, awkward, load-bearing question: when one design system must serve several brands, where do the brands differ, and how do you structure a Figma file so that difference is cheap to express and cheap to maintain?

It comes up constantly in serious agency and in-house platform work: a bank with retail and business apps, a media company with a dozen mastheads, a car group with a stable of marques, an events business with several show brands. Most teams start with one Figma file per brand, and most teams drown in exactly that. What follows is the seam, the three organisational schools, and the two authorities who tell you what to put on each side of the line.

The seam: functional stays shared, perceptual is where brands differ

Go back to Kholmatova’s split. It happens to be the fault line a multi-brand system is built along. Every pattern is either functional or perceptual, and the two differ in origin, not just in how they look.

Functional patterns come from the product’s domain and from user behaviours: an event card, an exhibitor list, a ticket call-to-action, a data grid, a checkout. Perceptual patterns come from the brand’s ethos: colour, typography, iconography, spacing, shape, imagery, motion, tone. Her HipChat and Slack example says most of what this lecture is about. Near-identical chat features, an entirely different feel, and all of that difference sits in the perceptual layer. Same skeleton, different skin.

That is your multi-brand seam. The functional layer is the shared infrastructure: components named by purpose, owned by the centre, identical across every brand. The perceptual layer is where brand lives: tokens, type, colour, iconography, per brand. Kholmatova says the same thing in brand terms:

The three organisational schools

Once you accept the seam, the Figma question gets concrete: how do you physically arrange collections, libraries and modes so the shared functional layer and the per-brand perceptual layer can coexist? The field has settled on three schools. None of them is universally correct. The right choice depends on your team size, brand count, and how much the brands actually share anatomically.

When to pick each. If the brands share most of their anatomy and one small team owns everything, go with School 2. The modes approach gives you a single source of truth and a one-click re-skin. If you have separate brand teams, confidentiality requirements between brands, or more than roughly eight brands, go with School 3, where the isolation earns back the plumbing. School 1 only survives where two brands share so little structure that calling them one system is a fiction. For the common four-to-twelve-brand case, the settled advice is layered collections everywhere (a primitives collection plus a semantic collection, with components bound only to the semantic tier), then modes for small shared-anatomy teams and library swap for large or siloed ones.

The 2025 change that made brand-as-mode viable

School 2 used to hit a hard ceiling. For years Figma capped variable modes at four per collection on every paid plan, which is why pre-2025 multi-brand articles either dismiss the modes approach or bend around it. If a mode carries a brand and you only get four of them, you have nothing left to spend on light/dark or density, and a dozen brands is out of the question.

Then that ceiling moved. At Figma’s Schema conference on 28 October 2025, the per-collection mode limits rose from four to 10 on Pro, 20 on Organization, and 40 on Enterprise, with Enterprise-only “extended collections” on top. Add typography variables from 2024, which let font-family itself become a mode-switched string, and brand-as-mode became a first-class strategy at real brand counts rather than a demo trick. So when you read an article claiming Figma only gives you four modes and brand-as-mode does not scale, check its date. That constraint expired in October 2025.

Perez-Cruz: consistency is not the goal, expression is

Kholmatova gives you the seam. Yesenia Perez-Cruz tells you what to do with the perceptual side of it so your brands do not collapse into one beige average. Her book Expressive Design Systems opens from a different fear than most systems writing. Where the usual worry is inconsistency, hers is that systems get so consistent they go dead:

She pulls apart two words most people use loosely. Unity means all your brand elements work together as one, and a tool can deliver that: shared components, a style guide, a brand language. Cohesion is the harder quality that makes experiences understandable across the whole journey, and no tool on its own produces it. Here is her formulation, from the New York subway signage case:

For multi-brand work the lesson is sharp. A shared component library buys you unity almost for free. It does not buy you cohesion, and it does not buy you brand. Both of those you have to design into the perceptual layer on purpose.

Big levers and small dials

Her most useful framework for a multi-brand file is how she decides where variation is allowed to happen. She frames the whole design language as a set of controls, some coarse and some fine:

Map this straight onto your Figma structure. The big levers, colour, typography and the spacing scale, are what a brand mode or a per-brand foundation library should carry: pull the lever and the whole brand shifts. The small dials are the per-component adjustments you expose deliberately and sparingly, so a brand can tune one component without forking it. The discipline is keeping brand difference on the levers and dials you chose, rather than letting it leak into ad-hoc overrides scattered across the file.

Her deeper warning is the one that separates a real multi-brand system from a reskin. Cohesion and unity are not enough if the perceptual layer has no range:

The practical consequence: if you give the perceptual layer no real range, brands feel like reskins. When every brand is the same component with a different hex value swapped in, users sense the sameness even when they cannot name it. A brand needs enough room on the big levers, a distinct type voice, a genuinely different colour strategy rather than a hue rotation, its own spacing rhythm, so it reads as itself and not as a paint job over a competitor. Making that room is the design work. The file structure only holds it.

The Harry’s Forge lesson: some brands need different structure, not different tokens

Here is the failure mode that catches teams who over-trust the seam. The clean story says functional structure is shared and only perceptual tokens differ. That holds most of the time and breaks right where it hurts. Harry’s built a multi-brand system called The Forge to serve both Harry’s and Flamingo, and they found some components that swapping tokens could not reconcile at all.

This refines the seam rather than weakening it. The functional layer is shared at the level of purpose and primitives, not always at the level of a single frozen assembly. Most components share their assembly across brands and vary only on the perceptual layer. A minority share only their primitives and their purpose, and get re-composed per brand. Knowing which is which before you build is the craft.

Case studies: how real systems hold the seam

Volkswagen Group: GroupUI. The clearest large-scale instance of the shared-functional / per-brand-perceptual seam. GroupUI serves 15+ brands (Volkswagen, Audi, Škoda, Porsche, MAN, Scania and more) from one framework-agnostic component core, built as Stencil.js web components so it does not care which front-end framework a brand ships. Every brand’s identity comes entirely through design tokens, with the Figma and Sketch libraries mirroring the code. Their own positioning for the system says a lot: it sits “between standard and flexibility.” That is the seam stated as a product goal. One shared functional core, brand carried wholly by the perceptual token layer, School 2 thinking at industrial scale.

NL Design System. The governance model that makes multi-brand sustainable. NLDS serves many Dutch government organisations (Utrecht, Amsterdam, Den Haag and others) from a shared base, and it splits ownership precisely: the centre owns behaviour, accessibility and the token contracts; each organisation owns only its token values, expressed as a JSON theme that compiles to a CSS theme class. An org can change what a component looks like but not how it behaves or whether it is accessible. That is the seam written as a governance rule rather than just a file structure. Their naming convention, prefix.block.element.modifier.property (for example utrecht.button.background-color), bakes the brand prefix into the token so values never collide across organisations. Component maturity moves through their estafettemodel (relay model): Help Wanted → Community → Candidate → Hall of Fame, so a pattern earns its place in the shared core by surviving real use instead of being decreed into it. That is the answer to “who is allowed to change what” that a modes-based file cannot give you on its own.

The panel: structure, expression, and the evidence

Three voices on one seam, from three angles. Kholmatova gives you the structural line: functional patterns are the shared, purpose-named infrastructure, perceptual patterns are where brand lives, and they differ in origin, not just in looks. That tells you where to cut. She also hands you the strict-versus-loose dial from Chapter 6, where a multi-brand system is usually strict on the functional contract (behaviour, accessibility, the shape of the API) and deliberately loose on the perceptual layer so brands have room to be themselves. Perez-Cruz tells you what to do on the loose side: modulate the big levers of colour, type and space per brand, expose small dials sparingly, and give the perceptual layer genuine range, since unity and cohesion without expressive range produce reskins rather than brands. The case studies supply the proof and the two hard edges. GroupUI shows the seam works at 15+ brands when brand rides entirely on tokens. NLDS shows the governance that keeps the seam honest, with the centre owning contracts and orgs owning values. Harry’s Forge marks the boundary of the clean story, where some components need per-brand structure and not just per-brand tokens. Kholmatova tells you where to cut, Perez-Cruz how much room to leave, and the real systems what breaks when you cut wrong.

Further reading

• Yesenia Perez-Cruz: Expressive Design Systems (A Book Apart)
• Nathan Curtis: “Theming Design Systems”
• IBM Carbon: themes
• Canonical: Ubuntu brand & design guidelines
• Canonical: Vanilla colour settings