Дизайн-токены: от палитры до продакшена
Дизайн-токены превращают решения о цвете, отступах и типографике в данные, которые одинаково читают Figma, веб и мобильные приложения. Разберём, как выстроить структуру токенов, чтобы она пережила ребрендинг, тёмную тему и рост команды.
Что такое токен и какую проблему он решает
Токен — это именованное значение дизайн-решения: цвет фона, радиус скругления, размер шрифта, длительность анимации. Вместо #1F6FEB в коде и макетах используется имя, например color.action.primary. Значение хранится в одном месте, а все потребители ссылаются на него.
Без токенов одно и то же решение живёт в нескольких местах: в библиотеке Figma, в CSS, в ресурсах Android и в каталоге цветов iOS. Каждая правка требует ручной синхронизации, и со временем копии расходятся. Появляются «почти одинаковые» оттенки серого, отступ 15 пикселей рядом с 16, и интерфейс теряет консистентность.
Токены решают это за счёт единого источника истины и автоматической сборки. Изменили значение — и после сборки оно обновилось во всех платформах. Но главная ценность даже не в автоматизации, а в том, что имя токена фиксирует намерение: не «синий», а «цвет основного действия». Это упрощает разговор между дизайнерами и разработчиками.
Токенами описывают не только цвета. В типичный набор входят отступы, размеры и начертания шрифтов, межстрочные интервалы, радиусы скругления, толщина границ, тени, прозрачность, z-индексы слоёв, длительности и кривые анимации. Начинать стоит с цвета и отступов: они встречаются чаще всего и дают быстрый эффект.
Три уровня: примитивы, семантика, компоненты
Большинство зрелых систем делят токены на три уровня. Примитивы описывают доступный набор значений: палитру blue.500, шкалу отступов space.4, размеры шрифтов. Они ничего не говорят о применении и напрямую в интерфейсе не используются.
Семантические токены ссылаются на примитивы и описывают роль: color.text.primary, color.surface.raised, color.border.danger. Именно с ними работает большинство компонентов. При смене темы меняется не компонент, а то, на какой примитив указывает семантический токен.
Компонентные токены привязаны к конкретному элементу: button.primary.background, input.border.focus. Они нужны, когда компоненту требуется отклонение от общей семантики или когда систему кастомизируют несколько продуктов. Если компонентных токенов становится больше, чем семантических, это сигнал, что семантика слишком бедная.
Простое правило: компоненты ссылаются на семантику, семантика — на примитивы, а примитивы содержат сырые значения. Прямые ссылки из компонента на примитив допустимы как исключение, но каждое такое место потом мешает при добавлении новой темы.
- примитивы — что вообще бывает
- семантика — для чего используется
- компоненты — где конкретно применяется
Именование, которое не придётся переделывать
Имя токена читают люди, поэтому его структура должна быть предсказуемой. Распространённый шаблон — от общего к частному: категория, свойство, роль, вариант, состояние. Например, color.background.action.primary.hover. Длинно, но по имени понятно всё, а автодополнение в редакторе снимает проблему длины.
Не включайте в семантические имена описание внешнего вида. Токен color.blue-button станет ложью после ребрендинга в зелёный. Также избегайте числовых шкал в семантике: text.size.3 ничего не говорит о назначении, а text.size.body — говорит.
Для шкал примитивов, наоборот, числа удобны. Отступы часто строят на сетке 8pt с половинным шагом 4: space.1 = 4px, space.2 = 8px, space.4 = 16px. Палитры нумеруют от светлого к тёмному с шагом 100 — это позволяет вставить промежуточный оттенок, не ломая соседей.
Договоритесь о словаре заранее и запишите его: «surface» или «background», «danger» или «error», «subtle» или «muted». Синонимы в одной системе — главный источник путаницы.
Формат и источник истины
Технически токены — это структурированные данные, обычно JSON. Сообщество W3C Design Tokens Community Group развивает открытый формат, в котором каждый токен описывается объектом с полями $value и $type, а ссылки на другие токены записываются в фигурных скобках: {color.blue.500}. Этот формат поддерживают многие инструменты, и следовать ему выгоднее, чем изобретать свой.
Главный вопрос — где живёт источник истины. Возможны два подхода. В первом токены редактируются в Figma через переменные и экспортируются в репозиторий плагином или через API. Во втором источник — JSON в репозитории, а Figma синхронизируется из него. Второй вариант лучше подходит командам с ревью кода: каждое изменение проходит через pull request и историю версий.
Какой бы путь вы ни выбрали, источник должен быть один. Если дизайнер правит переменную в Figma, а разработчик — JSON, расхождение неизбежно. Зафиксируйте направление синхронизации и автоматизируйте его.
Храните рядом со значением описание: поле $description в формате W3C подходит для короткого пояснения, когда токен использовать и когда нет. Эти описания потом попадают в документацию и подсказки редактора, и разработчику не нужно гадать, чем surface.raised отличается от surface.overlay.
Сборка: от JSON к CSS, iOS и Android
Из исходного JSON токены собираются в форматы платформ. Для веба это чаще всего CSS custom properties: --color-text-primary: #1A1D21;. Для iOS — Swift-константы или каталог ресурсов, для Android — XML-ресурсы или константы Compose. Самый распространённый инструмент для этого — Style Dictionary, но подойдёт и собственный скрипт, если платформ немного.
Темы удобно реализовать через переопределение семантического слоя. В CSS базовые значения задаются на :root, а тёмная тема переопределяет те же переменные в селекторе [data-theme="dark"] или в медиазапросе prefers-color-scheme. Компоненты при этом не меняются вообще: они ссылаются на семантические переменные.
Решите, какие токены попадают в продакшен. Примитивы в CSS часто не выводят вовсе или выводят с префиксом, который сигнализирует «не использовать напрямую». Это снижает соблазн написать var(--blue-500) в компоненте.
Сборку стоит запускать в CI: при изменении токенов собираются артефакты для всех платформ и публикуются как пакет. Так у каждой команды есть понятная версия, а не случайный файл из чата.
Внедрение, версионирование и контроль
Токены — это публичный API дизайн-системы, и к ним применимы те же правила, что к коду. Используйте семантическое версионирование: изменение значения без смены смысла — патч, новый токен — минорная версия, переименование или удаление — мажорная. Удаляемые токены сначала помечайте устаревшими и оставляйте на один-два релиза.
Хардкод вытесняется постепенно. Начните с линтеров: правило в stylelint, запрещающее цветовые литералы вне файла токенов, сразу покажет масштаб проблемы. Затем мигрируйте по компонентам, начиная с самых используемых. Попытка заменить всё за один спринт обычно заканчивается регрессиями.
Документируйте токены там, где их ищут: в Storybook или на сайте дизайн-системы с превью, значением и примером использования. Для цветовых пар сразу показывайте коэффициент контраста — так проверка доступности становится частью выбора токена, а не отдельной задачей.
Наконец, следите за ростом. Если каждую неделю появляются новые семантические токены под конкретные экраны, словарь размывается. Раз в квартал полезно проводить ревизию: искать неиспользуемые токены, дубли значений и случаи, когда компоненты обходят семантику.
- патч — новое значение того же смысла
- минор — новые токены
- мажор — переименование и удаление
- устаревшие токены живут один-два релиза
Частые вопросы
С какого размера команды нужны дизайн-токены?
Как только один и тот же интерфейс реализуют больше одного человека или больше одной платформы. Даже в небольшом проекте набор CSS-переменных с понятными именами экономит время на правки и подготовку тёмной темы.
Нужно ли выносить в токены все значения?
Нет. В токены стоит выносить повторяющиеся решения: цвета, отступы, типографику, радиусы, тени, длительности. Уникальные значения для одного экрана лучше оставить локальными, иначе словарь разрастётся и перестанет помогать.
Чем семантические токены отличаются от CSS-переменных?
CSS-переменные — способ доставки токенов в веб. Семантический токен — это решение о роли значения, которое может быть выведено и в CSS, и в Swift, и в Android-ресурсы. Переменная без продуманной семантики — просто ещё один способ хранить хардкод.
Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.
