Дизайн-токены: как фирменный стиль превращается в код
Чем токен отличается от переменной
CSS-переменная существует в границах одного проекта и одного языка. Если у вас пять продуктов на разных стеках — React, Swift, Kotlin — переменные придётся дублировать вручную в каждом репозитории, и рассинхрон гарантирован уже через пару спринтов. Токен описывается в нейтральном JSON-формате (стандарт W3C Design Tokens Community Group с полями $value и $type) и транслируется автоматически в нужный синтаксис под каждую платформу.
Практический эффект: примитивный токен blue-500 = #335CFF меняется один раз в источнике. Это автоматически подтягивает изменение во все семантические токены, которые на него ссылаются — bg-primary, text-link — и во все компоненты, которые используют эти семантические токены. Никто не ищет цвет по всему коду и не переименовывает вручную сотни файлов.
Архитектура: сколько уровней нужно на самом деле
Классическая схема — три уровня: примитивные, семантические, компонентные. Но в реальных продуктовых компаниях всё чуть сложнее, особенно когда речь о нескольких брендах под одним зонтиком.
| Уровень | Что описывает | Пример |
|---|---|---|
| Примитивный (Ref) | Сырые значения без смысла | blue-500 = #335CFF |
| Семантический (Sys) | Назначение в интерфейсе | bg-primary → blue-500 |
| Компонентный | Реализация в конкретном UI-элементе | button-primary-bg → bg-primary |
| Брендовый | Утверждённые вариации для каждого бренда | brand-b-button-bg → своя ссылка на Ref |
Четвёртый, брендовый уровень нужен только в white-label или мультибрендовых системах, где один код обслуживает несколько визуальных идентичностей. Если у вас один продукт — не тащите его искусственно, это лишняя сложность без выгоды.
Кейс: как VK Tech ускорила передачу дизайна в код
VK Tech перешла на токены не из любви к моде, а из-за конкретной боли: разработчики тратили часы на подгонку цветов и отступов из макетов Figma под пиксели в коде, а любое изменение темы требовало ручной правки десятков компонентов. После внедрения передача UI из дизайна в код ускорилась — раньше это была рутинная ручная сверка значений, теперь дизайнер может изменять токены и передавать их на фронт буквально в пару кликов.
Отдельный интересный ход — поддержка светлой и тёмной темы с одной базой компонентов. Компоненты не переписывались вообще: команда просто переименовала значения семантических токенов внутри одной темы на другую. Компонентный слой остался неизменным, поменялся только слой смысла — это и есть суть трёхуровневой архитектуры на практике, а не в теории.
Синхронизация Figma и кода без ручной работы
Технически связку между дизайном и разработкой чаще всего строят так:
- Дизайнер редактирует токены в плагине Tokens Studio внутри Figma.
- Плагин синхронизирует изменения с репозиторием на GitHub — связь двусторонняя, то есть код может обновить дизайн-файл, а не только наоборот.
- Токены экспортируются в JSON согласно стандарту W3C.
- Style Dictionary (инструмент от Amazon, фактический стандарт индустрии) генерирует из этого JSON нужные форматы: CSS, SCSS, TypeScript-объекты, конфиг Tailwind, XML для Android, Swift для iOS — одновременно, из одной конфигурации.
- CI/CD подхватывает сгенерированные файлы и раскатывает их по продуктам.
Работает это ровно так, как заявлено, если у команды есть дисциплина: правки токенов идут только через этот пайплайн, а не точечными хаками в CSS «на скорую руку» — иначе источник истины перестаёт быть источником истины уже через месяц.
Кто отвечает за токены и что делать с исключениями
Вот та часть, которую обходят почти все статьи про токены — организационная. Технически внедрить Style Dictionary можно за неделю. Сложнее ответить: кто решает, что blue-500 меняется на blue-600, и как об этом узнают пятнадцать продуктовых команд.
- Владение системой. В компаниях уровня Сбербанка и VK за токенами стоит выделенная команда дизайн-системы, а не отдельный дизайнер «по совместительству». Она принимает решения об изменениях и версионирует их как обычный код — через семантическое версионирование и changelog.
- Вотчинг с продуктовыми командами. Продуктовые команды подписываются на релизы токенов через npm-пакет или git submodule. Обновление — осознанное действие, а не то, что «прилетело само и что-то сломало» в проде в пятницу вечером.
- Обучение. Дизайнеров учат работать с уже существующими семантическими токенами, а не создавать новые под каждую задачу — это главная причина, почему системы разрастаются до неуправляемого состояния.
- Исключения. Когда токен реально не подходит под задачу — маркетинговый лендинг с уникальной акцентной анимацией, например — команда фиксирует это как осознанное отступление с пометкой в коде, а не тихо хардкодит значение. Иначе через год никто не поймёт, где токен, а где случайность.
На каком этапе внедрять и как не переусложнить
Внедрять токены с нуля, на этапе, когда продукта ещё нет или UI меняется каждую неделю, — плохая идея: система будет переписываться быстрее, чем успеет принести пользу. Разумная точка входа — момент, когда у продукта появилось хотя бы 15-20 переиспользуемых компонентов и второй продукт или платформа на подходе.
Сбербанк и VK в этом смысле показывают правильную последовательность: сначала запускается двухуровневая система — примитивы плюс семантика (Ref + Sys). Компонентный уровень добавляют позже, когда возникает реальная потребность в гибкости под платформенные особенности или white-label-варианты. Строить четыре уровня сразу для одного продукта без мультибрендовости — типичное переусложнение, которое замедляет команду, а не ускоряет.
Нейминг: почему структура имени важнее самого имени
Плохой нейминг убивает даже идеально спроектированную систему токенов — разработчик просто не найдёт нужный токен и захардкодит значение. W3C-стандарт с полями $value и $type позволил инструментам генерировать имена по объектно-ориентированному подходу: сначала объект, потом его свойство. Отсюда правило — button-primary-bg-color, а не color-button-bg-primary.
Разница не косметическая. Первый вариант группируется в автокомплите IDE по компоненту — начинаешь печатать «button» и видишь все его токены сразу. Второй вариант группируется по типу значения, что удобно только для дизайнеров цвета, но неудобно для 90% разработчиков, которые думают компонентами, а не палитрой.
Чем токен отличается от переменной
CSS-переменная существует в границах одного проекта и одного языка. Если у вас пять продуктов на разных стеках — React, Swift, Kotlin — переменные придётся дублировать вручную в каждом репозитории, и рассинхрон гарантирован уже через пару спринтов. Токен описывается в нейтральном JSON-формате (стандарт W3C Design Tokens Community Group с полями $value и $type) и транслируется автоматически в нужный синтаксис под каждую платформу.
Практический эффект: примитивный токен blue-500 = #335CFF меняется один раз в источнике. Это автоматически подтягивает изменение во все семантические токены, которые на него ссылаются — bg-primary, text-link — и во все компоненты, которые используют эти семантические токены. Никто не ищет цвет по всему коду и не переименовывает вручную сотни файлов.
Архитектура: сколько уровней нужно на самом деле
Классическая схема — три уровня: примитивные, семантические, компонентные. Но в реальных продуктовых компаниях всё чуть сложнее, особенно когда речь о нескольких брендах под одним зонтиком.
| Уровень | Что описывает | Пример |
|---|---|---|
| Примитивный (Ref) | Сырые значения без смысла | blue-500 = #335CFF |
| Семантический (Sys) | Назначение в интерфейсе | bg-primary → blue-500 |
| Компонентный | Реализация в конкретном UI-элементе | button-primary-bg → bg-primary |
| Брендовый | Утверждённые вариации для каждого бренда | brand-b-button-bg → своя ссылка на Ref |
Четвёртый, брендовый уровень нужен только в white-label или мультибрендовых системах, где один код обслуживает несколько визуальных идентичностей. Если у вас один продукт — не тащите его искусственно, это лишняя сложность без выгоды.
Кейс: как VK Tech ускорила передачу дизайна в код
VK Tech перешла на токены не из любви к моде, а из-за конкретной боли: разработчики тратили часы на подгонку цветов и отступов из макетов Figma под пиксели в коде, а любое изменение темы требовало ручной правки десятков компонентов. После внедрения передача UI из дизайна в код ускорилась — раньше это была рутинная ручная сверка значений, теперь дизайнер может изменять токены и передавать их на фронт буквально в пару кликов.
Отдельный интересный ход — поддержка светлой и тёмной темы с одной базой компонентов. Компоненты не переписывались вообще: команда просто переименовала значения семантических токенов внутри одной темы на другую. Компонентный слой остался неизменным, поменялся только слой смысла — это и есть суть трёхуровневой архитектуры на практике, а не в теории.
Синхронизация Figma и кода без ручной работы
Технически связку между дизайном и разработкой чаще всего строят так:
- Дизайнер редактирует токены в плагине Tokens Studio внутри Figma.
- Плагин синхронизирует изменения с репозиторием на GitHub — связь двусторонняя, то есть код может обновить дизайн-файл, а не только наоборот.
- Токены экспортируются в JSON согласно стандарту W3C.
- Style Dictionary (инструмент от Amazon, фактический стандарт индустрии) генерирует из этого JSON нужные форматы: CSS, SCSS, TypeScript-объекты, конфиг Tailwind, XML для Android, Swift для iOS — одновременно, из одной конфигурации.
- CI/CD подхватывает сгенерированные файлы и раскатывает их по продуктам.
Работает это ровно так, как заявлено, если у команды есть дисциплина: правки токенов идут только через этот пайплайн, а не точечными хаками в CSS «на скорую руку» — иначе источник истины перестаёт быть источником истины уже через месяц.
Кто отвечает за токены и что делать с исключениями
Вот та часть, которую обходят почти все статьи про токены — организационная. Технически внедрить Style Dictionary можно за неделю. Сложнее ответить: кто решает, что blue-500 меняется на blue-600, и как об этом узнают пятнадцать продуктовых команд.
- Владение системой. В компаниях уровня Сбербанка и VK за токенами стоит выделенная команда дизайн-системы, а не отдельный дизайнер «по совместительству». Она принимает решения об изменениях и версионирует их как обычный код — через семантическое версионирование и changelog.
- Вотчинг с продуктовыми командами. Продуктовые команды подписываются на релизы токенов через npm-пакет или git submodule. Обновление — осознанное действие, а не то, что «прилетело само и что-то сломало» в проде в пятницу вечером.
- Обучение. Дизайнеров учат работать с уже существующими семантическими токенами, а не создавать новые под каждую задачу — это главная причина, почему системы разрастаются до неуправляемого состояния.
- Исключения. Когда токен реально не подходит под задачу — маркетинговый лендинг с уникальной акцентной анимацией, например — команда фиксирует это как осознанное отступление с пометкой в коде, а не тихо хардкодит значение. Иначе через год никто не поймёт, где токен, а где случайность.
На каком этапе внедрять и как не переусложнить
Внедрять токены с нуля, на этапе, когда продукта ещё нет или UI меняется каждую неделю, — плохая идея: система будет переписываться быстрее, чем успеет принести пользу. Разумная точка входа — момент, когда у продукта появилось хотя бы 15-20 переиспользуемых компонентов и второй продукт или платформа на подходе.
Сбербанк и VK в этом смысле показывают правильную последовательность: сначала запускается двухуровневая система — примитивы плюс семантика (Ref + Sys). Компонентный уровень добавляют позже, когда возникает реальная потребность в гибкости под платформенные особенности или white-label-варианты. Строить четыре уровня сразу для одного продукта без мультибрендовости — типичное переусложнение, которое замедляет команду, а не ускоряет.
Нейминг: почему структура имени важнее самого имени
Плохой нейминг убивает даже идеально спроектированную систему токенов — разработчик просто не найдёт нужный токен и захардкодит значение. W3C-стандарт с полями $value и $type позволил инструментам генерировать имена по объектно-ориентированному подходу: сначала объект, потом его свойство. Отсюда правило — button-primary-bg-color, а не color-button-bg-primary.
Разница не косметическая. Первый вариант группируется в автокомплите IDE по компоненту — начинаешь печатать «button» и видишь все его токены сразу. Второй вариант группируется по типу значения, что удобно только для дизайнеров цвета, но неудобно для 90% разработчиков, которые думают компонентами, а не палитрой.
Актуальные статьи
МегаФон, BMW, ВТБ и ещё 240+ компаний. Смотрите как это выглядит в шоуриле:
В наше брендинговое агентство обращаются, чтобы заказать:
