Когда интерфейс небольшой, цвет можно просто взять пипеткой, радиус посмотреть в макете, а отступ повторить по соседнему блоку. Чем больше становится продукт, тем хуже работает этот способ. В какой-то момент макет перестает быть системой правил и превращается в огромную коллекцию частных примеров. Именно в этот момент design tokens становятся не модным слоем документации, а практическим инструментом.
Токен - это имя решения
Самая полезная характеристика токена не в том, что он хранит значение. Значение можно сохранить где угодно. Токен дает значению смысл. Вместо условного \#0F1114 появляется surface.canvas. Вместо очередного числа для скругления - понятная роль радиуса. Благодаря этому команда обсуждает не конкретный пиксель, а назначение.
Это особенно важно, когда значение меняется. Если темный фон заменили другим оттенком, нам не нужно искать старый цвет по всему проекту. Меняется решение, а все места, которые на него ссылаются, продолжают говорить на одном языке.
Макет показывает пример, токены показывают правило
В TRUE VISUAL мы столкнулись с типичной проблемой: цельный Component HTML Catalog уже хорошо показывал элементы, но сам по себе не объяснял цветовые схемы и переключение светлой и темной темы. Встраивать всю логику в каждый пример было бы неудобно. Гораздо надежнее держать визуальные правила отдельно и позволять компонентам использовать их.
Так появляется нормальное разделение ответственности. Каталог отвечает за устройство и состояния компонента. Набор токенов - за системные значения. Тема - за то, какие значения подставляются в роли при конкретной цветовой схеме.
Почему примитивов недостаточно
Если хранить только палитру вроде gray-900, blue-500 и white, система остается слишком близко к краскам. Компоненту все равно приходится знать, какой конкретный оттенок брать. Поэтому полезен второй уровень - семантический. Например, surface.canvas, text.primary, border.subtle, action.primary.
Такой слой позволяет менять визуальный характер темы, не переписывая компоненты. В светлой и темной теме text.primary может ссылаться на совершенно разные примитивы, но смысл роли остается прежним.
Токены полезны не только людям
Для проекта, в котором участвуют AI-агенты, формализация правил дает дополнительный эффект. Агенту гораздо проще изменить конкретную роль, чем угадывать закономерность по десяткам файлов. Если задача звучит как "изменить цвет вторичной границы", наличие border.subtle радикально снижает пространство для ошибки.
То же касается генерации новых элементов. Вместо случайного набора цветов и отступов агент получает ограниченный словарь уже принятых решений. Он может создавать новое, не разрушая визуальную систему.
Не нужно превращать в токены вообще все
Токенизация тоже способна превратиться в отдельный вид бюрократии. Если каждое редкое число получает имя, словарь становится сложнее самого интерфейса. Мы считаем полезным другой принцип: токен нужен там, где значение повторяется, меняется вместе с темой, выражает системную роль или должно контролироваться централизованно.
Локальное исключение может оставаться локальным. Главное - чтобы команда осознавала, что это исключение, а не случайно забытое системное правило.
Design tokens для нас - это не экспорт цветов из Figma и не отдельный технический артефакт. Это язык, который связывает дизайн, прототип, разработку и автоматизацию. Чем сложнее становится продукт, тем ценнее оказывается сам факт, что у его решений есть устойчивые имена.