Design tokens: системный подход к дизайн-системам

В небольшом проекте дизайнеры просто рисуют интерфейс в Figma, разработчики реализуют его в коде, цвета и шрифты живут параллельно в двух местах. Через несколько лет проект разрастается: десятки экранов, мобильное приложение, лендинги, документация. Каждое незначительное изменение — другой оттенок основного цвета, новый размер шрифта — превращается в недели работы, потому что менять нужно в сотнях мест.

Design tokens — структурный ответ на эту проблему. Это не просто переменные с цветами, а полноценная инфраструктура управления дизайн-системой, обеспечивающая единый источник правды для всех платформ и форматов. Разбираем устройство design tokens, их типологию, как они интегрируются с инструментами дизайна и кода, какие задачи решают и какие проблемы создают при внедрении.

Концепция design tokens

Design tokens — именованные сущности, представляющие визуальные атрибуты дизайн-системы. Цвета, размеры шрифтов, отступы, радиусы скругления, тени, продолжительность анимаций — всё это вместо «магических» значений в коде описывается через токены с понятными именами.

Вместо color: #0066CC в CSS пишется color: var(—color-brand-primary). Вместо margin-top: 16px — margin-top: var(—spacing-md). Это даёт уровень абстракции: токен один раз определяется в дизайн-системе, потом используется во всех компонентах и приложениях. Изменение значения токена автоматически распространяется на всё, что его использует.

Три уровня токенов: primitive, semantic, component

Зрелая дизайн-система выстраивается на трёх уровнях токенов, каждый со своим назначением.

Primitive (базовые) tokens — фундаментальные значения без семантики. Например, blue-500: #0066CC, blue-600: #0052A3, gray-100: #F5F5F5. Эти имена описывают цвет, не его роль в интерфейсе. Базовые токены — палитра, из которой строится всё остальное.

Semantic (семантические) tokens — указывают на роль значения в интерфейсе. Например, color-action-primary: blue-500, color-text-secondary: gray-600. Семантический токен ссылается на primitive, добавляя смысл: «вот этот цвет используется для кнопок основного действия». При смене палитры меняются связи semantic → primitive, а сами семантические имена остаются стабильными.

Component (компонентные) tokens — специфичные для конкретного компонента. button-primary-background-color: color-action-primary. Третий уровень даёт максимальную гибкость для тонкой настройки отдельных компонентов без затрагивания общих семантических токенов.

Трёхуровневая структура — главный признак зрелой дизайн-системы. Без неё токены либо слишком хаотичны (только primitive), либо слишком жёстки (только semantic). С тремя уровнями каждое изменение находит свой уровень с минимальным влиянием на остальное.

Темизация и переменные

Один из главных бизнес-кейсов для design tokens — поддержка нескольких тем. Дневная и ночная темы, высококонтрастный режим для accessibility, темы под разные бренды (white-label решения), темы под праздничные периоды.

Реализуется через переопределение semantic токенов в каждой теме. Primitive остаются теми же (палитра не меняется), semantic меняют ссылки на primitive: в светлой теме color-background-page: gray-50, в тёмной — color-background-page: gray-900. Компоненты ссылаются только на semantic токены, поэтому переключаются автоматически.

В CSS темизация через токены реализуется элегантно: атрибут data-theme на корневом элементе и наборы переменных под каждую тему. Переключение темы — изменение одного атрибута, после которого все цвета обновляются мгновенно через каскадирование CSS-переменных.

W3C Design Tokens Format

Долгое время в индустрии отсутствовал стандарт описания токенов — каждая команда использовала свой JSON-формат. В 2023 году появилась первая редакция W3C Design Tokens Community Group Format Module — попытка унифицировать описание токенов на уровне индустрии.

Стандарт определяет JSON-формат с обязательными полями: $value (значение), $type (тип, например color или dimension), $description (опциональное описание). Поддерживаются токены-алиасы через ссылки на другие токены: например, button-bg: { $value: «{color.brand.primary}» }.

Стандартизация позволяет инструментам работать с токенами совместимо. Figma может экспортировать токены в стандартном формате, инструменты типа Style Dictionary импортировать и трансформировать под разные платформы. К 2026 году большинство ведущих инструментов поддерживают формат W3C.

Style Dictionary и трансформация токенов

Один и тот же токен должен быть доступен в разных форматах: CSS-переменные для веба, Swift-структуры для iOS, XML-ресурсы для Android, JSON для документации, рисунки для дизайн-инструментов. Ручная синхронизация невозможна — слишком много мест для ошибки.

Style Dictionary от Amazon — самый популярный инструмент трансформации токенов. Берёт исходные токены в JSON, применяет настраиваемые transforms (для преобразования значений) и formats (для генерации файлов под разные платформы). На выходе — CSS, SCSS, JS-объект, Swift-код, Android XML, всё из одного источника.

Интеграция с Figma

Figma долгое время хранила стили (colors, text styles) в собственном формате, не имеющем выхода в код. В 2023 году Figma представила Variables — структурированную систему для управления значениями, очень близкую к концепции design tokens.

Variables в Figma поддерживают: разные типы (color, number, string, boolean), переключение между collections (аналог тем), алиасы между переменными, scope для ограничения использования. Это сделало Figma полноценным инструментом для дизайна токенов, не только их использования.

Интеграция Figma Variables с кодом реализуется через плагины. Популярные решения: Tokens Studio (бывший Figma Tokens), Variables2JSON, Specify. Каждый позволяет экспортировать переменные Figma в JSON и далее трансформировать через Style Dictionary в код для разных платформ.

Tailwind CSS и токены

Tailwind CSS — популярный фреймворк, в основе которого фактически лежит концепция токенов. tailwind.config.js — это файл токенов: цвета, отступы, размеры шрифтов, точки брейкпоинтов. Tailwind генерирует utility-классы на основе этих токенов: bg-blue-500, p-4, text-lg.

Для команд, использующих Tailwind, design tokens интегрируются естественно. Конфиг Tailwind становится главным источником токенов для веба, остальные платформы могут синхронизироваться через Style Dictionary с тем же набором значений. Гибкость Tailwind в настройке делает его особенно подходящим для проектов с устоявшейся дизайн-системой.

Naming conventions: как называть токены

Названия токенов — одна из самых сложных задач в дизайн-системе. Хорошее имя описывает роль, не значение. Плохое имя привязывает к конкретной реализации, теряя гибкость при изменениях.

• Плохо: color-blue (что если бренд сменит цвет?)
• Лучше: color-brand-primary (роль ясна)
• Плохо: margin-16 (что если базовое значение изменится?)
• Лучше: spacing-md (относительный размер)
• Плохо: button-blue-background
• Лучше: button-primary-background

Многие команды используют систему категория-свойство-вариант: color-text-primary, color-text-secondary, color-background-page, color-background-card. Это даёт предсказуемые имена и упрощает поиск нужного токена.

Density и responsive tokens

Сложные интерфейсы требуют разных значений токенов для разных контекстов. Density tokens — наборы значений для разных плотностей интерфейса: compact для data-heavy дашбордов, comfortable для обычных приложений, spacious для маркетинговых лендингов. Один и тот же button может занимать разную высоту в разных density-режимах.

Responsive tokens — значения, меняющиеся в зависимости от размера экрана. Базовый шрифт на десктопе 16px, на планшете 17px, на смартфоне 16px. Адаптивные токены управляются через media queries в CSS или через утилитные функции в JavaScript-фреймворках.

Accessibility через токены

Design tokens упрощают соблюдение требований accessibility. Контраст цветов, размеры кликабельных элементов, минимальные расстояния между ними — всё это можно зашить в токены и обеспечить compliance на уровне дизайн-системы.

Например, можно определить токены минимальных контрастов: color-text-on-primary должен иметь контраст не меньше 4.5:1 с color-background-primary. Если кто-то меняет значение primary, автоматический тест проверяет, не нарушился ли контраст. Такие проверки встраиваются в CI/CD дизайн-системы.

Версионирование и эволюция

Дизайн-система — живой организм, эволюционирующий со временем. Токены добавляются, удаляются, переименовываются. Без формального процесса это создаёт хаос: некоторые команды используют старые имена, другие — новые, не вся продукция перестраивается на новые токены одновременно.

Зрелые дизайн-системы версионируют свой набор токенов. Семантическое версионирование (semver) с явными правилами что считать breaking change. Депрекация старых токенов с периодом параллельной поддержки. Скрипты миграции, помогающие командам переходить на новые версии.

В крупных компаниях вокруг дизайн-системы вырастает отдельная команда design system engineering, отвечающая за инфраструктуру токенов, документацию, инструменты, миграции. Это серьёзная инвестиция, окупающаяся в больших масштабах через единство пользовательского опыта между продуктами.

Внедрение в существующий проект

Внедрить design tokens в новый проект просто — сразу строится правильно. Внедрить в существующий — сложная задача, требующая миграции десятков или сотен компонентов и страниц.

Поэтапный подход обычно работает лучше «большого взрыва». Несколько типичных этапов.

• Аудит: найти все используемые цвета, размеры, шрифты в существующем коде
• Кодификация: определить токены, покрывающие найденные значения
• Внедрение в новые компоненты: все новые разработки используют токены
• Постепенная миграция: при работе над существующими компонентами заменять hardcoded-значения на токены
• Финальная очистка: удалить старые hardcoded значения, провести полную проверку

Сразу 100% миграция возможна только в небольших проектах. Для крупных систем это процесс на год и больше, требующий координации между командами.

Часто задаваемые вопросы

С какого размера проекта имеет смысл внедрять design tokens?

С момента, когда дизайн используется в нескольких приложениях или платформах, или когда есть несколько команд разработки. Для одностраничного приложения один разработчика — overkill. Для продуктовой команды из 10+ разработчиков и/или нескольких платформ — практически обязательно для поддержания консистентности.

Чем design tokens отличаются от CSS-переменных?

CSS-переменные — техническая реализация для веба. Design tokens — концепция, выходящая за пределы CSS. Токены могут существовать в JSON, потом трансформироваться в CSS-переменные, Swift-константы, XML-ресурсы. Toкен — это абстрактный design decision; CSS-переменная — один из способов его проявления в коде.

Нужны ли component tokens или хватает primitive и semantic?

Зависит от размера дизайн-системы. Для маленьких — двух уровней достаточно. Для крупных систем с десятками компонентов component tokens дают гибкость: можно настроить специфическое поведение одного компонента без затрагивания общих semantic токенов. Признак, что пора добавлять component tokens — частые ситуации «нужно изменить только в одном компоненте, не везде».

Как обеспечить, что все разработчики используют токены, а не hardcoded значения?

Через линтеры. ESLint-плагины для CSS-in-JS и Stylelint-правила для CSS могут запрещать использование цветов и размеров вне зарегистрированных токенов. Без линтеров дисциплина рано или поздно проседает, особенно в больших командах.

Можно ли использовать design tokens без Figma?

Можно. Figma — популярный источник токенов, но не единственный. Команда может определять токены сразу в JSON или в Tailwind config, синхронизация с дизайном идёт через документацию. Подход работает в командах, где разработчики плотно вовлечены в дизайн-процесс.

Что делать с brand-цветами, которые используются только на лендингах?

Включить их в primitive tokens, но не в semantic. Маркетинговые лендинги используют их напрямую через primitive, продуктовые компоненты — через semantic, ссылающиеся на нейтральные primitive. Так бренд-эксперименты на лендингах не затрагивают продукт.

Заключение

Design tokens из локальной техники веб-разработки превратились в полноценную инженерную дисциплину со своими стандартами, инструментами, лучшими практиками. Без них поддерживать единый опыт между несколькими платформами и приложениями становится практически невозможно — слишком много мест для рассинхронизации, слишком высокая стоимость каждого изменения.

Зрелая дизайн-система с токенами даёт три измеримых преимущества. Скорость изменений — обновить бренд-цвет на 50 экранах занимает минуты, а не месяцы. Консистентность — пользователь получает одинаковый опыт независимо от платформы и продукта. Качество — повторное использование проверенных решений снижает ошибки в новых разработках.

Внедрение требует инвестиций: создание инфраструктуры, миграция существующего кода, обучение команд, поддержка процессов. Но в среднесрочной перспективе эти инвестиции окупаются многократно через ускорение разработки и снижение технического долга. Для команд, работающих над масштабными продуктами, дизайн-система с правильно построенными токенами — не опция, а конкурентное преимущество.