Дизайн-токены задуманы как единый источник правды для цветов, отступов и типографики. Во многих командах это файл, который кто-то обновляет руками, когда к этому вынуждает релиз.
В этом руководстве — процесс, который переносит токены из Figma в код без ручного экспорта. Он держится на трёх приёмах: называть токены по смыслу, сравнивать вместо копирования и доставлять каждое изменение pull request'ом. Мы делаем FISYCO — инструмент, который автоматизирует этот процесс, и выводы ниже взяты из опыта его создания.
Коротко
- Хоть какой-то конвейер токенов есть лишь у 40% команд дизайн-систем; остальные синхронизируют токены между дизайном, документацией и кодом вручную (zeroheight Design Systems Report 2026, 147 практиков).
- Называйте токены по смыслу (bgColor-default), а не по значению (gray-0): тогда при ребрендинге меняются значения, а не имена.
- Опознавайте токены по стабильному ID, а не по имени: тогда переименование распознаётся как переименование, а не как удаление плюс добавление.
- Доставляйте каждое изменение pull request'ом с ревью и запускайте синхронизацию публикацией библиотеки в Figma.
Почему ручной перенос токенов из Figma в код ломается
Ручной экспорт ломается, потому что требует от людей безупречно повторять длинную цепочку шагов. Дизайн-токен — это именованное дизайн-решение, например цвет или шаг отступа, и он полезен, только пока дизайн и код в нём сходятся. Типичный ручной экспорт выглядит так:
- Открыть Figma и найти коллекцию.
- Запустить плагин или скопировать значения.
- Выбрать нужный режим.
- Вставить в нужный файл и поправить форматирование.
- Открыть pull request.
Пропустите шаг — и код тихо разойдётся с дизайном. К тому же ручной экспорт прячет, что именно изменилось. Когда файл токенов пересобирается целиком, ревьюер видит сотни изменённых строк и одобряет их на доверии. Переименованный токен и сменившийся фирменный цвет в таком диффе выглядят одинаково.
Часть проблемы — доступ. Variables REST API в Figma доступен только на тарифе Enterprise, поэтому многие команды вообще не могут прочитать переменные скриптом. У плагина Figma такого ограничения нет: он читает переменные, заданные в файле, на любом тарифе и отправляет их в ваш конвейер.
Шаг 1. Называть токены по смыслу
Имена токенов — это договор между дизайном и кодом. Имя по значению описывает, что такое токен. Смысловое имя — для чего он нужен.
Хороший публичный образец — система Primer от GitHub. В ней базовые токены, которые прямо соответствуют сырым значениям, например base-color-green-5, отделены от функциональных, таких как bgColor-inset, и от токенов компонентов, таких как button-primary-bgColor-hover (имена токенов в Primer). Натан Кёртис в своей таксономии имён токенов (2020) делит имена на уровни: базовый, модификатор, объект и пространство имён. Он советует держаться одного последовательного соглашения без омонимов.
Практическое правило: держите небольшой базовый слой для палитры, а компонентам разрешайте только смысловой слой. Смысловые имена переживают ребрендинг. Имена по значению превращаются во враньё: после ребрендинга blue-500 оказывается зелёным.
Шаг 2. Сравнивать, а не копировать
Вместо того чтобы перезаписывать файл токенов, сравните две стороны и опишите разницу:
- Имена: какие токены добавлены, удалены или переименованы.
- Значения: какие токены изменились и с чего на что.
- Ссылки: не указывает ли смысловой токен теперь на другой базовый. Когда
bgColor-accentпереходит сblue-500наblue-600, это изменение ссылки, и дифф должен прямо так и сказать, а не показывать два сырых hex-значения. - Режимы: поменялись ли светлая и тёмная темы вместе. В Figma переменная хранит по одному значению на каждый режим (Figma Help Center), поэтому один режим может уехать сам по себе.
Переименование — самый опасный случай. Если дифф сопоставляет токены по имени, переименование выглядит как «один токен удалили, другой добавили», и ломается каждое место, где использовалось старое имя. Сопоставляйте токены по стабильному ID, который Figma присваивает в исходном файле библиотеки, — и переименование будет видно как переименование. Тот же pull request должен переименовать все использования в коде или оставить старое имя устаревшим алиасом на один релиз.
Судите только о тех источниках, которые действительно прочитали. Мы усвоили это на собственной ошибке: ранняя версия нашей синхронизации в одном из запусков прочитала только стили Figma и сочла удалёнными все переменные, пришедшие из плагина. Дифф должен сравнивать сопоставимое.
Шаг 3. Доставлять изменения pull request'ом
Изменение токенов должно попадать в код тем же путём, что и любое другое: через pull request, который команда смотрит на ревью. Описание важнее сгенерированного файла — именно его ревьюер и читает. Например (условный пример):
Токены: изменена 1 ссылка, изменено 1 значение, добавлен 1, переименован 1
~ bgColor-accent light: {blue-500} → {blue-600}
~ fgColor-muted dark: #8b949e → #9198a1
+ bgColor-inset
→ gray-bg переименован в bgColor-default (тот же Figma ID)Ревьюер проверяет намерение, а не каждую строку. И ещё одно правило: точка отсчёта должна сдвигаться только после слияния pull request'а. До этого изменение предложено, но не выпущено.
Никогда не позволяйте автоматической синхронизации пушить прямо в основную ветку. Pull request — то место, где команда замечает изменение, которого никто не ждал.
Шаг 4. Запускать синхронизацию из Figma
Когда конвейер дизайн-токенов стал надёжным, уберите людей из запуска. Вебхук LIBRARY_PUBLISH в Figma сообщает о созданных, изменённых и удалённых переменных, стилях и компонентах при каждой публикации библиотеки. Публикация запускает синхронизацию. Синхронизация открывает или обновляет pull request, а команда смотрит и вливает его.
Доступность вебхуков и их лимиты зависят от тарифа Figma, так что проверьте свой, прежде чем на них полагаться. Кнопка ручной синхронизации в любом случае пригодится как запасной путь.
Где место формата DTCG
В октябре 2025 года W3C Design Tokens Community Group опубликовала первую стабильную версию своей спецификации — 2025.10 (W3C DTCG). Это спецификация Community Group, а не стандарт W3C. Figma объявила о встроенном импорте и экспорте переменных в этом формате (Figma Blog).
Общий формат файлов упрощает экспорт переменных Figma. Но он не решает, что изменилось, кто это проверит и когда это выйдет. Это по-прежнему работа конвейера.
Частые вопросы
Нужен ли тариф Figma Enterprise, чтобы автоматизировать токены?
Не обязательно. Variables REST API требует Enterprise, но плагин Figma читает переменные, заданные в файле, на любом тарифе и отправляет их в ваш конвейер.
Какой формат использовать на стороне кода?
Тот, который потребляет ваш стек: CSS custom properties, SCSS, TypeScript или JSON. Используйте DTCG как формат обмена и генерируйте из него всё остальное.
Что делать с токенами, которые есть только в коде?
Их тоже нужно показывать в сравнении. Значение, которое есть только в коде, либо отсутствует в дизайне, либо должно быть удалено, и кто-то должен осознанно решить, что из двух. Отслеживать такие пробелы во времени — часть того, как измерять здоровье дизайн-системы.
Как FISYCO переносит токены из Figma в код
Мы строим FISYCO вокруг этого процесса. Он читает переменные и стили из вашего файла Figma и сравнивает их с последней влитой версией по стабильному ID. Затем доставляет разницу в ваш репозиторий pull request'ом — в JSON, CSS, SCSS или TypeScript, по кнопке или после каждой публикации в Figma. Переменные приходят через плагин FISYCO для Figma, поэтому всё это работает на любом тарифе. Полная картина — в статье о том, что FISYCO умеет сегодня.