Требования к адаптивному дизайну в Figma

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

1.1. Страницы (Pages)

Рекомендуемая структура файла Figma:

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

---

Страница Responsive / Breakpoints

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

Содержит:

• описание системы брейкпоинтов и диапазонов
  (например: Mobile 375 → 320–768, Tablet 768 → 768–1024)
• примеры поведения ключевых блоков при ресайзе
  (например: перестроение карточек, скрытие sidebar, переход навигации в бургер-меню)
• визуальные пояснения изменений layout’а
  (например: смена количества колонок, изменение порядка блоков)
• комментарии для разработки
  (например: max-width контейнера, min-width карточки)

Страница не дублирует дизайн-экраны и не содержит полные версии интерфейса.

---

Страница Prototype

Страница, содержащая интерактивные пользовательские сценарии.

Содержит:

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

Страница не предназначена для хранения всех экранов проекта и используется только для демонстрации поведения интерфейса.

---

2. Брейкпоинты и принцип fluid-адаптива

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

В проекте используются якорные брейкпоинты, которые являются основными контрольными точками дизайна и описывают диапазоны ширин экранов, а не конкретные устройства.

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

Каждый брейкпоинт представлен отдельным Frame в Figma.

---

2.1.1. Гибкость системы брейкпоинтов

Количество брейкпоинтов не является фиксированным и может быть увеличено или сокращено в процессе работы, если:

• в рамках диапазона невозможно корректно отобразить дизайн,
• страдает визуальная иерархия или читаемость,
• меняется структура, сетка или навигация,
• этого требует продукт, контент или бизнес-логика.

Решение об изменении количества брейкпоинтов принимается дизайнером, заказчиком или менеджером проекта.

---

2.1.2. Связность брейкпоинтов

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

Каждый брейкпоинт обязан логически и визуально связываться с предыдущим и следующим брейкпоинтом.

Это означает:

• согласованную структуру layout’а,
• предсказуемые изменения между диапазонами,
• отсутствие «изолированных» версий дизайна.

Брейкпоинт не может существовать как самостоятельный, не связанный с соседними диапазонами.

---

2.2. Обязательное требование к ресайзу

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

Это означает:

• изменение ширины фрейма не ломает layout,
• элементы корректно тянутся или сжимаются,
• отступы и визуальная иерархия сохраняются,
• контент не выходит за границы контейнеров.

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

---

2.3. Реализация в Figma (обязательно)

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

• Auto Layout на всех контейнерах
• осознанные значения Hug / Fill / Fixed
• корректные Constraints
• min / max width для ключевых блоков (логически, не визуально)

Запрещено:

• проектировать макет только под фиксированную ширину
• компенсировать адаптивность дублированием фреймов
• использовать абсолютные размеры без необходимости

---

2.4. Проверка адаптивности (обязательная)

Для каждого якорного брейкпоинта дизайнер обязан:

1. Ресайзить фрейм до минимального значения диапазона
2. Ресайзить фрейм до максимального значения диапазона
3. Проверить:
   • поведение сетки
   • переносы текста
   • масштабирование карточек
   • поведение навигации
   • отсутствие коллизий

Макет считается не готовым, если он корректно работает только на базовой ширине.

---

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

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

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

• меняется сетка
• меняется навигация
• меняется структура контента

---

2.6. Связь с QA-чеклистом

Требование к обязательному ресайзу является частью QA-проверки адаптивности (см. раздел 14).

Отсутствие корректного ресайза в диапазоне считается критической ошибкой адаптивного дизайна.

---

3. Auto Layout (ключевое требование)

3.1. Обязательное использование

• Все контейнеры
• Все карточки
• Все списки
• Все кнопки
• Хедеры, футеры, сайдбары

Запрещено:

• Ручное позиционирование без Auto Layout
• Абсолютные отступы без необходимости

3.2. Настройки

• Padding задан со всех сторон
• Spacing между элементами через Auto Layout
• Использование Hug / Fill / Fixed осознанно

---

4. Constraints (Ограничения)

4.1. Обязательные правила

• Корректные Constraints:
  • Left / Right
  • Top / Bottom
  • Center
  • Scale (только при необходимости)

4.2. Проверка

• При изменении ширины фрейма интерфейс:
  • не ломается
  • не наезжает
  • не теряет пропорции

---

5. Grid / Layout Grid

5.1. Сетки

• Mobile: 4 колонки
• Tablet: 8 колонок
• Desktop: 12 колонок

5.2. Настройки

• Заданы:
  • Margin
  • Gutter
  • Column width
• Сетка соответствует реальной верстке

---

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

6.1. Компонентный подход

• Все повторяющиеся элементы — Components
• Использовать Variants вместо копий

6.2. Адаптивность компонентов

Каждый компонент:

• Тянется по ширине
• Меняет высоту по контенту
• Корректно ведёт себя в разных контейнерах

---

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

7.1. Стили текста

• Только через Text Styles
• Названия:
  H1 / H2 / Body / Caption / Button

7.2. Адаптивность текста

• Размеры шрифтов меняются между брейкпоинтами
• Line-height задан в %
• Ограничения по количеству строк (max lines)

---

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

8.1. Color Styles

• Все цвета — через стили
• Семантические названия:
  • Primary / Secondary
  • Text / Background / Border
  • Success / Error / Warning

---

9. Контент и состояния

9.1. Длина контента

• Короткий / нормальный / длинный текст
• Переполнение
• Перенос строк

9.2. Состояния UI

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

---

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

10.1. Адаптивность

• Fill / Fit задан осознанно
• Safe area для обрезки
• Поддержка разных соотношений сторон

---

11. Навигация

11.1. Поведение на разных экранах

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

---

12. Accessibility (A11y)

12.1. Минимальные требования

• Контраст ≥ WCAG AA
• Минимальный размер клика: 44×44 px
• Focus states
• Логичный tab order

---

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

13.1. Обязательные сценарии

• Основные пользовательские флоу
• Переходы между брейкпоинтами
• Проверка поведения при resize

---

14. Проверка адаптивности (QA в Figma)

14.1. Чеклист

• Ресайз фрейма вручную
• Переключение брейкпоинтов
• Проверка компонентов отдельно
• Проверка экстремальных значений

---

15. Передача в разработку

15.1. Требования

• Dev Mode включён
• Комментарии с логикой адаптивности
• Описаны:
  • брейкпоинты
  • поведение блоков
  • скрытие/появление элементов

---

16. Документация

16.1. Обязательно

• Описание принципов адаптива
• Таблица брейкпоинтов
• Примеры поведения блоков

---

17. Типичные ошибки (запрещено)

• Фиксированные ширины без причины
• Дубли компонентов под каждый экран
• Текст как вектор
• Ручные отступы
• Отсутствие Auto Layout

---

18. Минимальный стандарт качества

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

• Корректно ресайзится
• Использует Auto Layout + Constraints
• Имеет брейкпоинты
• Понятен разработчику без дополнительных объяснений