~/wiki / dizayn-sistema-i-komponenty / tokeny-tsvet-tipografika-otstupy

Токены дизайна: почему без них продукт всегда выглядит по-разному

Основной чат

Чат для вайбкодеров: новости, гайды, поиск исполнителей, маркетплейс и разбор реальных кейсов.

$ cd раздел/ $ join vibe dev
Токены дизайна: почему без них продукт всегда выглядит по-разному - обложка

В команде три разработчика делают три разных раздела продукта. У каждого в голове «основной синий цвет бренда» — но у каждого своё понимание какой именно синий. Первый пишет #1A1A2E. Второй #1B1B30. Третий берёт пипеткой из Figma но промахивается на пиксель — получается #1A1C2E.

Три разных синих. Пользователь не заметит сознательно. Но подсознательно почувствует «что-то не так» — то самое размытое ощущение которое снижает доверие к продукту.

С токеном color/brand/primary у всех троих одно значение — хранится в одном месте и никуда не расходится.


Что такое токен и почему имя важнее значения

Токен — именованная переменная. color/brand/accent: #E94560. Не просто #E94560.

Разница выглядит мелкой пока не нужен ребрендинг. Тогда color/brand/accent меняется в одном файле — и всё что его использует обновляется автоматически: Figma, CSS, iOS, Android. #E94560 разбросанный по 80 файлам — ручной обход с пропусками и багами.

Второй эффект который недооценивают: AI-агенты. Число #E94560 — просто число без контекста. Имя color/brand/accent — смысл. Claude Code видит color/brand/accent и понимает что это акцентный цвет, использует его на CTA и активных состояниях. Hex-значение AI угадывает.


Трёхуровневая архитектура

Плоская система токенов (один уровень) ломается при масштабировании: непонятно что менять при ребрендинге, непонятно как добавить тёмную тему, AI не разбирается в логике. Три уровня решают это.

Уровень 1 — Primitive (факты без смысла)

Полная визуальная палитра без указания где что используется.

json
{
  "color": {
    "blue": {
      "900": { "value": "#1A1A2E", "type": "color" },
      "800": { "value": "#252545", "type": "color" },
      "500": { "value": "#4040A0", "type": "color" }
    },
    "red": {
      "500": { "value": "#E94560", "type": "color" },
      "400": { "value": "#F06080", "type": "color" }
    },
    "neutral": {
      "50":  { "value": "#FAFAF8", "type": "color" },
      "100": { "value": "#F5F5F0", "type": "color" },
      "900": { "value": "#1A1A2E", "type": "color" }
    }
  },
  "spacing": {
    "1": { "value": "4px" },
    "2": { "value": "8px" },
    "4": { "value": "16px" },
    "6": { "value": "24px" },
    "8": { "value": "32px" }
  }
}

Primitive-токены никогда не используются в компонентах напрямую. Только как источник для следующего уровня.

Уровень 2 — Semantic (смысл без деталей)

Ссылаются на Primitive и дают им назначение. Это главный уровень с которым работают компоненты.

json
{
  "color": {
    "brand": {
      "primary": { "value": "{color.blue.900}" },
      "accent": {
        "value": "{color.red.500}",
        "comment": "CTA, активные состояния. Не использовать для фонов."
      }
    },
    "background": {
      "page":    { "value": "#FFFFFF" },
      "surface": { "value": "{color.neutral.100}" },
      "elevated": { "value": "#FFFFFF" }
    },
    "text": {
      "primary":   { "value": "{color.blue.900}" },
      "secondary": { "value": "{color.blue.800}" },
      "disabled":  { "value": "{color.neutral.400}" }
    },
    "status": {
      "error":   { "value": "{color.red.500}" },
      "success": { "value": "#2D8A4E" },
      "warning": { "value": "#D97706" }
    },
    "border": {
      "default": { "value": "#E0E0F0" },
      "focus":   { "value": "{color.brand.accent}" }
    }
  }
}

При ребрендинге меняешь только ссылки в Semantic-уровне. color/brand/accent теперь указывает на {color.green.500} — все компоненты обновляются, Primitive при этом не трогаешь.

Уровень 3 — Component (только когда нужен)

Токены для конкретных компонентов. Добавляй только при реальной потребности: multi-brand поддержка, или когда один компонент должен выглядеть по-разному в разных контекстах. На старте не нужен — не усложняй раньше времени.


Именование: стандарт DTCG

Design Token Community Group — открытый стандарт именования. В 2026 его поддерживают Figma Variables, Tokens Studio, Style Dictionary, все AI-инструменты. Паттерн: category/role/variant.

Команда должна понимать назначение токена из имени — без дополнительных пояснений.

Правильно Неправильно Почему плохо
color/action/primary blue-dark описывает внешний вид
spacing/component/gap-md big-padding субъективная оценка
font/size/heading-2 h2 HTML-тег, не дизайн-решение

Правило проверки: можно ли понять для чего этот токен не зная продукта? Если нет — имя неправильное.


Синхронизация: Figma → JSON → Код → AI

plaintext
Tokens Studio (Figma плагин)
       ↓ push при каждом изменении
design-tokens.json в git
       ↓ Style Dictionary в CI
├── tokens.css   → var(--color-brand-accent: #E94560)
├── tokens.js    → export const colorBrandAccent = '#E94560'
├── tokens.swift → UIColor для iOS
└── tokens.xml   → Android resources
       ↓
DESIGN.md        → AI-агенты знают имена и назначение

На практике: дизайнер меняет цвет в Figma Variables → Tokens Studio пушит JSON в git → CI запускает Style Dictionary → разработчик видит обновление в следующем PR. Без ручной синхронизации, без «поменял в Figma — перенеси в код».


Типичные ошибки при внедрении

Пропускают Primitive-уровень. Создают сразу Semantic с захардкоженными значениями. При ребрендинге нужно менять значение в каждом Semantic-токене. С Primitive — только ссылку.

Один токен для нескольких назначений. color/interactive/active используют для кнопок, меню и чекбоксов одновременно. Когда нужно изменить только кнопки — нельзя без затрагивания остального.

Токены в коде но не в DESIGN.md. AI не знает их имён. Продолжает писать hex. Токены работают для AI только если явно перечислены в контекстных файлах которые он читает перед началом работы.

Создают 200 токенов в первый день. Никто не использует. Начни с 20–30 самых нужных, добавляй по мере необходимости.


Как мигрировать существующий проект без боли

Не «большой переезд», а поэтапная миграция:

  1. Найди топ-5 цветов которые встречаются чаще всего (grep по hex или поиск в Figma)
  2. Создай для них Primitive и Semantic токены
  3. Переведи на них один компонент — Button
  4. Проверь что работает в Figma и в коде, синхронизация настроена
  5. Следующий компонент

Через месяц работы в таком режиме большая часть системы на токенах — без стресса и без отдельного «проекта миграции».


Промпт для аудита и создания токенов

markdown
Проанализируй проект и помоги создать систему токенов.

Шаг 1: Найди все уникальные hex-значения цветов в CSS, Tailwind, inline-стилях.
Для каждого: значение, сколько раз встречается, в каких файлах.
Отсортируй по частоте — топ-15.

Шаг 2: Для топ-15 предложи:
- Primitive-токен: color/[hue]/[shade] (например color/blue/900)
- Semantic-токен: color/[category]/[role] (например color/brand/primary)
- Комментарий: когда использовать, что запрещено

Шаг 3: Сгенерируй JSON в формате DTCG для всех токенов.
Сгенерируй CSS Custom Properties для Semantic-уровня.

Цель: готовый design-tokens.json который можно сразу подключить через Tokens Studio.

Почему «просто договориться» не работает без токенов

Самый распространённый способ управления цветами без токенов — это Figma Styles. Создаёшь стиль «Primary Blue», применяешь его к компонентам. Казалось бы — единый источник.

Проблема первая: Styles не синхронизируются с кодом автоматически. Разработчик видит «Primary Blue» в Figma и пишет #1A1A2E в коде вручную. При следующем изменении цвета в Figma — в коде остаётся старое значение.

Проблема вторая: AI не видит Styles. Когда агент генерирует компонент, он не знает что у тебя есть стиль «Primary Blue». Он видит hex-значения в кодовой базе и пытается угадать что является «основным синим».

Токены решают обе проблемы: они существуют и в Figma Variables, и в CSS Custom Properties, и в JSON-файле который читает AI. Один источник правды который доступен всем трём аудиториям одновременно.


Практические вопросы при внедрении

«Tokens Studio бесплатный?» Да, базовая версия бесплатная и покрывает большинство сценариев. Платные фичи нужны при работе с несколькими брендами или сложными workflow — для одного продукта платить не нужно.

«Нужно ли сначала мигрировать все компоненты?» Нет. Начни с одного. Создай токены для Button — переведи Button в Figma на Variables, переведи Button в коде на CSS Custom Properties. Проверь что работает. Потом Input. Потом Card. Миграция поэтапная, не «всё сразу».

«Что если разработчики против?» Покажи конкретную цену. Посчитай сколько часов разработчики тратят на ответы «какой цвет?» в месяц. Умножь на ставку. Tokens Studio бесплатен, его установка занимает час. Экономия начинается сразу.

«Как называть токены если у нас нет дизайн-системы?» Начни с простых семантических имён: color/brand/primary, color/text/default, color/background/surface. Не думай о сложной иерархии — просто дай имена тому что есть. Улучшить структуру позже проще чем мигрировать с захардкоженного.

plaintext
☐ Три уровня: Primitive → Semantic → Component (только при нужде)
☐ Primitive не используются в компонентах напрямую
☐ Semantic: category/role/variant, назначение читается из имени
☐ Комментарии в токенах: когда использовать, что запрещено
☐ Tokens Studio синхронизирует Figma Variables ↔ JSON
☐ Style Dictionary: CSS/JS/Swift/XML из одного JSON
☐ ESLint-правило: запрет hex в JSX и CSS
☐ Токены в DESIGN.md с назначением для AI
$ cd ../ ← назад к Дизайн-система и компоненты