Адаптивный дизайн в Figma: мобильные и десктопные макеты

То, что фрейм Figma одинаково хорошо выглядит и на десктопе 1440px, и на телефоне 375px, ещё не значит, что адаптивное поведение между этими значениями уже определено — Figma показывает вам два фиксированных снимка, а браузеру нужны явные правила, чтобы заполнить весь диапазон реальных размеров экрана посетителя. Перейти от «эти два фрейма выглядят правильно» к раскладке, которая действительно держится, можно только если читать Auto Layout и constraints как сигнал об адаптивном поведении, а не просто как визуальные настройки, и понимать, где заканчивается работа Figma и начинается CSS. Дальше — практическая ментальная модель, что проверить перед тем, как приступать к вёрстке, и где во всём этом находится место автоматическому адаптивному выводу MarkupGen.

Фрейм Figma — это визуальная спецификация, а не готовый адаптивный CSS

Figma рендерит фрейм при одной фиксированной ширине. Ничто в файле не «проигрывается» при разных размерах экрана так, как это делает браузер: то, что в Figma выглядит как адаптивный дизайн, на самом деле — набор правил (направление, gap и режимы размера в Auto Layout; constraints слоя), которые описывают намерение, а не рабочую симуляцию события ресайза. Именно в CSS это намерение становится реальностью: flex-direction, gap, проценты, clamp() и правила @media — вот что на самом деле реагирует на ширину viewport. Относитесь к файлу Figma как к источнику истины для намерения, а не как к чему-то, что уже содержит готовый адаптивный код.

Мобильный и десктопный фреймы описывают один дизайн, а не два

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

Auto Layout и constraints: что на самом деле переносится в адаптивное поведение

Направление, gap, отступы и режимы размера (hug, fill, fixed) в Auto Layout близко соответствуют Flexbox — полное поэлементное сопоставление смотрите в статье Figma Auto Layout в CSS. Именно для адаптивного поведения важнее всего режим размера: элемент со значением «fill» говорит о том, что он должен расти или сжиматься вместе со своим контейнером (flex: 1, width: 100%), а «fixed» — о том, что этого делать не должен.

Constraints отвечают на другой вопрос — как элемент ведёт себя при изменении размера своего родителя, что важнее всего для всего, что находится вне Auto Layout:

• Left / Right — закреплён у одного края, близко к фиксированному отступу, который остаётся на месте при изменении размера родителя.
• Left and Right — растягивается вместе с родителем, близко к width: 100% с фиксированными боковыми отступами.
• Center — остаётся отцентрированным при изменении размера родителя, похоже на margin: 0 auto или отцентрированное размещение во flex/grid.
• Scale — масштабируется пропорционально родителю; у CSS нет единого прямого эквивалента, обычно это приближают относительными единицами.
• Top / Bottom (и их сочетания) — та же логика, применённая к вертикальной оси.

Во многих реальных файлах используются оба механизма сразу: Auto Layout — для того, как располагаются дочерние элементы контейнера, constraints — для того, как сам этот контейнер ведёт себя внутри чего-то большего, чем он сам.

Брейкпоинты: от фреймов Figma к реальному CSS

В Figma нет встроенной функции брейкпоинтов — нет настройки, которая говорит «переключить раскладку ниже 768px». На практике файл даёт вам либо отдельные фреймы под каждый размер экрана, либо один фрейм с Auto Layout, который гибко меняет размер вообще без структурных изменений. От того, с каким из этих двух случаев вы имеете дело, зависит, нужны ли CSS явные правила @media, а основная часть работы — подобрать значения брейкпоинтов там, где раскладка действительно меняет форму, а не привязываться к произвольным ширинам устройств. Статья Брейкпоинты Figma в CSS-медиазапросы подробно разбирает оба паттерна и то, где обычно ошибается ручной перенос.

Как решения в Figma превращаются в адаптивный CSS

Когда сигналы со стороны Figma понятны, со стороны CSS остаётся довольно небольшой набор инструментов, применяемых последовательно:

• Flexbox — для большинства фреймов с Auto Layout: строк, колонок, панелей навигации, списков карточек.
• Grid — для по-настоящему двумерных раскладок, вроде дашборда или галереи, которые Auto Layout имитирует вложенными строками и колонками.
• Медиазапросы — там, где меняется сама форма раскладки: боковая панель превращается в нижнюю навигацию, сетка превращается в одну колонку.
• Гибкое масштабирование (проценты, minmax(), clamp()) — для всего, что находится между ширинами, которые дизайнер действительно указал, вместо добавления брейкпоинтов для заполнения промежутков.
• max-width — чтобы текст и контент не растягивались неудобно широко на больших экранах, даже если сам фрейм Figma этого не показывает.
• Перенос и укладка в стопку (flex-wrap, превращение строки в колонку) — для контента, который должен перетекать, а не сжиматься.
• Изменения видимости — для всего, что действительно предназначено только для мобильных или только для десктопа; делать это стоит аккуратно, поскольку скрытие элемента через display: none также убирает его из дерева доступности. Если скрытый контент должен оставаться доступным другим способом, например через мобильное меню, смотрите статью Figma в доступный HTML.

Частые ошибки при переносе Figma в адаптивные раскладки

• Восприятие мобильной версии как уменьшенного десктопа вместо самостоятельной раскладки со своей иерархией и приоритетами.
• Жёсткое указание пиксельных размеров везде, где фрейм Figma показывает конкретное число, вместо того чтобы использовать режимы fill/fixed и constraints, чтобы решить, что действительно должно оставаться фиксированным.
• Игнорирование переноса текста — заголовок или подпись кнопки, умещающиеся в одну строку на исходном языке, могут занять две-три строки в более длинном переводе, а раскладка, рассчитанная на однострочный текст, из-за этого ломается.
• Опора на абсолютное позиционирование, чтобы совпасть с дизайном пиксель в пиксель, — это выглядит правильно ровно при той ширине фрейма и ломается на всех промежуточных ширинах.
• Проверка только тех ширин, при которых нарисованы фреймы Figma — скажем, 375px и 1440px — с пропуском всего, что между ними, а именно там и происходит большая часть реальных поломок.

Чек-лист для передачи разработчику

Прежде чем реализовывать адаптивное поведение по файлу Figma, стоит проверить несколько вещей непосредственно в дизайне, а не полагаться на предположения:

• Какие фреймы существуют и задуманы ли мобильная и десктопная версии как один и тот же контент, перестроенный по-другому, или как принципиально разный опыт.
• Настройки Auto Layout на каждом фрейме — направление, gap, отступы и режим размера у элементов, которым нужно менять размер.
• Constraints у всего, что находится вне Auto Layout, особенно у элементов, закреплённых у края или отцентрированных.
• Отступы и типографику при каждой ширине фрейма — масштабируются ли они или остаются фиксированными.
• Варианты компонентов — есть ли у компонента отдельный мобильный вариант, или ожидается, что адаптироваться будет один и тот же компонент.
• Что на самом деле отличается между мобильным и десктопным фреймами и является ли каждое отличие осознанным решением, а не просто расхождением между файлами, отредактированными в разное время.

Как MarkupGen автоматизирует базовую адаптивность

Каждый экспорт отталкивается от собственных настроек Auto Layout и ограничений изменения размера конкретного фрейма, а не от общего списка брейкпоинтов: направление, gap и отступы переносятся точно, а размер fill/hug превращается в гибкий CSS, — благодаря этому результат масштабируется под разные размеры экрана без ручных медиазапросов для большинства раскладок.

Для дизайнов, где мобильной версии действительно нужна другая структура — вертикальная навигация вместо горизонтальной, переставленный герой-блок, скрытый сайдбар, — встроенный редактор может сгенерировать отдельную, целенаправленно спроектированную мобильную или десктопную раскладку для текущей страницы на основе существующего HTML/CSS, со своим собственным медиазапросом; вы просматриваете её перед применением, а дальше размер экрана посетителя сам решает, какая из них рендерится. В любом случае вывод отдаёт предпочтение семантическому HTML вместо вложенных <div>, доступен в Vanilla CSS, Tailwind, Bootstrap, Bulma, Materialize или Pico, с автоматической AI-оценкой качества при каждом экспорте. Ничто из этого не заменяет чек-лист выше — это отправная точка, сгенерированная на основе реальных сигналов дизайна, которую стоит проверять так же, как и любую другую реализацию адаптивности перед публикацией.

Если хотите увидеть, как ваш собственный файл Figma адаптируется под оба размера экрана, попробуйте конвертер Figma в HTML — или конвертируйте сразу в React, если это ваш стек — бесплатно, без банковской карты.

Часто задаваемые вопросы

Как дизайн в Figma должен обрабатывать мобильные и десктопные раскладки? Относитесь к ним как к одному дизайну, выраженному при двух ширинах — с одним и тем же контентом, заголовками и компонентами, — а не как к двум не связанным между собой файлам. Auto Layout и constraints описывают, как эта общая структура должна адаптироваться; настоящие структурные различия, такие как свёрнутая навигация или переставленный герой-блок, затем реализуются с помощью CSS-медиазапросов.

Делают ли Auto Layout и constraints в Figma дизайн адаптивным автоматически? Нет. Они описывают намерение — как элемент должен менять размер или вести себя при изменении своего контейнера, — но это намерение всё равно нужно перевести в Flexbox, Grid, гибкое масштабирование или медиазапросы на реальном CSS. Ни Figma, ни инструмент конвертации не принимают все адаптивные решения самостоятельно.

Как выбрать CSS-брейкпоинты по дизайну в Figma? В Figma нет встроенной функции брейкпоинтов, поэтому подбирайте их значения там, где раскладка действительно меняет форму, а не по произвольным ширинам устройств. Если дизайн использует отдельные фреймы под каждый размер экрана, раскладка каждого фрейма обычно превращается в один блок @media; если он опирается на гибкое изменение размера в Auto Layout, брейкпоинт часто вообще не нужен.

В чём разница между Auto Layout и constraints в Figma? Auto Layout управляет тем, как располагаются дочерние элементы фрейма — направление, gap, отступы, размер, — это ближе всего к display: flex. Constraints управляют тем, как элемент ведёт себя при изменении размера своего родителя: закреплён ли он у края, отцентрирован или масштабируется, — это важнее всего для элементов вне Auto Layout или для того, как сам фрейм с Auto Layout ведёт себя внутри чего-то большего.

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

Что нужно проверить перед адаптивной реализацией дизайна из Figma? Какие фреймы существуют, настройки Auto Layout и constraints у каждого из них, как (и меняются ли вообще) отступы и типографика между фреймами, есть ли у компонентов отдельные мобильные варианты и какие различия между мобильным и десктопным фреймами осознанные, а какие — случайное расхождение.