Two brands, two websites, and a few months later two "Confirm" buttons that are no longer the same height, three almost identical greys and a form rebuilt from scratch because nobody knew the other team already had one. A shared Figma design system solves this, on one condition: decide first what the brands have in common and what belongs to each of them. Otherwise you end up with identical brands, or with a library nobody dares to touch.
I designed the Figma design system for Moonworkers, my own company, starting from the users (personas, wireframes, then components). I have also built a Figma design system shared by several brands for a client. Here is the method I took from that work, what Figma allows today, and what it really costs.
01What a Figma design system contains, and what it is not
Nielsen Norman Group, in its article Design Systems 101, describes a design system as a set of standards for managing design at scale, with reusable components and patterns. It distinguishes three pieces: the style guide (colours, typography, tone), the component library and the pattern library (layouts, page templates).
In Figma, the library is the published file that holds the components, styles and variables. When someone publishes an update, Figma offers it in every file that uses those assets, and each person accepts or ignores it.
So the library is only part of the design system. The rest is rules: when to use which component, how to name things, who decides to add a variant. Without those rules, the risk is well known: everyone detaches the instance, changes it on their own, and the library becomes decoration.
02Several brands: separate what is shared from what changes
The first question to settle is not technical. List, brand by brand, what has to stay different: the main colour, often the heading typeface, sometimes the corner radius, the tone of messages. Everything else is meant to be shared: the grid, the spacing, how a field behaves when it shows an error, the accessibility of a button.
To organise this, I work in three layers:
- Raw values: the full palette, the spacing scale, the text sizes. They mean nothing on their own ("blue 600", "space 4").
- Roles: "action colour", "card background", "secondary text". Each role points to a raw value.
- Components: they only use roles, never a raw value or a hard coded colour.
In this model, a brand is simply another set of mappings between roles and values. The button does not know which brand it is drawn for: it asks for the "action colour" and gets the right one.
This is how design tokens work. The W3C Design Tokens Community Group published the first stable version of its specification on 28 October 2025. Its Format Module defines a token as information associated with a human readable name, at minimum a name and value pair, and provides for aliases: a token can point to another one, written between curly braces. Roles are those aliases.
I care about this for a reason that comes from integration work rather than design. On one project, two tools did not use the same unit, centimetres on one side and millimetres on the other, and a whole rendering came out distorted. Since then my rule has been that the reference data is explicit and written in one place. A multi-brand design system applies that rule to colours and spacing.
03Organising it in Figma: library, variables, modes and extended collections
In Figma, roles become variables, grouped into collections. Modes let a single collection hold several sets of values: light and dark, high contrast, screen sizes. An object set to "Auto" takes its parent's mode, so you can switch a whole page at once. The number of modes per collection depends on your plan.
For several brands, the simplest option is one mode per brand. It holds as long as each brand does not have several modes of its own: as soon as you need brand A in light and dark, then brand B in light and dark, a single axis of modes is no longer enough.
That is the case Figma added extended collections for. A parent collection carries the structure of variables and modes. Each brand is an extension that inherits everything and only overrides what changes. A variable that has not been overridden follows the parent's updates automatically. The feature is limited to the Enterprise plan, which matters when you decide.
Extensions in the same file or in separate files
In his talk at Schema by Figma 2025, whose transcript I read, Chad Bergman explains that extensions can be defined in the same file as the parent collection, or in separate files that each brand team owns. In the same file, updates propagate straight away and maintenance stays central. In separate files, each team can experiment freely, but updates become harder to publish.
Figma offers a rule of thumb: up to 10 brands, keep everything in the same library; beyond that, use separate files. The same talk announces native import and export of variables in the W3C specification format, which opens the way to tokens shared with the code.
04The method I follow, step by step
Before opening Figma
- Inventory the existing screens of each brand and note the duplicates: how many different buttons, greys and heading sizes.
- Write down the list of what must stay specific to each brand, and have it approved by the people who own those brands. One line per item, with the reason.
- Name the roles with the developers, so that the "action colour" has the same name in Figma and in the code.
In Figma
- Create the raw values, then the roles that point to them, for one brand first.
- Rework the components so that they only use roles. This is the longest step.
- Add the second brand, as a mode or an extended collection, and check every component in both brands, side by side, at the same level of finish.
- Publish the library with a release note, then announce who approves change requests.
Step 6 is one I learnt from mock-ups: when you show several directions at the same level of finish, the discussion finally compares choices, as I describe in the article on building a clickable prototype before development. Putting the brands side by side also exposes the badly named role, the one that works for one brand and breaks the other.
This website applies the same idea on a small scale. I built it myself, and the content appears in phosphor green because a single colour variable is redefined inside the content area, while headings and navigation keep the white. One component, two contexts, one value to change.
05What it costs, and when I would not do it
A design system needs maintaining, and that is where most of them decay. The Nielsen Norman Group article recommends at least one interaction designer, one visual designer and one developer to keep it alive, and notes that it is mostly worth it when the company expects years of repeatable design work. I draw a simple rule from this: no design system without a named person who decides on changes, otherwise the library falls behind the websites.
I would not do it for a prototype or a one-off campaign, nor when the brands have almost nothing in common: forcing a shared foundation then produces components full of exceptions. Extended collections do not solve everything either. They require the Enterprise plan, and Figma's talk warns that modes already applied in files go back to the default after migration: you have to reapply them.
One last limit: Figma is only half of it. If the roles do not also exist in the code, the brands will drift apart anyway, just later. It is the same problem as with an integration specification: as long as both sides are not reading the same document, each one is right in its own corner.
06Where to start on Monday
Take two comparable screens, one per brand, for example the contact page. Count the colours, text sizes and components that differ. Next to each difference, write whether it is intended or accidental. That list will tell you whether a shared design system will save you time, and it gives you the first version of your roles.
This is the kind of work I do on short engagements: a review of what exists, the structure set up live with the team, then a documented handover so that the library lives on without me. Written rules rather than manual fixes are also what keep my content machines on track. If you would like to talk about it, my services page explains how I work.