# Требования к адаптивному дизайну в 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 - Имеет брейкпоинты - Понятен разработчику без дополнительных объяснений