Привет, Хабр. Я Илья Сластен, продуктовый дизайнер интерактивной карты ПГК Диджитал. Ранее в своих статьях я рассказывал о ключевых аспектах работы с локальными переменными в 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: нужные переменные всегда под рукой, ничего лишнего;
формировать единый визуальный язык, понятный и предсказуемый.
Но главное — это устойчивость.В такой системе ничего не держится на «интуиции» конкретного дизайнера. Всё построено по логике, а значит, что масштабироваться, адаптироваться и передавать дизайн-решения становится в разы проще.
Это и есть зрелость дизайн-системы — когда она не мешает, а помогает расти намного быстрее.
