Компоненты и варианты в Figma: как собрать небольшую библиотеку интерфейса

Если в макете одна и та же кнопка встречается десять раз, ручное редактирование быстро превращается в источник ошибок. У одной кнопки окажется другой радиус, у второй — иной отступ, у третьей — случайно измененный цвет. Компоненты в Figma нужны именно для таких повторяющихся элементов: вы задаете основу один раз, а дальше используете ее в разных местах как управляемые копии.

Чтобы небольшая библиотека действительно экономила время, мало просто нарисовать кнопку и скопировать ее по экрану. Нужна понятная связка из главного компонента, экземпляров и вариантов. Тогда состояние hover, размер small или отключенный вид disabled переключаются в правой панели, а не пересобираются вручную каждый раз.

Зачем выносить повторяющиеся элементы в компоненты

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

У компонента есть еще одно практическое преимущество: он заставляет заранее определить, что именно в элементе должно меняться, а что нет. Например, текст внутри кнопки меняется часто, а радиус и базовые отступы — редко. Такой подход дисциплинирует структуру макета и помогает не превращать каждую кнопку в уникальный рисунок.

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

Компонент, экземпляр и набор вариантов: в чем разница

Компонент — это исходный элемент, который вы редактируете как шаблон. Экземпляр — его копия на макете: она наследует изменения исходника, но может иметь допустимые локальные настройки, например другой текст. Если поменять главный компонент, экземпляры обновятся автоматически.

Частая ошибка — пытаться сделать библиотеку состояний через обычные копии или через редактирование экземпляров. Это не дает управляемого переключения состояний. Для этого нужен набор вариантов — несколько компонентов, объединенных в один component set. Внутри такого набора вы задаете свойства, например State и Size, а у каждого варианта будет своя уникальная комбинация значений.

В справке Figma variants описаны как способ сгруппировать похожие компоненты в один контейнер. Для кнопки это удобно: вместо отдельных объектов вроде Button Default, Button Hover и Button Disabled вы получаете один элемент Button с переключаемыми параметрами. Экземпляр такого набора вставляется в макет один раз, а нужное состояние выбирается справа.

Именование через слэш тоже полезно, но важно не путать его с механикой вариантов. Названия со структурой вроде Button/Primary помогают организовать компоненты в списке Assets. А чтобы именно создать варианты, нужно либо добавить вариант к главному компоненту, либо объединить несколько компонентов командой Combine as variants.

Как собрать кнопку с состояниями и размерами без путаницы

Начните с базовой кнопки: прямоугольник или frame, текст внутри и, если нужно, Auto Layout для внутренних отступов. После этого превратите элемент в компонент. Дальше не копируйте экземпляры в надежде получить библиотеку состояний. Правильный шаг — создать у главного компонента новый вариант через Add variant или заранее подготовить несколько компонентов и объединить их в набор вариантов.

Когда набор создан, переименуйте служебные свойства во что-то понятное. Вместо Property 2 и Property 3 задайте, например, State и Size. Значения могут быть такими: для State — default, hover, disabled; для Size — small, medium, large. Важно, чтобы каждый вариант имел уникальную комбинацию значений. Если два варианта окажутся с одинаковым набором свойств, Figma покажет конфликт.

Необязательно создавать все возможные сочетания заранее. Если в проекте пока не нужен large + disabled, можно его не рисовать. Это удобнее, чем раздувать библиотеку ради формальной полноты. Но те комбинации, которые вы уже добавили, должны быть названы последовательно и храниться в одном наборе.

После этого вставьте на макет не главный компонент, а его экземпляр из панели Assets. В правой панели вы сможете переключать State и Size без ручной перерисовки. Это и есть тот результат, ради которого собирают мини-библиотеку: один источник правды и быстрые управляемые изменения.

Учебный пример: мини-библиотека кнопки для одного экрана

Учебный пример. Представим экран регистрации, где есть три кнопки: основная «Создать аккаунт», второстепенная «Войти» и недоступная «Отправить код», пока пользователь не заполнил поля. Чтобы не рисовать три независимые кнопки, соберем один набор Button с двумя свойствами: State и Size.

Сначала делаем вариант medium + default: высота 44, горизонтальные отступы 16, синий фон, белый текст. Затем дублируем именно вариант внутри набора и меняем значение State на hover: фон становится темнее, остальные параметры сохраняются. Еще один вариант — disabled: светло-серый фон, более тусклый текст. После этого создаем размеры small и large, меняя высоту и отступы, а не рисуя кнопку заново с нуля.

На экран вставляем три экземпляра набора Button. У первого оставляем State=default, Size=large, у второго — State=default, Size=medium, у третьего — State=disabled, Size=medium. Текст в экземплярах меняем под задачу экрана. Если позже вы решите, что у всех состояний нужен радиус 12 вместо 8, измените одинаковые слои в нужных вариантах внутри набора; после обновления самих вариантов их экземпляры на экране подтянутся автоматически. Для ускорения такой правки в component set можно использовать multi-edit, когда совпадающие объекты редактируются согласованно.

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

Правила небольшой библиотеки и как проверить курс по теме

Даже маленькая библиотека быстро теряет пользу, если в ней нет простых правил. Для одной кнопки достаточно договориться о двух вещах: какие свойства считаются управляемыми и как они называются. Например, если вы используете State и Size, не стоит в соседнем наборе писать Status и Dimension без причины. Единая логика именования важнее декоративной красоты панели Layers.

Еще одно полезное правило — держать вариант в левом верхнем углу как основной. По справке Figma именно верхний левый вариант становится вариантом по умолчанию в Assets. Поэтому логично ставить туда самое частое состояние, обычно default среднего размера. Тогда при вставке на макет вы сразу получаете наиболее ожидаемую версию элемента.

Если вы выбираете обучение по теме компонентов, смотрите не только на формулировку «есть Figma в программе». Для читателя полезнее задать себе три вопроса: показывают ли в программе работу с компонентами, вариантами и UI-kit; есть ли самостоятельная практика, где вы сами собираете набор кнопок, а не просто повторяете действия за видео; кто и как проверяет результат, особенно структуру компонента, свойства и именование. По сохраненной программе курса «Онлайн-курс Figma с нуля» есть отдельный модуль про Auto Layout, стили, сборку UI-kit и использование компонентов и их вариантов для быстрого редактирования дизайна. Это полезный признак именно для темы небольшой библиотеки интерфейса.

Если после статьи вы сможете собрать один набор Button с понятными свойствами и вставлять его на экран как управляемый экземпляр, цель достигнута. Дальше этот же принцип легко перенести на поля ввода, теги, переключатели и карточки — но начинать лучше с одного элемента, доведенного до порядка.