Архитектура переменных Figma: как построить систему токенов, которая переживёт продакшен

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

Команды, которые делают всё правильно, относятся к переменным Figma как к полноценному слою дизайн-токенов: структурированному, с алиасами, областями применения и возможностью экспорта. Команды, которые делают неправильно, находятся в одном запросе на тёмную тему от полной перестройки. Вот архитектура, которая переживает продакшен.

Переменные - это не стили, это слой токенов

Стили Figma - это пресеты. Вы определяете цвет, текстовый стиль, эффект и применяете его прямо к слою. Это работает для файла с одним брендом, одним режимом и без требований к передаче в разработку. Перестаёт работать в ту секунду, когда что-то меняется.

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

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

Примитивы, семантика, компоненты. В каждой работающей системе переменных есть эти три слоя. Пропуск семантического слоя - самая частая архитектурная ошибка в файлах Figma сегодня.

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

Три слоя не опциональны в зависимости от размера проекта. Маленькой системе с пятью компонентами всё равно нужны все три слоя, иначе первый же запрос на тему разнесёт её на куски.

Слой первый: примитивы

Примитивы - это сырые значения. blue-500, gray-900, space-4, radius-md. Это палитра, шкала, фундамент. Их никогда не привязывают напрямую к слою компонента.

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

Здесь важны соглашения об именовании. Примитивы должны называться по шкале или палитре, но никогда по смыслу. blue-500 - правильно. button-blue в качестве примитива - категориальная ошибка, которая причиняет боль на масштабе.

Слой второй: семантика

Семантические токены несут смысл. surface, surface-elevated, text-primary, text-muted, border-default, border-focus. Они отвечают на вопрос «для чего этот цвет?», а не «какой это цвет?»

Семантические токены ссылаются на примитивы. Это единственная связь, которая у них есть. Алиасинг семантики на семантику создаёт неопределённость в том, где живёт значение, и делает переопределения режимов ненадёжными.

Именно на этом слое живут светлый, тёмный и брендовые режимы. Семантический токен разрешается в разные примитивы в зависимости от активного режима, так на самом деле и работает темизация. Примитив blue-500 не меняется. Семантический токен text-link меняет то, во что он разрешается, в зависимости от режима.

Слой третий: компоненты

Токены компонентов относятся к одному семейству компонентов. button-bg, button-text, button-border, card-surface, card-border, input-bg. Они ссылаются на семантические токены, никогда на примитивы.

Задача токена компонента - конкретность без жёсткой связности. button-bg разрешается в surface-action, который разрешается в blue-500. Когда бренд меняется, вы обновляете семантический слой, и кнопка обновляется вместе с ним. Токен компонента остаётся нетронутым.

Частое возражение: это кажется лишними токенами без причины. Причина в том, что button-bg и surface-action могут разойтись. В какой-то момент продуктовое решение потребует, чтобы кнопка использовала чуть другую поверхность. Токены компонентов дают точку переопределения, не трогая семантическую систему.

Режимы или коллекции: дерево решений

Режимы переключают значения внутри коллекции. Коллекции разделяют зоны ответственности. Это разные вещи, и их смешение - источник большей части архитектурной путаницы в настройке переменных Figma.

Правило такое: одна коллекция на одну зону ответственности, режимы для вариантов одной и той же зоны. Цвет - одна зона. Отступы - одна зона. Светлая и тёмная темы - не отдельные зоны. Это режимы одной цветовой зоны.

Когда использовать режим, а когда новую коллекцию:

• Другое значение той же вещи? Режим.
• Совсем другая вещь? Коллекция.
• Переключение между светлой и тёмной темой? Режим внутри цветовой коллекции.
• Переключение между компактными и комфортными отступами? Режим внутри коллекции отступов.
• Добавляете бренд? Режим внутри семантического слоя, а не новая коллекция.

Четыре правила областей применения

Область применения (scoping) переменной определяет, где её можно применить в Figma. Ошибка здесь означает, что дизайнеры могут случайно потянуться к примитивам вместо семантических токенов, и архитектурная дисциплина рушится в момент использования.

Четыре правила не обсуждаются:

1. Ограничивайте примитивы областью «никуда». Примитивы не должны применяться нигде. Это внутренние значения, а не токены для потребителей. Полностью скройте их из выпадающего списка применения.
2. Ограничивайте семантические токены их типом. Цветовой семантический токен получает область заливок и обводок. Токен отступа получает область полей gap, padding и размеров. Держите область узкой.
3. Ограничивайте токены компонентов их семейством. Токен кнопки не должен применяться к карточке. Если область слишком широкая, граница компонента теряет смысл.
4. Никогда не открывайте примитивы потребителям. Если дизайнер или разработчик применяет примитив к слою, система дала сбой на уровне областей применения. Это провал процесса, а не провал пользователя.

Цепочка алиасов, которая делает темы возможными

Рабочая тема - это цепочка алиасов: компонент ссылается на семантику, семантика ссылается на примитив, примитив хранит значение. Длина цепочки - три, всегда три.

Цепочка из двух звеньев (компонент к примитиву) пропускает слой перевода и делает режимы невозможными без ручных переопределений в каждом токене компонента. Цепочка из четырёх создаёт неопределённость, какой семантический слой несёт режим, и аудит превращается в отладку, а не в простой поиск.

button-bg → surface-action → blue-500 → #0066FF

Copy

Эта цепочка переживает тёмную тему: вы обновляете surface-action так, чтобы в тёмном режиме семантической коллекции он указывал на blue-300. Токен button-bg обновляется автоматически. Примитив blue-500 по-прежнему разрешается в #0066FF. Больше ничего менять не нужно.

Светлый, тёмный и брендовые режимы

Три режима, которые нужны большинству систем переменных: светлый, тёмный и брендовый. Несёт их только семантический слой. Никогда не слой примитивов.

Применять режимы к примитивам - категориальная ошибка. blue-500 - это всегда #0066FF. Это примитив. У него нет светлого или тёмного варианта, потому что он не несёт смысла. У семантического токена text-link есть светлый и тёмный вариант, потому что он несёт смысл, который в разных контекстах разрешается по-разному.

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

Числовые, строковые и булевы переменные

Переменные Figma - это не только цвета. Числовые переменные управляют отступами, размерами и радиусами. Строковые переменные управляют текстом внутри дизайн-файлов. Булевы переменные управляют видимостью слоёв, что напрямую соответствует пропсам компонентов.

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

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

Передача в код: схема, которая работает

Система переменных хороша ровно настолько, насколько хорош её экспорт. Рабочая схема передачи - это Tokens Studio или Figma Variables REST API, плюс конвейер трансформации, плюс скрипт импорта на стороне кода.

Tokens Studio экспортирует коллекции переменных в структурированный JSON-формат, совместимый со Style Dictionary. Style Dictionary преобразует этот JSON в любой нужный кодовой базе вывод: CSS custom properties, наборы цветов Swift, ресурсные файлы Kotlin, конфиг Tailwind. На шаге трансформации нормализуются соглашения об именовании и вычищаются специфичные для Figma имена, которые не ложатся на конвенции кода.

Конвейер должен запускаться при каждом обновлении переменных, а не вручную. GitHub Action, срабатывающий на пуш из Tokens Studio, или вебхук Figma, срабатывающий на изменения переменных, держит токены в коде синхронизированными, и никому не нужно помнить про экспорт. Эту схему на масштабе используют Stripe и Atlassian, и она достижима в любой кодовой базе, где есть шаг сборки. Для решений о формате цветовых токенов в этом выводе стоит прочитать про цвет OKLCH до того, как вы зафиксируете значения CSS custom properties.

---

Нужна система переменных Figma, которая переживёт режимы, бренды и передачу в разработку без переписывания? Brainy проектирует продакшен-архитектуры токенов в Figma: трёхслойная модель, цепочка алиасов и конвейер экспорта, который чисто ложится в вашу кодовую базу. Нанять Brainy

---

Семь частых ошибок, которые ломают системы переменных

У большинства этих ошибок один корень: панель переменных воспринимают как улучшенную панель стилей, а не как архитектурный слой. Исправление - сдвиг ментальной модели. Всё остальное следует из него.

Аудит системы переменных

Проведите этот аудит для любой системы переменных Figma, и вы поймаете архитектурный долг до того, как он уйдёт в релиз.

Структура

• Минимум три коллекции: примитивы, семантика, компоненты (или эквивалентные названия)
• У каждой коллекции одна чёткая зона ответственности
• Ни одна коллекция не смешивает типы (цвет и отступы в одной коллекции - это провал)

Цепочка алиасов

• Каждый токен компонента ссылается на семантический токен, а не на примитив
• Каждый семантический токен ссылается на примитив, а не на другой семантический токен
• Ни один токен не хранит сырое значение, кроме примитивов
• Длина цепочки алиасов ровно три для всех цветовых токенов

Режимы

• Светлая и тёмная темы - режимы в семантической коллекции, а не отдельные коллекции
• Варианты брендов - режимы в семантической коллекции, а не отдельные файлы
• В коллекции примитивов нет режимов

Области применения

• Переменные-примитивы ограничены областью «никуда» (не применяются нигде)
• Семантические переменные ограничены своим типом (цвет: заливки и обводки, отступы: поля раскладки)
• Переменные компонентов ограничены своим семейством компонентов

Передача

• Переменные экспортируются через Tokens Studio или REST API
• Конвейер трансформации существует и автоматизирован
• Токены в коде соответствуют соглашению об именовании переменных Figma с задокументированными исключениями

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

FAQ

В чём разница между переменными Figma и стилями Figma?

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

Сколько коллекций должно быть в системе переменных Figma?

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

Могут ли переменные Figma заменить Tokens Studio?

Для создания и редактирования внутри Figma - да. Нативная панель переменных делает большую часть того, чем занимался Tokens Studio до выхода API переменных. Для экспорта и трансформации Tokens Studio всё ещё полезен: у него зрелый конвейер к Style Dictionary, и он справляется с крайними случаями, которые нативный экспорт не покрывает. Сейчас эти два инструмента дополняют друг друга, а не конкурируют.

Что будет, если сделать алиас семантического токена на другой семантический токен?

Разрешение режимов становится неоднозначным. Если text-secondary ссылается на text-primary, и вы переключаетесь на тёмный режим, Figma разрешает цепочку и может не применить переопределение тёмного режима там, где вы ожидаете. Алиасинг семантики на семантику также делает аудит системы почти невозможным на масштабе. Правило жёсткое: семантические токены ссылаются только на примитивы.

Как добавить третий бренд, не перестраивая систему?

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

Нужна ли трёхслойная модель для небольших проектов?

Да, но размер каждого слоя уменьшается. В небольшом проекте может быть пятнадцать примитивов, восемь семантических токенов и по два токена компонента на компонент. Архитектура всё равно из трёх слоёв. Соблазн пропустить семантику в небольших проектах - причина, по которой так много маленьких проектов становятся архитектурным долгом в момент появления второго дизайнера или запроса на тёмную тему. О том, как архитектура токенов вписывается в более широкое решение по стеку, есть контекст в материале Framer vs Webflow vs Next.js.

Сдвиг, который на самом деле открывают переменные Figma

Настоящая система переменных в Figma - это самое близкое, к чему дизайн и разработка подошли к единому источнику истины. Не документ для передачи. Не ссылка на Zeplin. Живой, экспортируемый, структурированный слой токенов, который обе стороны читают из одних и тех же определений.

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

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

Стройте архитектуру, а не просто токены.