Сталкивался с похожей архитектурой. Я бы строил это не как несколько брендовых дизайн-систем, а как одну Core Design System + semantic tokens + отдельный brand layer.
Базовая схема:
Core Components → Semantic Tokens ← Brand Theme
* Core Components — единый source of truth: anatomy, states, variants, behavior, accessibility.
* Semantic Tokens — контракт между компонентами и брендом (surface-primary, text-primary, action-primary и т.д.).
* Brand Layer — цвета, typography, radius, shadows, imagery и другие допустимые визуальные отличия.
* Компоненты работают только с semantic tokens и ничего не знают о конкретном бренде.
Если есть Figma Enterprise, я бы в первую очередь смотрел на Extended Variable Collections — механизм как раз рассчитан на multi-brand DS: бренд наследует parent collection и переопределяет только необходимые значения. Новые и изменённые токены master-системы наследуются брендами без необходимости копировать компоненты.
Без Enterprise похожую архитектуру можно собрать через Variables + aliases + Modes, но при большом количестве брендов modes начинают хуже масштабироваться.
Ключевое правило лучше фиксировать сразу: brand = configuration, not fork.
То есть бренд может менять заранее определённые themeable properties, но не должен создавать собственные версии базовых компонентов. Overrides я бы тоже не использовал как основу theming — скорее для контента и действительно редких исключений.
Главный риск здесь не цвета, а постепенное появление требований вроде «у Brand B этот Button немного другой». Поэтому на старте важно определить Theme Contract: что бренд имеет право менять, а что остаётся ответственностью Core Design System.
Иначе через пару лет вместо одной масштабируемой системы легко получить несколько разошедшихся дизайн-систем с общим предком.
Простой
