Привет, Хабр. Я Илья Сластен, продуктовый дизайнер интерактивной карты ПГК Диджитал. Ранее в своих статьях я рассказывал о ключевых аспектах работы с локальными переменными в Figma и подход Atomic Design и о минимализме в дизайне. Сегодня поговорим о нейминге.
Когда создаешь дизайн-систему, кажется, что главное — создать компоненты, настроить сетки, собрать библиотеку в Figma. Но на деле одна из самых сложных частей — это разобраться с токенами: как их называть, как их организовать, и как всё это выстроить так, чтобы было удобно и дизайнерам, и разработчикам. Без этого система быстро превращается в кашу.
В этой статье я покажу, как на практике организовать токены и Figma-библиотеки так, чтобы масштабирование не превращалось в хаос. Мы разберём уровни абстракции токенов, способы нейминга, таксономию и подход к построению библиотек на 4-х уровнях:
Primitives — базовые значения: цвет, типографика, тени
Style Guide — визуальные токены с семантикой
Base Components — библиотека универсальных компонентов
Product — продуктовые кастомизации
Почему правильный нейминг — это не косметика, а архитектура
Токены — это не просто какие-то переменные. Это способ договориться между дизайном и разработкой. Вместо того чтобы писать «тут чёрный #1A1A1A», дизайнер говорит: «используй text.primary.default — это основной цвет текста, и он сам подстроится под светлую или тёмную тему». Удобно и понятно для всех.
Когда с неймингом у токенов бардак — начинается настоящая путаница. Смотришь на макет и не понимаешь: какой токен взять для текста кнопки, а какой — для фона карточки. Всё вроде бы должно быть просто, но из-за непонятных названий приходится гадать или спрашивать у коллег. В итоге один элемент выглядит ярче, другой — тусклее, хотя не должен.
Переиспользовать такие стили сложно — каждый новый компонент приходится собирать почти с нуля. А если нужно сделать тёмную тему — начинается боль. У каждого дизайнера свои «любимые» цвета и отступы, и в итоге вместо единой системы получается разнобой: из файла в файл всё разное.
Всего этого легко избежать, если привести токены в порядок: придумать им понятные и логичные названия, задать контекст — и тогда сразу становится понятно, где и что применять. Но как это сделать?
Первый шаг — это создание обширной цветовой палитры и типографической системы, чтобы в дальнейшем токенизировать примитивы в style guide для разных направлений.
Например, мы создаем style guide для внутренних продуктов компании, для маркетинга, для внешних продуктов. Все эти гайды используют общие примитивы, описанные в файле, но в каждом случае применяются разные настройки: для маркетинговых материалов, таких как лендинги, нам может понадобиться большая типографика и яркие акценты цветов, а для внутренних веб-приложений — небольшая типографика и набор нейтральных цветов.
1. Primitives — фундамент переменных
Primitives — это базовая библиотека, которая включает в себя все исходные значения, необходимые для построения визуальной системы. Это первый, самый низкий уровень, где хранятся основные примитивы: цвета, шрифты, радиусы, тени, отступы, line-height и другие. Эти примитивы не привязаны к конкретным UI элементам, а представляют собой значения, которые будут токенизироваться в отдельном файле. Описываются примитивы с помощью функций Variables и Styles.
Примеры примитивов:
colors/blue/500 = #1D4ED8
colors/grey/100 = #F3F4F6
font/heading/lg = Inter 24pt/32pt Bold
radius/sm = 4px
shadow/lg = 0px 8px 16px rgba(0,0,0,0.1)Особенности:
Публикуются для создания более высокоуровневых токенов, которые затем применяются в разных частях интерфейса;
Не привязываются к UI-элементам с помощью функции scope. Они остаются абстрактными значениями;
Примитивы не используются напрямую в макетах.
Пример структуры библиотеки в Variables:
Primitives
├── colors
│ ├── blue/100, 200, 300...
│ └── neutrals/100, 200, ...
├── typography
│ ├── font-family
│ ├── font-size
│ └── line-height
├── radius
├── padding
└── shadows
2. Style Guide
Следующий уровень в структуре дизайн-системы — семантические токены. На этом этапе с помощью Figma Variables мы начинаем формировать коллекции токенов. Каждая коллекция, например Typography, может включать в себя группы и подгруппы. Например, группа font-size может содержать подгруппу headings, в которую входят токены H1, H2, H3 и т. д.
Один из ключевых аспектов этого уровня — использование Variables modes. Для типографики, например, это могут быть режимы Desktop и Mobile. Такие режимы позволяют адаптировать значения токенов (например, размеры шрифта) под разные размеры фреймов, обеспечивая автоматическую адаптивность интерфейса без ручной правки.
Важно понимать, что семантические токены не содержат собственных значений. Вместо этого они привязываются с помощью функции "Create alias" — ссылки на примитивы из библиотеки Primitives, созданной на предыдущем этапе.
Например, вместо того чтобы назначать цвет #1A1A1A для токена цвета текста, мы указываем, что text.primary.default — это цвет, который ссылается на цветовой примитив, например, colors/neutrals/900 из библиотеки Primitives. Такая структура обеспечивает централизованный контроль над параметрами, упрощает поддержку и масштабирование системы.
Пример семантических токенов:
text/primary/default = colors/neutrals/900
Основной цвет текста, используемый в стандартном режиме отображения.text/placeholder/subtle = colors/neutrals/500
Цвет для текста в плейсхолдерах или подсказках, используемый в элементах с пониженной контрастностью.surface/warning/subtle = colors/yellow/50
Цвет фона для предупреждающих или информационных элементов, таких как сообщения о статусе.border/input/focused = colors/blue/500
Цвет рамки для активного поля ввода, используемый при получении фокуса.radius/input = radius/sm
Радиус скругления для полей ввода, что придает элементам плавные углы.font/label/small = font/label-sm
Типографика для малых подписей и меток, используемых в элементах интерфейса.
Назначение токенов:
Для повышения удобства работы с токенами, используется функция Scope. Это позволяет назначать токены только на те UI элементы, к которым этот токен применим. Например, работая с карточкой, дизайнеру не нужно просматривать токены, которые относятся к полям ввода. Это позволяет ускорить процесс разработки и создания макетов, а также уменьшает количество ошибок, связанных с неправильным применением визуальных параметров.
3. Base Components — универсальные UI-элементы
После того, как мы создали и опубликовали библиотеки Primitives и Style guide, мы приступаем создавать базовые компоненты, которые можно применять от файла к файлу. Важное уточнение: все компоненты строятся строго на основе семантических токенов из Style Guide. Кастомные же компоненты, которые не требуют сквозной публикации, создаются локально на следующем этапе.
Основные цели:
Обеспечить визуальную и функциональную консистентность во всех продуктах и платформах.
Создать унифицированный набор UI-элементов, который можно использовать повторно без необходимости переизобретать решения.
Подход к сборке компонентов:
Все визуальные параметры (цвета, размеры, шрифты, скругления, отступы и пр.) задаются исключительно через семантические токены из Style Guide.
Компоненты должны поддерживать все ключевые состояния: default, hover, active, focused, disabled и т. д.
За счёт использования токенов компоненты автоматически адаптируются под темы (например, светлую и тёмную), без необходимости их дублирования или редизайна под каждую тему.
Пример использования токенов в компоненте Button:
К компоненту Button могут применяться следующие семантические токены:
text.button.primary — цвет текста в основной кнопке
surface.button.primary — фон кнопки
border.button.primary — обводка кнопки
spacing.inline.sm — внутренние отступы
Такой подход делает компонент масштабируемым, легко поддерживаемым и пригодным для адаптации под разные сценарии использования.
4. Product
И, наконец, последний уровень — продуктовый дизайн-файл. Здесь создаётся интерфейс конкретного продукта и локальные компоненты, разработанные под его задачи. Такой файл не включается в основную библиотеку токенов и компонентов и не публикуется без необходимости, чтобы не засорять другие продуктовые файлы.
Например, если в Кредитном калькуляторе нужен особый степпер:
— он создаётся на основе BaseComponents.Stepper из библиотеки Base Components,
— дополняется нужной логикой и остаётся локальным,
— не влияет на другие продукты, где такой степпер не используется,
— при этом использует токены из библиотеки Style Guide.
Типичные сценарии использования:
Создание интерфейсных блоков, специфичных для конкретного пользовательского сценария или страницы (например, калькуляторы, сложные формы, баннеры с логикой).
Расширение базовых компонентов за счёт добавления бизнес-логики или учёта уникальных требований, которые нецелесообразно выносить в общую систему.
Поддержка внутренних гайдлайнов, актуальных только для одного продуктового направления (например, банковского, логистического или партнёрского кабинета).
Итого:
Когда дизайн-система начинает масштабироваться, хаос без чёткой архитектуры — лишь вопрос времени. Начинаются дубли, непонятные названия, противоречия между файлами, ручные правки и бесконечные обсуждения «почему здесь так, а там иначе». Вместо инструмента роста система превращается в источник фрустрации.
Грамотно выстроенная архитектура токенов — это не просто порядок ради порядка. Это стратегический фундамент, который позволяет:
экономить десятки часов на рутине — как дизайнерам, так и разработчикам;
минимизировать визуальные и технические баги;
быстрее проводить редизайны и запускать новые продукты;
легко ориентироваться в Figma: нужные переменные всегда под рукой, ничего лишнего;
формировать единый визуальный язык, понятный и предсказуемый.
Но главное — это устойчивость.В такой системе ничего не держится на «интуиции» конкретного дизайнера. Всё построено по логике, а значит, что масштабироваться, адаптироваться и передавать дизайн-решения становится в разы проще.
Это и есть зрелость дизайн-системы — когда она не мешает, а помогает расти намного быстрее.
