Как построить систему дизайн‑токенов для масштабируемого интерфейса.

Когда продукт перерастает стадию «одного макета в Figma» и превращается в экосистему из нескольких веб-приложений, мобильных клиентов и десятков страниц, команда неизбежно сталкивается с проблемой «магических чисел». Один и тот же оттенок серого в CSS может называться #F5F5F5, #F6F6F6 или light-grey. В итоге любое изменение основного цвета бренда превращается в многодневный квест по поиску и замене значений во всех репозиториях.

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

Что такое дизайн-токены на самом деле?

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

Обычная переменная говорит нам, какого цвета элемент. Токен говорит нам, для чего этот цвет предназначен.

Вместо того чтобы использовать переменную $blue-500 для кнопки, мы используем $button-primary-bg. Таким образом, если завтра бренд решит, что основные кнопки должны стать фиолетовыми, мы меняем значение одного токена, и интерфейс обновляется везде, при этом семантика (значение «основная кнопка») остается неизменной.

Архитектура уровней: Трехуровневая модель

Чтобы система была масштабируемой, нельзя сваливать все токены в одну кучу. Лучшая практика — разделение на три уровня абстракции. Это позволяет гибко управлять темой (например, переключать темный режим) и адаптировать интерфейс под разные платформы.

1. Примитивы (Global/Base Tokens)

Это «сырые» значения. Они описывают палитру всех доступных цветов, шрифтов и отступов, но не привязаны к конкретным элементам интерфейса.

• • Пример: color-blue-500: #2196F3, spacing-4: 16px, font-size-sm: 12px.

• • Правило: Примитивы никогда не используются напрямую в коде компонентов. Они служат лишь фундаментом для следующих уровней.

2. Семантические токены (Alias/Semantic Tokens)

Это самый важный слой. Здесь мы присваиваем примитивам смыслы. Семантика отвечает на вопрос «Зачем это используется?».

• • Пример: color-text-primary $\rightarrow$ color-grey-900, color-bg-interactive-hover $\rightarrow$ color-blue-600.

• • Зачем это нужно: Именно здесь происходит магия темной темы. В светлой теме color-bg-default ссылается на белый примитив, а в темной — на темно-серый. Компонент при этом продолжает использовать один и тот же семантический токен, не зная о смене темы.

3. Компонентные токены (Component-specific Tokens)

Это узкоспециализированные токены для конкретных элементов. Они нужны, когда стандартных семантических значений недостаточно или когда нужно изменить один элемент, не затрагивая остальные.

• • Пример: button-primary-border-radius $\rightarrow$ radius-md.

• • Зачем это нужно: Если вам нужно изменить скругление только у кнопок, не меняя скругление всех карточек в системе, компонентный токен — ваш единственный выход.

Пошаговый план внедрения системы

Переход на токены — это не только техническая задача, но и изменение культуры взаимодействия между дизайнерами и разработчиками.

1. Аудит визуального шума. Соберите все используемые цвета, отступы и шрифты из текущего проекта. Вы удивитесь, обнаружив 12 оттенков белого и 5 вариантов «основного» синего.
2. Создание базовой палитры. Определите основные цвета и их вариации (shades). Используйте математический подход или готовые системы (например, Tailwind palette), чтобы шаги между оттенками были гармоничными.
3. Разработка семантического слоя. Определите основные роли:

• • Backgrounds (фоны);

• • Foregrounds/Text (текст и иконки);

• • Borders (границы);

• • Interactive/Action (состояния кнопок, ссылок).

1. Формализация именования. Договоритесь о нейминге. Хороший токен читается как предложение: [категория]-[элемент]-[состояние]-[свойство]. Например: color-button-primary-hover-bg.
2. Автоматизация экспорта. Ручной перенос значений из Figma в CSS/JSON — это путь к ошибкам. Используйте инструменты автоматизации (Style Dictionary или плагины вроде Tokens Studio).

Техническая реализация и доставка (Delivery)

Главная проблема — как сделать так, чтобы дизайнер изменил цвет в Figma, и он автоматически обновился в коде.

Оптимальный пайплайн выглядит так:

1. Figma (Tokens Studio/Variables) $\rightarrow$ JSON-файл.
2. GitHub/GitLab $\rightarrow$ JSON попадает в репозиторий через Pull Request.
3. Style Dictionary $\rightarrow$ Инструмент обрабатывает JSON и генерирует платформо-зависимые файлы:

• • .css или .scss для веба;

• • .xml или .json для Android;

• • .swift для iOS.

1. CI/CD $\rightarrow$ Автоматическая сборка и публикация пакета (например, через NPM), который затем импортируется в проекты.

Подводные камни и как их избежать

В процессе построения системы вы наверняка столкнетесь с этими проблемами:

• • Избыточность. Не создавайте токены для всего подряд. Если у вас всего один вид кнопок, компонентные токены вам не нужны — хватит семантических.

• • «Ловушка именования». Не называйте токены color-light-blue. Как только цвет станет чуть темнее, название станет ложью. Используйте color-accent-main.

• • Сопротивление команды. Разработчикам может показаться, что var(--color-text-primary) писать дольше, чем #333. Объясните им, что это инвестиция в скорость будущих рефакторингов.

Резюме

Система дизайн-токенов — это не про «красивые названия переменных», а про создание единого языка общения между дизайном и разработкой. Правильная иерархия (Примитивы $\rightarrow$ Семантика $\rightarrow$ Компоненты) позволяет интерфейсу масштабироваться без боли, легко поддерживать консистентность и внедрять новые визуальные стандарты за считанные минуты, а не недели.

Помните, что идеальная система — это та, которая эволюционирует. Начните с малого, зафиксируйте базу и постепенно расширяйте структуру по мере роста продукта.