01Проблема не в количестве компонентов

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

Начни с повторяемости, которую реально видишь в проекте. Одна карточка, одно поле, одна кнопка и одна строка списка важнее двадцати абстрактных элементов «на будущее». Система должна объяснять поведение, а не увеличивать объём файла.

02Разложи карточку на смысловые группы

У карточки тарифа есть название и статус, описание, цена, список условий и действие. Сначала объединяй элементы по смыслу, затем задавай расположение. Отступ внутри названия и бейджа отличается от расстояния между названием и ценой, потому что первая пара воспринимается как одна группа.

Перед Auto Layout запиши правило: ширина карточки определяется сеткой, высота растёт с контентом, действие находится после содержимого. Если проекту нужна одинаковая высота всех карточек, объясни, как распределяется свободное пространство. Не компенсируй неизвестное поведение случайными пустыми фреймами.

03Auto Layout начинается с ответа: кто определяет размер?

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

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

04Варианты описывают различия, а не каждую комбинацию подряд

У кнопки могут различаться назначение, размер и состояние. Назови свойства понятно: например, тип действия и состояние. Не добавляй вариант «зелёная_новая_2», который никто не сможет выбрать осмысленно. Варианты должны отвечать на реальные вопросы пользователя компонента.

Отдельно подумай, что меняется содержимым, а что поведением. Текст не нужно превращать в отдельный визуальный вариант для каждой подписи. Если различие возникает только один раз и компонент приходится усложнять ради него, возможно, это другой компонент. Проверка простая: может ли коллега выбрать нужный элемент без объяснения автора?

05Не забудь ошибки и загрузку

Покажи базовое состояние, фокус, недоступность и ошибку там, где они применимы. Для поля нужны подпись, подсказка и текст ошибки; один красный контур не объясняет, как исправить ввод. Для карточки с внешним изображением нужна замена на случай отсутствия картинки. Для списка — пустой результат и загрузка.

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

06Проверь длинный текст и разные изображения

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

Найденную проблему записывай как правило: «Название переносится, бейдж остаётся рядом с ним или уходит на следующую строку». Это полезнее, чем «Сдвинуть на 8 px». Система становится устойчивой, когда ограничения известны и повторяемы.

07Передача: покажи правила и исключения

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

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

08Порядок нужен тебе, а не идеальному скриншоту файла

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

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

Источники и дальнейшее чтение