Design Tokens: как настоящие дизайн-системы сохраняют согласованность

Hex-код — это значение. Token — это решение с именем. Дизайн-системы строятся из решений, а не из значений.

В этом и есть весь смысл. Захардкодьте #0EA5E9 в четырнадцать компонентов Figma, получите запрос на тёмную тему и окажетесь перед неделей find-and-replace. Назовите его color-interactive-primary и смените одно значение, пока каждая поверхность обновляется. Никакой магии — просто именованные решения.

Что такое design token на самом деле

Design token — это именованная переменная, хранящая дизайн-решение. Она может содержать цвет, значение отступа, размер шрифта, радиус скругления, тень или продолжительность анимации. Имя — это контракт. Значение за именем может меняться, не ломая ничего, что использует token.

Классический подход без tokens начинается так: дизайнер выбирает #1D4ED8 для основных кнопок, хардкодит его в компоненте кнопки, затем копирует hex в карточку, бейдж и ссылку. Через шесть месяцев обновляется брендбук. Теперь у вас проблема с поддержкой, которая растёт с каждым выпущенным компонентом.

Tokens переворачивают это. Вы называете решение (color-action-default), присваиваете значение один раз, и всё, что ссылается на token, остаётся синхронизированным. Значение — это деталь реализации. Имя — это система.

Три уровня, которые делают tokens рабочими

Сырые tokens — это просто переменные. Настоящую пользу системе tokens приносит иерархия. Каждая достойная изучения продакшн-система использует три уровня.

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

Semantic tokens сопоставляют роли с primitives. Token color-surface-default может указывать на почти белый в светлой теме и почти чёрный в тёмной, и компонент никогда не знает, какое сырое значение получает. Он знает только роль.

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

Почему tokens лучше захардкоженных значений

Скорость изменений — очевидный аргумент, но не главный. Главный аргумент — точность.

Когда дизайнер передаёт файл, полный сырых hex-кодов, разработчик понятия не имеет, какие из них намеренные, а какие случайные. #1A1A2E — это фон, или кто-то взял пипеткой не тот слой? Tokens убирают двусмысленность. Имя semantic token — это документация, которая путешествует вместе со значением.

Tokens — это также контракт передачи между дизайн-инструментами и кодом в 2026 году. Figma variables напрямую сопоставляются с CSS custom properties. Token, определённый в файле Figma, можно экспортировать, закоммитить и использовать в коде без единого ручного шага. Разрыв между дизайном и реализацией исчезает, когда обе стороны говорят на одних и тех же именах tokens.

Для команд, занимающихся доступностью, tokens добавляют ещё один уровень безопасности. Вы аудируете semantic-палитру в одном месте и гарантируете, что color-text-default всегда обеспечивает контраст 4.5:1 с color-surface-default, в какой бы теме ни находились.

Как реальные дизайн-системы структурируют tokens

Три системы стоит знать: Shopify Polaris, IBM Carbon и GitHub Primer. Они по-разному реализуют трёхуровневую модель, и различия показательны.

Shopify Polaris хранит primitives в цветовой шкале (color-sky-100 до color-sky-900) и алиасирует их к semantic-ролям вроде --p-color-bg-fill-active. Component tokens редки, поэтому большинство компонентов потребляют semantic tokens. Конвенция — роль-потом-состояние, что естественно читается в коде: понятно, для чего bg-fill-disabled, без дополнительного контекста.

Смотреть вживую на polaris.shopify.com

IBM Carbon уходит глубоко в semantic-слои. Его цветовой набор включает явные feedback-tokens вроде support-error и support-success, tokens интерактивных состояний и layer-tokens для вложенных поверхностей (компонент на панели на странице — каждый требует разного значения поверхности). Это сложнее, но IBM выпускает корпоративный софт, где важно каждое вложенное состояние.

Смотреть вживую на carbondesignsystem.com

GitHub Primer публикует primitive-слой как "primitives", а semantic-слой как "functional tokens" на primer.style. Тематизация Primer позволяет GitHub выпускать светлую, тёмную, светлую высококонтрастную и тёмную приглушённую темы из одного набора компонентов. Каждая тема — это другое присвоение значений тем же именам tokens.

Паттерн одинаков во всех трёх: primitives как шкала, semantic tokens как имена ролей, тематизация как смена значений на semantic-уровне. Компоненты остаются нетронутыми.

---

Brainy помогает дизайнерам строить системы, которые масштабируются, а не разовые экраны. Смотрите, что мы создаём для креаторов на /creators.

---

Как называть tokens, не сойдя с ума

Именование tokens раскалывает команды. Слишком общие имена — и они ничего не несут. Слишком специфичные — и вы пишете новый token для каждого компонента.

Работающая конвенция именования состоит из четырёх частей: категория, роль, вариант и состояние. Не все четыре части нужны каждый раз, но структура предотвращает хаотичное разрастание.

Рабочие примеры в виде CSS custom properties, которые реально потребляет разработчик:

• color-surface-default — дефолтный фон страницы
• color-text-subtle — вторичный текст с пониженным контрастом
• color-interactive-primary-hover — hover-состояние основного действия
• spacing-component-md — средний внутренний отступ для компонентов
• radius-interactive — радиус скругления для кликабельных элементов

Два правила спасут от большинства споров. Никогда не кодируйте сырое значение в имя — color-blue-500 ничего не говорит о роли. Никогда не называйте по компоненту на semantic-уровне — button-primary-color в semantic-слое означает, что вы вовсе пропустили semantic-уровень.

Для типографических систем, которые масштабируются, та же конвенция применима, и font-size-body-lg всегда лучше text-18px.

Один набор tokens, светлая и тёмная тема

Тёмная тема — место, где token-системы окупаются наиболее наглядно. Если вы называли tokens по роли, тёмная тема — это смена значений, а не редизайн.

Смотреть вживую на primer.style

Механизм прост. Ваш semantic token color-surface-default указывает на primitive, который почти белый в светлой теме и почти чёрный в тёмной. Компонент, потребляющий его, не меняется. Вы переключаете темы, меняя сопоставление значений на semantic-уровне.

CSS custom properties делают это механическим:

:root { --color-surface-default: #ffffff; --color-text-primary: #111827; } [data-theme="dark"] { --color-surface-default: #0f172a; --color-text-primary: #f8fafc; }

Каждый компонент, ссылающийся на var(--color-surface-default), теперь реагирует на атрибут темы без единой дополнительной строки кода. Shopify Polaris, GitHub Primer и IBM Carbon используют этот паттерн в продакшн-масштабе.

Типичная ошибка — смешивать semantic и primitive tokens в компонентах. Когда компонент ссылается напрямую на color-blue-600 вместо color-interactive-primary, он перестаёт реагировать на тематизацию. Одна небрежная primitive-ссылка ломает всю модель. Lint-правила, помечающие прямое потребление primitives в коде компонентов, стоят времени на настройку.

Понимание того, как цветовые решения воспринимаются даёт концептуальную основу, а tokens дают структуру для реализации этого во всех темах.

Когда design tokens избыточны

Tokens добавляют уровень косвенности. Косвенность имеет свою цену. Честно оценивайте, когда эта цена оправдана.

Маленькие команды двигаются быстрее без tokens. Стартапу из трёх человек, ищущему product-market fit, не нужна трёхуровневая иерархия. Когда вы меняете визуальное направление каждые две недели, одной библиотеки стилей Figma достаточно.

Антипаттерн, которого стоит избегать, — преждевременное semantic-именование. Tokens с именами color-blue и color-gray добавляют косвенность без смысла. Либо называйте по роли через color-surface и color-text, либо оставайтесь на primitives, пока не накопится достаточно компонентов, чтобы понять, какие роли реально нужны.

Плохое именование tokens хуже, чем отсутствие tokens. Token с именем button-color-for-the-checkout-page на semantic-уровне — это ловушка поддержки. Дисциплина именования необязательной не бывает — именно она и делает tokens рабочими.

FAQ

Заменяют ли design tokens стили Figma?

Нет, но расширяют их. Figma variables, выпущенные в 2023 году, — это ближайший нативный аналог внутри Figma, и они сопоставляются с code tokens при единой конвенции именования. Figma styles обрабатывают типографику и цветовые заливки, тогда как variables охватывают всю иерархию tokens, включая состояния и component-level решения.

Работают ли tokens без дизайн-системы?

Tokens наиболее ценны внутри дизайн-системы, но даже один продукт выигрывает от semantic-именования на уровне CSS custom properties. Формальная система не нужна, чтобы перестать хардкодить hex-значения.

Какой инструмент использовать для управления tokens?

Для небольших команд Figma variables плюс JSON-экспорт достаточно. Для крупных команд Style Dictionary (open source, от Amazon) — стандартный инструмент сборки. Он берёт JSON-структуру tokens и генерирует CSS custom properties, iOS Swift константы и Android XML. Tokens Studio для Figma — популярный плагин-мост между Figma и Style Dictionary.

Насколько детализированными должны быть component tokens?

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

Работают ли tokens только для цветов, или ещё для отступов и типографики?

Tokens работают для всего, что имеет дискретное значение: цвет, отступы, типографика, радиус скругления, тень блока, продолжительность анимации, её плавность и z-index. Наиболее зрелые системы, такие как IBM Carbon и Atlassian Design System, имеют tokens для всего этого. Начните с цвета и отступов, затем добавляйте остальное по мере зрелости системы.

Перестаньте хардкодить значения

Практический путь не сложен:

• Называйте primitives как шкалу
• Сопоставляйте primitives с semantic-ролями
• Пусть каждый компонент потребляет semantic tokens, но не primitives
• Экспортируйте значения tokens из одного источника (Figma variables, JSON-файл или пакет дизайн-системы) и позвольте инструментам сборки распределять их в CSS, iOS и Android

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

Больше материалов о дизайн-системах — смотрите, что ещё публикует Brainy на /paper.