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. Понятен разработчику без дополнительных «устных» пояснений: правила адаптивности описаны в файле.