figma-adaptive-standards/adaptive-layout-requirements.full.md

Требования к адаптивному дизайну в Figma (Полная версия)

Документ описывает стандарт подготовки адаптивных макетов в Figma так, чтобы они:

• корректно ресайзились в пределах заданных диапазонов ширин;
• были предсказуемы для разработки (верстки);
• минимизировали количество «ручных» правок и дублирования;
• содержали достаточные пояснения по поведению UI.

Кому адресовано

• Дизайнерам интерфейсов
• Team Lead / DesignOps
• Разработчикам (для валидации качества и передачи в работу)

Термины (коротко)

• Брейкпоинт — якорная ширина и набор правил компоновки, по которым интерфейс меняет структуру.
• Диапазон — интервал ширин, где один макет обязан работать корректно при ресайзе.
• Auto Layout — основной механизм адаптивности в Figma для контейнеров и компонентов.
• Hug / Fill / Fixed — режимы ресайза (по контенту / заполнять контейнер / фиксированно).
• Constraints — привязки объектов внутри Frame (Left/Right/Top/Bottom/Center/Scale).
• «Обоснованно» (в контексте этого стандарта) — по каждому «выбору» (например: Hug/Fill/Fixed, wrap/truncate для текста, Fill/Fit, Stretch/Center) должно быть понятно: что именно выбрано, зачем и как это ведёт себя на min/max диапазона и при длинном контенте. Если выбор может трактоваться по-разному — добавьте аннотацию/комментарий на странице Responsive / Breakpoints.

---

1. Структура файла Figma

1.1. Цель структуры

Структура страниц нужна для:

• быстрого поиска актуальных экранов и компонентов;
• отделения финального UI от пояснений по адаптивности и интерактивности;
• прозрачной передачи в разработку.

1.2. Рекомендуемая структура страниц

• Cover / Overview — контекст: цель продукта, аудитория, платформы, контакты, ссылки, правила
• Design / UI — финальные экраны (по брейкпоинтам или по флоу)
• Components — библиотека компонентов и их состояния/варианты
• Styles / Tokens — стили: цвет, типографика, эффекты, сетки (если принято)
• Responsive / Breakpoints — правила поведения, схемы перестроения, примеры ресайза
• Prototype — интерактивные сценарии и пользовательские флоу
• Archive / Old — устаревшие версии (только для истории)

Примечание: Responsive / Breakpoints и Prototype не дублируют финальные экраны один-в-один. Их задача — объяснить поведение, которое не очевидно из статичных макетов.

1.3. Правила нейминга (минимальный стандарт)

• Страницы: Design / UI, Components и т.д. — одинаково во всех проектах.
• Фреймы экранов: Feature / Screen — Breakpoint (например: Catalog / List — Desktop)
• Компоненты: ComponentName + группа (Button / Primary, Input / TextField), семантика важнее внешнего вида.

1.4. Что считается «готовым набором» в файле

В файле должны быть:

• фреймы всех якорных брейкпоинтов;
• компоненты и их состояния (через Variants);
• стили (цвета/типографика) с семантическими именами;
• пояснения по адаптивности и «порогам» изменений.

---

2. Брейкпоинты и адаптивность

2.1. Якорные брейкпоинты (база)

Версия	Базовая ширина	Диапазон
Mobile	375 px	320 – 768 px
Tablet	768 px	768 – 1024 px
Laptop	1024 px	1024 – 1440 px
Desktop	1440 px	1440 – 1920 px

Требования:

• Каждый брейкпоинт — отдельный Frame (Screen Frame).
• Диапазоны рассматриваются как интервалы ресайза: макет должен работать от min до max.
• Все брейкпоинты должны быть логически и визуально связаны: типографика, сетка, шаги отступов и компоненты должны «эволюционировать», а не пересобираться хаотично.

Примечание про границы: пересечение на значении 768/1024/1440 трактуется как «порог» — допустимы оба варианта, но в проекте должно быть принято единое правило (например: Mobile < 768, Tablet ≥ 768).

2.2. Когда допустимо менять список брейкпоинтов

Базовый набор можно корректировать только при объективной необходимости:

• меняется навигационный паттерн (например, горизонтальное меню → бургер);
• меняется сетка (количество колонок/маржины/контейнер);
• меняется иерархия контента (скрытие/появление блока, перестановка основных зон);
• появляются «скачки» из-за контента, которые нельзя закрыть корректным ресайзом.

Недопустимая причина:

• «так удобнее рисовать» или «не получилось настроить авто-лейаут». В этом случае исправляется настройка, а не множатся фреймы.

2.3. Принцип «один фрейм — один диапазон»

Один фрейм описывает поведение интерфейса в диапазоне, а не конкретное устройство.

Дополнительный фрейм внутри диапазона создаётся только если:

• на определённой ширине меняется структура (например, 2 колонки → 3 колонки);
• меняется тип навигации;
• меняется композиция ключевых зон (например, фильтры из сайдбара уходят в drawer).

2.4. Обязательное требование: корректный ресайз

Макет считается адаптивным только если он корректно ресайзится вручную во всём диапазоне.

Проверка (обязательная):

• вручную измените ширину фрейма до минимума диапазона;
• вручную измените ширину фрейма до максимума диапазона;
• проверьте промежуточные значения (минимум 3–5 точек внутри диапазона).

Оценивается:

• поведение сетки и контейнеров;
• перенос и переполнение текста;
• колонки, карточки и списки;
• навигация и хедер/футер;
• отсутствие коллизий: наездов, обрезаний, неожиданных перекрытий;
• сохранение визуальной иерархии.

Макет некорректен, если «работает» только на базовой ширине, а при ресайзе ломается.

2.5. Реализация адаптивности в Figma (обязательные правила)

2.5.1. Auto Layout

Обязателен для:

• всех контейнеров списков и лент;
• карточек, таблиц, форм;
• хедера/футера/сайдбара;
• любых повторяющихся групп (где есть паддинги и расстояния).

Минимальные требования к Auto Layout:

• паддинги задаются через Auto Layout (а не «ручными» прямоугольниками);
• расстояния между элементами задаются через Spacing;
• направление (Horizontal/Vertical) и Wrap выбираются обоснованно;
• в ключевых местах задаются min/max (если без этого появляются «переломы» компоновки).

2.5.2. Resizing: Hug / Fill / Fixed

Правила выбора:

• Контейнеры (строки, колонки, секции) чаще всего: Fill container по ширине.
• Элементы по контенту (лейблы, чипсы, иконки): Hug contents.
• Фиксированные размеры — только для:
  • иконок (например, 16/20/24);
  • интерактивных областей, где фикс диктуется UX (например, высота кнопки);
  • медиа с заданным форм-фактором (но с контролем кропа).

Типичная ошибка: «всё Fixed». Это убивает адаптивность.

2.5.3. Constraints

Constraints применяются там, где Auto Layout не покрывает сценарий (например, декоративные элементы, фоновые иллюстрации, абсолютные позиционирования).

Минимальные правила:

• элемент, который должен «прилипать» к краю контейнера, получает соответствующие привязки (Left/Right/Top/Bottom);
• элементы, которые должны масштабироваться пропорционально, используют Scale только если это оправдано (иначе деформируется типографика и иконки);
• избегайте смешения: Auto Layout внутри контейнера + хаотичные constraints у детей.

2.6. Примеры адаптивного поведения (как описывать)

В странице Responsive / Breakpoints для каждой сложной зоны должны быть описаны правила в формате:

• Что фиксировано (например, высота хедера 64px)
• Что тянется (контейнер контента по ширине)
• Что переносится/перестраивается (карточки wrap, 1→2→3 колонки)
• Что скрывается/появляется (например, вторичный CTA скрывается на mobile)

Пример описания (текстом):

• «Сетка карточек: на Mobile — 1 колонка, на Tablet — 2 колонки, на Laptop/ Desktop — 3 колонки. Карточка имеет min-width 280px, при нехватке места переносится на новую строку (wrap).»

---

3. Компоненты

3.1. Что обязано быть компонентом

Компонентами должны быть оформлены:

• любые повторяющиеся UI-элементы (кнопки, поля, карточки, бейджи, таблицы, модалки);
• сложные блоки, встречающиеся минимум 2 раза;
• элементы с состояниями/интерактивностью.

Запрещено:

• копировать элементы «вручную» вместо компонентов;
• создавать отдельные компоненты под каждый брейкпоинт, если поведение можно решить ресайзом.

3.2. Variants вместо копий

Состояния и вариации должны быть в Variants.

Минимальный набор состояний (если применимо):

• Default, Hover, Pressed/Active, Disabled, Focus.

Дополнительные состояния по необходимости:

• Loading, Error, Success, Empty.

3.3. Требования к адаптивности компонентов

Компонент считается адаптивным, если:

• корректно меняет ширину при Fill (когда вставлен в растягиваемый контейнер);
• корректно меняет высоту при изменении контента (например, многострочный текст);
• не ломает паддинги и расстояния при ресайзе;
• корректно работает внутри разных контейнеров (list/grid, modal, sidebar).

Обязательная проверка:

• вставьте компонент в контейнер разной ширины и измените ширину родителя;
• проверьте состояния и длину текста.

3.4. Типовые требования по компонентам (примерно, без привязки к бренду)

• Button: фиксированная высота (например, 40/44/48 по дизайн-системе), ширина Hug или Fill по контексту, текст не должен вылезать (правила: перенос/обрезка задаются обоснованно).
• Input: высота фиксирована, поле Fill, лейбл и хелпер-текст — Hug с переносом.
• Card: контейнер Fill, текстовые блоки — Hug по высоте, изображение — обоснованный Fill/Fit с safe-area.

---

4. Сетка / Layout Grid

4.1. Зачем нужна сетка

Сетка задаёт предсказуемую структуру для:

• выравнивания и ритма;
• повторяемости решений;
• соответствия верстке.

4.2. Базовая рекомендация по колонкам

Device	Колонки
Mobile	4
Tablet	8
Desktop	12

Примечания:

• Laptop обычно использует 12 колонок (как Desktop), но может отличаться маржинами.
• Внутренний контейнер (max-width) допускается, если продукт предполагает «центрированный контент».

4.3. Настройки (что должно быть задано)

Для каждого фрейма должны быть явно определены:

• margin (внешние поля);
• gutter (межколоночные расстояния);
• поведение сетки (Stretch/Center) — в зависимости от выбранной модели.

Требование:

• сетка в Figma должна соответствовать принятой сетке в верстке (или быть согласована до начала дизайна).

4.4. Пример логики перестроения с сеткой

• На Mobile: контент в 4 колонки, карточки занимают 4/4.
• На Tablet: 8 колонок, карточки 4/8 (2 колонки на ряд).
• На Desktop: 12 колонок, карточки 4/12 (3 колонки на ряд).

---

5. Типографика

5.1. Text Styles + Variables (обязательное правило)

Все текстовые слои в макете обязаны использовать Text Styles.

Text Styles должны быть семантическими (а не «по экрану») и опираться на типографические токены в Variables.

Минимальный набор (пример семантики):

• H1, H2, H3
• Body / Regular, Body / Medium
• Caption
• Button

Требования:

• одинаковая семантика должна выглядеть согласованно во всех экранах;
• локальные «ручные» правки размеров/интервалов поверх стиля недопустимы (кроме редких исключений, зафиксированных правилом);
• разрешены только бесплатные шрифты; предпочтительно использовать Google Fonts;
• значения типографики (минимум font-size и line-height, при необходимости letter-spacing) — источник правды в Variables;
• адаптация типографики между брейкпоинтами делается через Modes в Variables, а не через дублирование текстовых стилей «под каждый брейкпоинт».

5.2. Адаптация типографики между брейкпоинтами через Modes

Если типографика меняется между брейкпоинтами, это изменение фиксируется через Modes в коллекции Variables.

Обязательная структура:

• есть коллекция Variables для типографики (например: Typography);
• в коллекции заведены Modes под брейкпоинты (например: Mobile, Tablet, Laptop, Desktop — в точности как принято в проекте);
• для каждого семантического стиля (H1/H2/Body/...) определены переменные минимум для:
  • font-size;
  • line-height;
  • опционально: letter-spacing (редко и только обоснованно).

Обязательное правило применения:

• Text Styles используют эти переменные как значения типографики;
• у каждого фрейма экрана выставлен корректный Mode (Mobile/Tablet/Laptop/Desktop), чтобы типографика внутри фрейма соответствовала брейкпоинту;
• любые отличия от токенов (если они вообще допускаются) должны быть подписаны: что изменено, зачем и как это ведёт себя на min/max диапазона и при длинном контенте.

5.3. Многострочный текст: переносы и ограничения

Для ключевых текстовых блоков обязаны быть определены правила:

• переносится ли текст (wrap) или обрезается (truncate);
• сколько максимум строк допустимо в конкретном контексте (карточка/ячейка/таблица/заголовок/кнопка);
• что происходит при переполнении (например, …, перенос на следующую строку, увеличение высоты блока — что именно ожидается в UI).

Минимальная проверка контента:

• короткий текст;
• нормальный (ожидаемый);
• длинный;
• «экстремальный» (очень длинный) — для выявления поломок;
• одна очень длинная строка без пробелов (проверка на разъезд/переполнение в узких контейнерах).

---

6. Цвета и стили

6.1. Цвета — только через Color Styles

Все цвета должны быть оформлены как Color Styles.

Требование по именованию:

• семантика важнее оттенка.

Пример семантических групп:

• Primary / Secondary
• Text / Background / Border
• Success / Error / Warning

6.2. Дополнительные стили

Если в проекте используются:

• тени,
• блюр,
• обводки,
• радиусы,

то они должны быть единообразны и по возможности вынесены в стили/токены (в рамках принятых процессов команды).

---

7. Контент и состояния UI

7.1. Контентные сценарии

Для каждого экрана/секции, где возможны вариации, должны быть проверены:

• короткий/длинный текст;
• пустые значения;
• максимальные значения (например, большие числа);
• локализация (если продукт многоязычный) — хотя бы проверка длины.

7.2. Состояния UI (обязательный список)

В зависимости от компонента/экрана должны быть представлены состояния:

• Default
• Hover
• Active/Pressed
• Disabled
• Focus
• Loading
• Empty
• Error

Требование:

• состояния должны быть реализованы либо в Variants компонентов, либо как отдельные фреймы/слои с явной маркировкой.

7.3. Ошибки и валидация

Где есть ввод и формы, необходимо:

• указать правила отображения ошибок (текст, цвет, иконка, границы);
• учесть переполнение текста ошибки;
• показать состояние Error и Focus одновременно, если применимо.

---

8. Изображения и медиа

8.1. Обоснованный выбор Fill / Fit

• Fill (cover) используется, когда допустима обрезка.
• Fit (contain) используется, когда обрезка недопустима.

8.2. Safe area для обрезки

Если используется Fill, у изображений должна быть предусмотрена безопасная зона (safe area):

• важные объекты (лицо, логотип, текст на фото) не должны попадать под обрезку при изменении пропорций.

8.3. Разные соотношения сторон

Требование:

• если контент может приходить с разными ratio, дизайн обязан описать поведение:
  • фиксируем ли высоту блока;
  • разрешаем ли менять высоту по контенту;
  • используем ли placeholder/фон.

---

9. Навигация

9.1. Паттерны по брейкпоинтам (базово)

• Desktop → горизонтальное меню
• Tablet → сокращённое меню (или гибрид)
• Mobile → бургер / bottom bar

9.2. Требования к адаптивности навигации

• при уменьшении ширины не должно происходить «переполнения» пунктов меню;
• должны быть определены правила:
  • что уходит в «ещё»/overflow;
  • когда включается бургер;
  • как ведут себя вторичные действия.

9.3. Сложные случаи

Если навигация включает:

• табы,
• фильтры,
• хлебные крошки,

то должно быть описано поведение на узких ширинах (скролл, перенос, сокращение, скрытие).

---

10. Accessibility (A11y)

10.1. Контраст

Требование:

• контраст текста и интерактивных элементов должен быть не ниже WCAG AA (если продуктом не задан иной стандарт).

10.2. Размер клика (hit area)

Требование:

• минимальная интерактивная зона: 44×44 px.

10.3. Focus states и порядок

Обязательно:

• состояние Focus для интерактивных элементов;
• логичный tab order (особенно в формах и диалогах).

---

11. Прототипирование

11.1. Что обязательно прототипировать

• основные пользовательские флоу (критические пути);
• ключевые состояния (ошибка/пусто/загрузка) — если важны для сценария;
• диалоги, drawer, dropdown — если это влияет на понимание поведения.

11.2. Переходы между брейкпоинтами

Если в продукте предполагается использование интерфейса в разных ширинах (веб), необходимо:

• зафиксировать, как ведёт себя интерфейс при переходе через пороги (например, при ресайзе окна).

11.3. Проверка поведения при ресайзе

В прототипе или на странице Responsive / Breakpoints необходимо продемонстрировать:

• как перестраиваются блоки;
• что скрывается/появляется;
• где меняется навигационный паттерн.

---

12. QA и проверка адаптивности

12.1. Обязательный сценарий проверки

1. Ресайз фрейма вручную до min диапазона.
2. Ресайз до max диапазона.
3. Проверка промежуточных значений.
4. Проверка отдельных компонентов (в изоляции).
5. Проверка экстремальных контентных значений.

12.2. Типовые ошибки (что искать)

• текст выходит за границы;
• кнопки/поля «схлопываются» ниже допустимого;
• пропадает сеточный ритм;
• карточки ломают высоту соседей непредсказуемо;
• элементы перекрывают друг друга при ресайзе;
• компоненты не тянутся, потому что внутри Fixed вместо Fill/Hug.

---

13. Передача разработчику

13.1. Dev Mode

Требование:

• Dev Mode включён и доступен;
• структуры слоёв достаточно для инспекта (без лишнего мусора и без превращения текста в вектор).

13.2. Комментарии и пояснения

Должны быть комментарии/аннотации по:

• брейкпоинтам и порогам изменений;
• правилам скрытия/появления блоков;
• нестандартным случаям (например, «на 1024 фильтры переезжают в drawer»).

13.3. Экспорт ассетов

Если требуется экспорт:

• указать форматы и размеры;
• убедиться, что иконки/иллюстрации подготовлены корректно (без лишних слоёв, с понятными именами).

---

14. Запрещено

• фиксированные ширины без причины (если элемент обязан тянуться);
• дубли компонентов под каждый экран вместо нормального ресайза;
• текст как вектор;
• «ручные» отступы вместо Auto Layout;
• отсутствие Auto Layout там, где есть паддинги/списки/повторяемые структуры.

---

15. Минимальный стандарт качества (acceptance criteria)

Макет считается адаптивным и готовым к разработке, если:

1. Корректно ресайзится во всём диапазоне каждого брейкпоинта.
2. Использует Auto Layout + корректные Resizing (Hug/Fill/Fixed) и Constraints.
3. Имеет якорные брейкпоинты, а дополнительные фреймы появляются только при структурных изменениях.
4. Компоненты оформлены как Components с Variants, состояния UI показаны.
5. Понятен разработчику без дополнительных «устных» пояснений: правила адаптивности описаны в файле.