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