Токенизация интерфейса: зачем нужны design tokens и как они упрощают разработку

Дата публикации: 23.08.2026

Токенизация интерфейса: что это такое

Когда интерфейс создаётся с нуля, его параметры легко начать задавать прямо в компонентах: здесь 24px, там 32px, здесь один оттенок серого, там немного другой, для одной кнопки радиус 12px, для другой 16px.

Пока элементов немного, это не проблема. Но по мере развития проекта такие значения начинают дублироваться и расходиться. Изменение визуальной системы превращается в поиск множества отдельных значений по макетам и CSS.

Токенизация решает эту проблему на уровне архитектуры интерфейса.

Design token — это именованное значение, которое описывает определённый параметр дизайн-системы. Вместо того чтобы использовать конкретное значение напрямую, интерфейс обращается к его имени.

Например:

--color-text: #f5f5f5;
--color-surface: #171717;
--radius-md: 12px;
--space-lg: 24px;

Теперь компоненту не нужно знать, что основной цвет текста равен #f5f5f5, а стандартный средний радиус — 12px. Он использует соответствующие токены:

.card {
  color: var(--color-text);
  background: var(--color-surface);
  border-radius: var(--radius-md);
  padding: var(--space-lg);
}

Это важное различие: токен описывает роль значения в системе, а не просто хранит число или цвет.

Например, --gray-100 говорит о конкретном оттенке серого. --color-text говорит о том, для чего этот цвет используется. Если дизайн изменится, значение --color-text можно заменить, не меняя компоненты, которые его используют.

Чтобы увидеть принцип на практике, можно взять небольшой интерфейс и изменить несколько токенов — все связанные элементы изменятся одновременно.

Какие параметры интерфейса можно токенизировать

Токенами можно описать практически все повторяющиеся параметры визуальной системы. На практике чаще всего токенизируют цвет, типографику, spacing, радиусы, границы, тени и параметры анимации.

Например, цветовая система может выглядеть так:

--color-background: #111111;
--color-surface: #1a1a1a;
--color-text: #f5f5f5;
--color-text-muted: #999999;
--color-accent: #d8ff4f;

Для отступов:

--space-xs: 8px;
--space-sm: 16px;
--space-md: 24px;
--space-lg: 32px;
--space-xl: 48px;
--space-2xl: 64px;
--space-3xl: 96px;

Для радиусов:

--radius-sm: 8px;
--radius-md: 12px;
--radius-lg: 16px;
--radius-xl: 24px;

Отдельные токены можно создавать и для типографики, например размера шрифта, межстрочного интервала и насыщенности:

--text-body-size: 18px;
--text-body-line-height: 1.6;
--text-heading-weight: 600;

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

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

От значений к смыслу: семантические токены

Есть два распространённых способа называть токены. Первый — по самому значению:

--gray-100: #f5f5f5;
--gray-800: #222222;
--radius-12: 12px;

Второй — по назначению:

--color-text: #f5f5f5;
--color-surface: #222222;
--radius-card: 12px;

Второй подход называется семантической токенизацией. Он связывает значение не с его физическими характеристиками, а с ролью в интерфейсе.

Это особенно важно при изменении дизайна. Допустим, основной текст сегодня почти белый, а после редизайна становится немного менее контрастным. При использовании --color-text компонентам не нужно знать, какое именно значение используется. Меняется только сам токен.

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

--color-text: #f5f5f5;
--color-border: #343434;
--color-surface: #1b1b1b;

Так система становится независимой от конкретной палитры. Это позволяет менять визуальные характеристики интерфейса, сохраняя его структуру.

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

Токены и CSS-переменные — не одно и то же

На практике design tokens часто реализуют через CSS custom properties, поэтому эти понятия легко смешать. Но это разные уровни.

CSS-переменная — механизм самого CSS:

--color-text: #f5f5f5;

Design token — элемент системы дизайна, у которого есть имя, значение и смысл. Он может существовать в Figma, JSON-файле, дизайн-системе или другом источнике, а затем преобразовываться в CSS-переменные для конкретного проекта.

Например, один токен:

color.text.primary

может использоваться в нескольких средах:

Design token
      ↓
   Figma
      ↓
    JSON
      ↓
     CSS
      ↓
--color-text-primary

Поэтому токенизация полезна не только как способ сократить CSS. Она создаёт единый слой между дизайн-системой и реализацией интерфейса.

Но для небольшого сайта совершенно не обязательно строить сложную инфраструктуру с отдельными JSON-файлами, генерацией токенов и синхронизацией Figma с кодом. Если проект разрабатывается одним человеком, обычных CSS custom properties часто достаточно. В этом случае сами CSS-переменные фактически становятся практической реализацией design tokens.

Можно посмотреть на это непосредственно в коде: слева одно и то же значение используется напрямую, справа — через семантический токен.

Где токенизация действительно полезна

Токены особенно полезны там, где интерфейс содержит много повторяющихся решений. Чем больше страниц и компонентов, тем больше пользы от единого набора параметров.

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

На проекте среднего размера преимущества становятся заметнее. Один и тот же токен может использоваться в десятках компонентов. Если меняется основной цвет интерфейса, размер базового отступа или степень скругления, достаточно изменить значение токена.

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

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

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

Когда токенизация становится избыточной

У токенизации есть обратная сторона: слишком подробная система может усложнить разработку вместо того, чтобы её упростить.

Если для каждого значения создавать отдельный токен, CSS быстро превращается в слой абстракций, через который приходится проходить, чтобы понять реальный дизайн:

--space-card-content-top: 27px;
--radius-feature-item: 11px;
--color-heading-secondary-hover: #d4d4d4;

Такие токены редко дают дополнительную ценность. Они просто переименовывают конкретные значения.

Для небольшого сайта обычно достаточно ограниченного набора системных токенов: несколько цветов, несколько значений spacing, несколько радиусов, параметры типографики и, при необходимости, размеры контейнеров или переходов.

Хороший критерий простой: если значение является частью повторяющегося визуального правила и его потенциально понадобится изменить системно — токен имеет смысл. Если это уникальное решение конкретного элемента — обычное CSS-значение часто будет понятнее.

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

Как организовать токены в реальном проекте

В реальном проекте токены лучше организовать по уровням, а не превращать их в один длинный список переменных.

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

:root {
  --gray-100: #f5f5f5;
  --gray-900: #171717;

  --space-1: 8px;
  --space-2: 16px;
  --space-3: 24px;
  --space-4: 32px;

  --radius-sm: 8px;
  --radius-md: 16px;
}

Второй уровень - семантический. Он связывает конкретное значение с его назначением:

:root {
  --color-text: var(--gray-100);
  --color-surface: var(--gray-900);
  --space-card: var(--space-3);
  --radius-card: var(--radius-md);
}

И уже компоненты используют преимущественно семантические токены:

.card {
  color: var(--color-text);
  background: var(--color-surface);
  padding: var(--space-card);
  border-radius: var(--radius-card);
}

Такой подход позволяет изменить визуальную систему сверху вниз. Например, если карточки должны стать менее скруглёнными, достаточно изменить --radius-card, а не искать все места, где использовался border-radius: 16px.

При этом отдельный токен для каждого свойства компонента создавать необязательно. Если значение действительно относится только к одной конкретной детали и не является частью общей системы, обычное CSS-значение часто будет проще.

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

Что меняется при редизайне

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

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

При наличии токенов часть работы сводится к изменению самой системы:

:root {
  --color-accent: #7c5cff;
  --color-surface: #181818;
  --radius-card: 16px;
}

После изменения:

:root {
  --color-accent: #e05a3f;
  --color-surface: #f4f1eb;
  --radius-card: 8px;
}

Компоненты при этом не переписываются. Карточки, кнопки, формы и другие элементы продолжают ссылаться на те же семантические токены, но получают новые значения.

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

Интерактивный пример ниже показывает именно такую ситуацию: одна и та же структура интерфейса получает разные визуальные системы только за счёт изменения токенов.

А нужен ли отдельный токен для каждого компонента?

Не обязательно.

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

--button-padding-x
--button-padding-y
--button-radius
--button-gap
--card-padding
--card-radius
--card-gap
--input-padding
--input-radius

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

Гораздо практичнее сначала использовать общие токены:

--space-sm
--space-md
--space-lg

--radius-sm
--radius-md
--radius-lg

--color-text
--color-surface
--color-accent

А компонентный токен создавать только тогда, когда компонент действительно требует собственного правила.

Например, если все карточки сайта используют один радиус, достаточно --radius-card. Если же у карточек каталога и карточек статей разные визуальные правила, можно разделить их:

--radius-card-product
--radius-card-article

То же относится к отступам, цветам и другим параметрам.

Хорошая система токенов поэтому не стремится к максимальному количеству переменных. Она стремится к минимальному набору правил, который позволяет последовательно управлять интерфейсом.

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

Токены в CSS: практический вариант для сайта

Для обычного сайта не требуется отдельный инструмент или сложная дизайн-система. Токены можно организовать непосредственно в CSS.

Например, в начале файла со стилями можно определить основные значения:

:root {
  /* Цвета */
  --color-text: #f5f5f5;
  --color-text-muted: #999;
  --color-surface: #1c1c1c;
  --color-surface-raised: #242424;
  --color-accent: #7c5cff;

  /* Отступы */
  --space-sm: 8px;
  --space-md: 16px;
  --space-lg: 24px;
  --space-xl: 48px;
  --space-section: 96px;

  /* Радиусы */
  --radius-sm: 8px;
  --radius-md: 16px;
  --radius-lg: 24px;
}

Дальше компоненты используют эти значения:

.card {
  padding: var(--space-lg);
  border-radius: var(--radius-md);
  background: var(--color-surface);
  color: var(--color-text);
}

.card__description {
  margin-top: var(--space-md);
  color: var(--color-text-muted);
}

.button {
  padding: var(--space-sm) var(--space-md);
  border-radius: var(--radius-sm);
  background: var(--color-accent);
}

На этом уровне уже появляется главное преимущество токенизации: визуальные решения отделены от конкретных компонентов.

Если позже нужно уменьшить общий ритм интерфейса, изменить характер скруглений или заменить акцентный цвет, достаточно изменить несколько значений в одном месте.

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

Когда дизайн-токены действительно окупаются

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

Но сам по себе размер проекта не является достаточным критерием. Важнее количество повторяющихся решений и вероятность их изменения.

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

Особенно заметна польза в трёх ситуациях.

Во-первых, когда один визуальный параметр повторяется во многих компонентах. Изменение одного токена позволяет сохранить согласованность интерфейса.

Во-вторых, когда сайт имеет несколько визуальных тем или состояний. Например, светлая и тёмная темы могут использовать одинаковые семантические токены, но получать разные значения.

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

При этом токены не заменяют архитектуру CSS. Они лишь делают повторяющиеся решения явными и управляемыми. Плохой CSS с сотней переменных не становится хорошим только потому, что эти значения названы токенами.

Где заканчивается токенизация и начинается дизайн-система

Дизайн-токены часто воспринимают как синоним дизайн-системы, но это разные уровни.

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

Например, токен:

--color-accent: #7c5cff;

говорит только о значении акцентного цвета.

Компонентная часть системы может определить, что акцентный цвет используется для основной кнопки, ссылок и активного состояния элементов. А сама кнопка уже описывает структуру, размеры, состояния hover, focus, disabled и другие детали.

Поэтому наличие нескольких CSS-переменных ещё не означает, что на сайте появилась полноценная дизайн-система.

Для одного проекта может быть достаточно небольшого набора токенов. Для другого поверх них действительно имеет смысл построить библиотеку компонентов и правила их использования.

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

Что в итоге даёт токенизация интерфейса

Токенизация не делает сайт автоматически лучше и не является обязательным этапом разработки. Это способ вынести повторяющиеся визуальные решения в отдельный управляемый слой.

Вместо того чтобы десятки раз задавать одни и те же значения непосредственно в компонентах, можно определить их один раз и использовать по всему интерфейсу:

:root {
  --color-text: #f5f5f5;
  --color-surface: #1c1c1c;
  --color-accent: #7c5cff;

  --space-sm: 8px;
  --space-md: 16px;
  --space-lg: 24px;

  --radius-sm: 8px;
  --radius-md: 16px;
}

Это даёт несколько практических преимуществ.

Изменения становятся централизованными. Если нужно изменить основной радиус или акцентный цвет, не приходится искать все соответствующие значения в стилях.

Интерфейс проще сохранять согласованным. Компоненты используют одну систему значений, а не случайный набор близких друг к другу размеров и цветов.

Редизайн становится предсказуемее. При хорошо организованных семантических токенах можно изменить визуальное направление сайта, не переписывая каждый компонент отдельно.

Но у токенизации есть и обратная сторона: она добавляет уровень абстракции. Поэтому токен стоит создавать не потому, что «так правильно», а потому что конкретное значение является частью повторяющегося правила и его имеет смысл контролировать централизованно.

Для небольшого сайта может хватить нескольких десятков переменных. Для большой системы их может быть значительно больше. Универсального количества токенов не существует.

Главный критерий простой: если изменение значения должно распространяться на несколько частей интерфейса, токен может быть полезен. Если значение существует только ради одной уникальной детали, дополнительная абстракция чаще всего не нужна.

Заключение

Токенизация интерфейса - это не про максимальное количество CSS-переменных. Это про управление повторяющимися решениями.

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

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

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