Момент, коли з'являється другий бренд, ламає більшість дизайн-систем. Агенція бере другого клієнта. Продукт запускає white-label-версію для партнера. Банк відкриває окремий необанк для молоді. І перша реакція команди — скопіювати всю бібліотеку, перефарбувати кнопки й жити з двома окремими Figma-файлами.

Через півроку це коштує вам подвійної роботи на кожен фікс. Знайшли баг у Button — правите двічі. Додали новий стан — двічі. Три бренди — тричі. Форк дизайн-системи не масштабується лінійно, він масштабується боляче.

Правильна відповідь інша: одна система компонентів, кілька наборів токенів. Бренд — це не окрема бібліотека, а окремий шар значень. Розберемо, як це побудувати так, щоб десятий бренд додавався за годину, а не за спринт.

Три рівні токенів — фундамент усього

Мульти-бренд неможливий без чіткого поділу токенів на рівні. Це не теорія заради теорії — саме межа між рівнями визначає, що змінюється від бренду до бренду, а що лишається спільним.

  • Примітиви — сира палітра. blue-500, green-400, space-4. Без сенсу, без контексту. Просто значення.
  • Семантика — роль. color-action-primary, color-surface, color-text-default. Вона посилається на примітив, але описує призначення.
  • Компонентні — за потреби. button-bg → посилається на color-action-primary. Потрібні лише коли компонент має власну логіку, що відхиляється від семантики.

Ключ мульти-бренду ось у чому: компоненти й код читають тільки семантику. Кнопка ніколи не знає, що вона «синя». Вона знає, що її фон — color-action-primary. А чим саме є цей action-колір — синім у бренда А чи фіолетовим у бренда Б — вирішує шар нижче. Якщо ви ще не розкладали токени на примітиви та семантику, почніть звідти — без цього поділу мульти-бренд просто не тримається.

Бренд — це мод, а не форк

У Figma Variables є режими (modes) — саме той механізм, який тут потрібен. Один раз ви вже могли бачити його для теми: mode «Light» і mode «Dark». Мульти-бренд працює абсолютно так само, тільки моди називаються за брендами.

Створіть колекцію Brand з модами Brand A, Brand B, Brand C. У кожному моді семантичні токени вказують на різні примітиви:

color-action-primary
Brand A → blue-500
Brand B → violet-600
Brand C → orange-500

Тепер перемикання моду на рівні фрейму або сторінки миттєво перефарбовує всі компоненти під потрібний бренд. Один макет, один клік — інша ідентичність. Компоненти при цьому не дублюються: усі бренди спільно користуються одним Button, одним Card, одним Input.

Якщо потрібні ще й світла/темна теми всередині кожного бренду — це друга колекція модів (Theme), що комбінується з першою. Дві осі варіативності, жодного форку.

Практика: розкладаємо два бренди

Припустимо, у вас фінтех-платформа, що продає white-label-гаманець двом партнерам. Ось як виглядає розкладка крок за кроком.

  1. Зберіть примітиви обох брендів в одну колекцію. Палітра А і палітра Б живуть поряд: brandA-blue-500, brandB-violet-600. Це просто значення, вони нікому не заважають.
  2. Створіть семантичний шар з модами. Колекція Semantic, моди A і B. Кожен семантичний токен отримує два значення — по одному на мод.
  3. Прив'яжіть компоненти лише до семантики. Перевірте кожен компонент: якщо десь лишився прямий примітив (наприклад, фон захардкоджено на blue-500) — це витік, який зламає другий бренд.
  4. Не забудьте нейтралі й радіуси. Часто бренди відрізняються не лише акцентом: інші сірі, інша скруглість, інша щільність. Виносьте radius і нейтральну шкалу в токени теж, інакше «однакові» кнопки виглядатимуть чужими.

Після цього перевірка проста: перемкніть мод і пройдіться по всіх екранах. Усе, що не змінилося або зламалося — це компонент, який досі тримається за примітив напряму.

Експорт у W3C JSON і генерація коду

Дизайн у Figma — половина справи. Друга половина — щоб код кожного бренду будувався з тих самих токенів автоматично, без ручного копіювання HEX-ів у CSS.

Робочий конвеєр 2026 року виглядає так:

  1. Експортуйте Figma Variables у W3C DTCG-формат — стандартизований JSON, де кожен токен має $value і $type. Кожен бренд-мод стає окремим файлом: brand-a.json, brand-b.json.
  2. Проженіть JSON через Style Dictionary — генератор, що перетворює токени на CSS-змінні, TypeScript-константи, iOS та Android-ресурси. Один вхід — кілька виходів.
  3. На виході — окремий CSS-файл на бренд: theme-a.css, theme-b.css. Компоненти в коді читають CSS-змінні (var(--color-action-primary)), а який саме файл підключено — визначає бренд.

Найкраще тут те, що весь ланцюжок автоматизується. Дизайнер міняє токен у Figma → експорт → Style Dictionary → пул-реквест з оновленими темами. Ніхто не переносить значення руками, а отже ніхто їх не переплутає. У курсі ми збираємо цей конвеєр з Claude і Figma MCP — AI генерує конфіг Style Dictionary і синхронізує токени за один промпт.

Компоненти лишаються одні — і це головний виграш

Уся суть підходу — у тому, що не дублюється. Виправили баг у Button — він виправлений для всіх брендів одразу. Додали новий компонент — він доступний усім. Оновили відступи в Card — оновилися скрізь.

Бренди відрізняються рівно на товщину шару токенів. Це може бути 40–60 значень: акценти, нейтралі, радіуси, іноді типографіка. Усе інше — структура, стани, логіка, доступність — спільне. Саме тому десятий бренд коштує години: ви заповнюєте ще один мод, а не будуєте систему заново.

Типові помилки, що ламають масштабування

  • Хардкод примітивів у компонентах. Найпоширеніший витік. Один #0A84FF, забутий у тіні або border, — і другий бренд отримує чужий синій.
  • Занадто рання компонентна семантика. Не робіть button-primary-bg-brandA. Бренд ніколи не має бути частиною назви токена — інакше ви вшиваєте його в структуру.
  • Спроба зробити «все токеном». Якщо бренди відрізняються лише палітрою — не виносьте в моди кожен піксель. Токенізуйте те, що реально варіюється.
  • Ігнорування контрасту. Акцент бренда Б може провалювати WCAG на тому ж фоні, де бренд А проходить. Кожен мод потребує окремої перевірки контрасту, а не припущення «якщо для А ок, то й для Б».

Мульти-бренд — це не про більше файлів, а про правильну межу між тим, що спільне, і тим, що змінне. Проведіть цю межу через шар токенів один раз — і кожен наступний бренд стане заповненням таблиці, а не новим проєктом. Розбір таких архітектур на реальних кейсах ми показуємо і на YouTube-каналі UX Hero.