Design tokens: как хранить и масштабировать стиль бренда в коде
Двухуровневая или трёхуровневая архитектура: выбор зависит от масштаба продукта
Классическая схема primitive → semantic → component хороша не всегда. Для команды с одним продуктом и одной темой третий уровень часто избыточен — он добавляет слой абстракции, который никто не читает, а поддерживать приходится вдвое больше файлов.
| Критерий | 2 уровня (primitive → component) | 3 уровня (primitive → semantic → component) |
|---|---|---|
| Продукт с одной темой, без ребрендинга | Подходит | Избыточно |
| Поддержка light/dark, мультибренд | Не работает без переписывания компонентов | Обязателен — как в Material Design 3, где смена темы происходит через семантическую переподстановку без изменения логики компонентов |
| Команда до 5 разработчиков | Достаточно, ниже порог входа | Оверхед на старте |
| Продуктовая линейка на нескольких платформах | Быстро упирается в дублирование | Оправдан, семантический слой развязывает платформы |
Правило простое: если в дорожной карте есть тема, ребренд или мультибренд — берите три уровня сразу, переход с двух на три задним числом болезненный и требует ручной миграции всех ссылок.
Синхронизация Figma и кода: где реально ломается процесс
Здесь топ выдачи обычно ограничивается фразой «настройте синхронизацию через плагин», но проблема не в настройке, а в её хрупкости. Tokens Studio остаётся единственным плагином с полноценной двусторонней синхронизацией с Git-репозиторием, и даже там расхождения возникают регулярно — из-за конфликтов веток, ручных правок в коде «мимо» токенов и разного порядка мержа.
Показательный кейс — инцидент Figma Dev Mode 2.0 в октябре 2024 года: автоматическое удаление префиксов из имён токенов вызвало коллизии и рассинхрон в 12 продакшн-компонентах. Урок из него простой — любое автоматическое преобразование имён нужно тестировать на копии продакшн-набора перед обновлением плагина, а не доверять дефолтным настройкам инструмента.
- Дизайнер переименовывает токен локально в Figma без пуша в репозиторий — код и дизайн расходятся молча.
- Разработчик хардкодит значение «на один пиксель точнее», чем в токене — появляется теневой дубль.
- Обновление плагина меняет формат экспорта — ломается пайплайн трансформации в Style Dictionary.
Все три проблемы лечатся не инструментом, а процессом: CI-проверка, которая блокирует мерж, если значение токена в коде не совпадает с исходником в Git, и запрет на прямые правки токенов в Figma без пул-реквеста.
Governance: почему системы токенов разваливаются после запуска
Франческо Импрота точно формулирует суть проблемы: системы токенов деградируют не из-за инструментов, а из-за отсутствия процесса управления. Без владельца компонент-слоя, без approval workflow и без стратегии deprecation система разрушается в течение месяцев — разработчики начинают заводить локальные переменные «потому что через токен долго», и дублирование нарастает незаметно.
- Назначьте владельца токенов — не дизайнера «по совместительству», а роль с полномочием отклонять новый токен, если для задачи уже есть подходящий.
- Введите approval workflow: новый токен проходит ревью так же, как код — с обязательным ответом на вопрос «почему существующие семантические токены не подходят».
- Зафиксируйте deprecation-стратегию: токен помечается deprecated, живёт минимум один релизный цикл с предупреждением в коде, потом удаляется — без этого шага список токенов только растёт.
- Проводите квартальный аудит: сколько токенов реально используется в компонентах, сколько — мёртвый вес.
Хорошая система против плохой: как это измерить, а не почувствовать
Разница между рабочей и сломанной системой не в красоте документации, а в конкретных цифрах. Knapsack в исследовании 2023 года показал: команды с консистентной нейминг-конвенцией решают проблемы design-to-code handoff на 38% быстрее, чем команды без стандартов — это измеримый, а не абстрактный эффект.
| Метрика | Хорошая система | Плохая реализация |
|---|---|---|
| Доля хардкодных значений в коде компонентов | Близко к нулю, есть lint-правило | Растёт со временем, никто не отслеживает |
| Именование токенов | По роли: color-action-primary | По внешнему виду: primary-500 — ломается при ребренде |
| Синхронизация Figma/код | Автоматическая, с CI-проверкой | Ручная, «раз в спринт» |
| Владелец системы | Назначен, есть approval-процесс | Никого нет, любой добавляет токен по своему желанию |
Отдельно стоит запомнить архитектурную ошибку, которая почти не заметна на старте: назвать токен по внешнему виду вместо роли. primary-500 работает, пока в продукте один бренд и одна тема. При ребрендинге или запуске второго бренда такое имя требует переписывания всех ссылок, потому что смысл токена жёстко привязан к конкретному оттенку, а не к функции.
Token bloat: как компонентные токены превращаются в сотни позиций
Tetrisly столкнулась с показательной проблемой — 500+ токенов только для одного компонента Button, если перемножить все состояния, варианты и темы. В этот момент абстракция теряет смысл: искать нужный токен дольше, чем написать значение напрямую, а сама идея переиспользования разваливается.
Избежать этого можно только если ограничивать комбинаторику осознанно, а не автоматически генерировать токен на каждое пересечение параметров:
- Разделяйте состояния (hover, disabled) через модификаторы поверх базового семантического токена, а не создавайте отдельный токен на каждую комбинацию.
- Считайте токены компонента лимитом — если их больше 20-30 на компонент, это сигнал пересмотреть архитектуру, а не расширять список.
- Используйте наследование через семантический слой: тема меняет значение на уровне semantic-токена, компонентный слой не должен знать про тему вообще.
Когда токены вообще не нужны
Это тот вывод, который редко встречается в статьях про настройку, а зря. Если продукт — это лендинг с одной темой, без планов на ребрендинг, без нескольких платформ и без команды дизайнеров, которая меняется — токены добавят оверхед, который никогда не окупится. Три уровня абстракции, пайплайн трансформации через Style Dictionary, синхронизация с Git — это инфраструктура, оправданная только там, где стиль меняется чаще, чем раз в год, или используется в нескольких продуктах одновременно.
Формат хранения тоже стоит выбирать по факту, а не по моде: W3C Design Tokens Community Group стандартизирует JSON-формат, но большинство систем на рынке используют его лишь частично — и это нормально, если внутренняя команда договорилась о едином соглашении и следует ему без исключений. Стандарт нужен там, где токены будут переноситься между инструментами разных вендоров; для закрытой внутренней системы важнее дисциплина, а не соответствие спецификации.
Двухуровневая или трёхуровневая архитектура: выбор зависит от масштаба продукта
Классическая схема primitive → semantic → component хороша не всегда. Для команды с одним продуктом и одной темой третий уровень часто избыточен — он добавляет слой абстракции, который никто не читает, а поддерживать приходится вдвое больше файлов.
| Критерий | 2 уровня (primitive → component) | 3 уровня (primitive → semantic → component) |
|---|---|---|
| Продукт с одной темой, без ребрендинга | Подходит | Избыточно |
| Поддержка light/dark, мультибренд | Не работает без переписывания компонентов | Обязателен — как в Material Design 3, где смена темы происходит через семантическую переподстановку без изменения логики компонентов |
| Команда до 5 разработчиков | Достаточно, ниже порог входа | Оверхед на старте |
| Продуктовая линейка на нескольких платформах | Быстро упирается в дублирование | Оправдан, семантический слой развязывает платформы |
Правило простое: если в дорожной карте есть тема, ребренд или мультибренд — берите три уровня сразу, переход с двух на три задним числом болезненный и требует ручной миграции всех ссылок.
Синхронизация Figma и кода: где реально ломается процесс
Здесь топ выдачи обычно ограничивается фразой «настройте синхронизацию через плагин», но проблема не в настройке, а в её хрупкости. Tokens Studio остаётся единственным плагином с полноценной двусторонней синхронизацией с Git-репозиторием, и даже там расхождения возникают регулярно — из-за конфликтов веток, ручных правок в коде «мимо» токенов и разного порядка мержа.
Показательный кейс — инцидент Figma Dev Mode 2.0 в октябре 2024 года: автоматическое удаление префиксов из имён токенов вызвало коллизии и рассинхрон в 12 продакшн-компонентах. Урок из него простой — любое автоматическое преобразование имён нужно тестировать на копии продакшн-набора перед обновлением плагина, а не доверять дефолтным настройкам инструмента.
- Дизайнер переименовывает токен локально в Figma без пуша в репозиторий — код и дизайн расходятся молча.
- Разработчик хардкодит значение «на один пиксель точнее», чем в токене — появляется теневой дубль.
- Обновление плагина меняет формат экспорта — ломается пайплайн трансформации в Style Dictionary.
Все три проблемы лечатся не инструментом, а процессом: CI-проверка, которая блокирует мерж, если значение токена в коде не совпадает с исходником в Git, и запрет на прямые правки токенов в Figma без пул-реквеста.
Governance: почему системы токенов разваливаются после запуска
Франческо Импрота точно формулирует суть проблемы: системы токенов деградируют не из-за инструментов, а из-за отсутствия процесса управления. Без владельца компонент-слоя, без approval workflow и без стратегии deprecation система разрушается в течение месяцев — разработчики начинают заводить локальные переменные «потому что через токен долго», и дублирование нарастает незаметно.
- Назначьте владельца токенов — не дизайнера «по совместительству», а роль с полномочием отклонять новый токен, если для задачи уже есть подходящий.
- Введите approval workflow: новый токен проходит ревью так же, как код — с обязательным ответом на вопрос «почему существующие семантические токены не подходят».
- Зафиксируйте deprecation-стратегию: токен помечается deprecated, живёт минимум один релизный цикл с предупреждением в коде, потом удаляется — без этого шага список токенов только растёт.
- Проводите квартальный аудит: сколько токенов реально используется в компонентах, сколько — мёртвый вес.
Хорошая система против плохой: как это измерить, а не почувствовать
Разница между рабочей и сломанной системой не в красоте документации, а в конкретных цифрах. Knapsack в исследовании 2023 года показал: команды с консистентной нейминг-конвенцией решают проблемы design-to-code handoff на 38% быстрее, чем команды без стандартов — это измеримый, а не абстрактный эффект.
| Метрика | Хорошая система | Плохая реализация |
|---|---|---|
| Доля хардкодных значений в коде компонентов | Близко к нулю, есть lint-правило | Растёт со временем, никто не отслеживает |
| Именование токенов | По роли: color-action-primary | По внешнему виду: primary-500 — ломается при ребренде |
| Синхронизация Figma/код | Автоматическая, с CI-проверкой | Ручная, «раз в спринт» |
| Владелец системы | Назначен, есть approval-процесс | Никого нет, любой добавляет токен по своему желанию |
Отдельно стоит запомнить архитектурную ошибку, которая почти не заметна на старте: назвать токен по внешнему виду вместо роли. primary-500 работает, пока в продукте один бренд и одна тема. При ребрендинге или запуске второго бренда такое имя требует переписывания всех ссылок, потому что смысл токена жёстко привязан к конкретному оттенку, а не к функции.
Token bloat: как компонентные токены превращаются в сотни позиций
Tetrisly столкнулась с показательной проблемой — 500+ токенов только для одного компонента Button, если перемножить все состояния, варианты и темы. В этот момент абстракция теряет смысл: искать нужный токен дольше, чем написать значение напрямую, а сама идея переиспользования разваливается.
Избежать этого можно только если ограничивать комбинаторику осознанно, а не автоматически генерировать токен на каждое пересечение параметров:
- Разделяйте состояния (hover, disabled) через модификаторы поверх базового семантического токена, а не создавайте отдельный токен на каждую комбинацию.
- Считайте токены компонента лимитом — если их больше 20-30 на компонент, это сигнал пересмотреть архитектуру, а не расширять список.
- Используйте наследование через семантический слой: тема меняет значение на уровне semantic-токена, компонентный слой не должен знать про тему вообще.
Когда токены вообще не нужны
Это тот вывод, который редко встречается в статьях про настройку, а зря. Если продукт — это лендинг с одной темой, без планов на ребрендинг, без нескольких платформ и без команды дизайнеров, которая меняется — токены добавят оверхед, который никогда не окупится. Три уровня абстракции, пайплайн трансформации через Style Dictionary, синхронизация с Git — это инфраструктура, оправданная только там, где стиль меняется чаще, чем раз в год, или используется в нескольких продуктах одновременно.
Формат хранения тоже стоит выбирать по факту, а не по моде: W3C Design Tokens Community Group стандартизирует JSON-формат, но большинство систем на рынке используют его лишь частично — и это нормально, если внутренняя команда договорилась о едином соглашении и следует ему без исключений. Стандарт нужен там, где токены будут переноситься между инструментами разных вендоров; для закрытой внутренней системы важнее дисциплина, а не соответствие спецификации.
Актуальные статьи
МегаФон, BMW, ВТБ и ещё 240+ компаний. Смотрите как это выглядит в шоуриле:
В наше брендинговое агентство обращаются, чтобы заказать:
