diff --git a/README.md b/README.md index a9da7b1..57386be 100644 --- a/README.md +++ b/README.md @@ -1,150 +1,8 @@ -# Требования к адаптивному дизайну в Figma (Сжатая версия) +# Figma Adaptive Standards -## 1. Структура файла Figma -Рекомендуемая структура: +Стандарты и требования к подготовке **адаптивных макетов в Figma**: брейкпоинты, ресайз в диапазоне, Auto Layout/Constraints, компоненты, сетка, типографика, состояния UI, A11y и передача в разработку. -- **Cover / Overview** — описание проекта, цели, контакты, ссылки -- **Design / UI** — финальные экраны -- **Components** — повторяющиеся элементы и Variants -- **Styles / Tokens** — цвета, типографика, эффекты -- **Responsive / Breakpoints** — логика адаптивного поведения -- **Prototype** — интерактивные сценарии и флоу -- **Archive / Old** — устаревшие версии - -> Примечание: Страницы `Responsive / Breakpoints` и `Prototype` не дублируют дизайн-экраны, служат для объяснения поведения интерфейса и интерактивности. - ---- - -## 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 в Figma. -- Количество брейкпоинтов **может корректироваться** (визуальная иерархия, контент, сетка, навигация). -- Все брейкпоинты должны быть **логически и визуально связаны**. - -### 2.2. Принцип «один фрейм — один диапазон» -- Один фрейм описывает **диапазон ширин**, а не отдельное устройство. -- Дополнительный фрейм — только при изменении сетки, навигации или структуры контента. - -### 2.3. Обязательное требование к ресайзу -- Макеты должны **корректно ресайзиться во всём диапазоне**, без дополнительных фреймов. -- Проверяется: - - изменение ширины фрейма вручную до min/max диапазона - - поведение сетки, карточек, текста, навигации - - отсутствие коллизий и переполнений - - сохранение визуальной иерархии - -> Макет некорректен, если работает только на базовой ширине. - -### 2.4. Реализация в Figma -- **Обязательно:** Auto Layout на всех контейнерах, осознанные `Hug / Fill / Fixed`, Constraints, min/max width для ключевых блоков. -- **Запрещено:** ручное позиционирование без Auto Layout, абсолютные размеры без необходимости, дубли фреймов для адаптивности. - ---- - -## 3. Компоненты -- Все повторяющиеся элементы — **Components**; использовать **Variants** вместо копий. -- Адаптивность компонентов: - - тянутся по ширине - - меняют высоту по контенту - - корректно ведут себя в разных контейнерах - ---- - -## 4. Сетка / Layout Grid -| Device | Колонки | -|---------|---------| -| Mobile | 4 | -| Tablet | 8 | -| Desktop | 12 | - -- Настройки: margin, gutter, column width -- Сетка должна соответствовать верстке - ---- - -## 5. Типографика -- Только через **Text Styles** (`H1 / H2 / Body / Caption / Button`) -- Размеры шрифтов могут меняться между брейкпоинтами -- Line-height в %, ограничения по количеству строк - ---- - -## 6. Цвета и стили -- **Color Styles** с семантическими названиями: - `Primary / Secondary`, `Text / Background / Border`, `Success / Error / Warning` - ---- - -## 7. Контент и состояния UI -- Текст: короткий / нормальный / длинный, проверка переполнения -- Состояния UI: Default, Hover, Active, Disabled, Focus, Loading, Empty, Error - ---- - -## 8. Изображения и медиа -- Использовать `Fill / Fit` осознанно -- Safe area для обрезки -- Поддержка разных соотношений сторон -- Форматы и размеры соответствуют проекту - ---- - -## 9. Навигация -- Desktop → горизонтальное меню -- Tablet → сокращённое меню -- Mobile → бургер / bottom bar - ---- - -## 10. Accessibility (A11y) -- Контраст ≥ WCAG AA -- Минимальный размер клика: 44×44 px -- Focus states, логичный tab order - ---- - -## 11. Прототипирование -- Основные пользовательские флоу -- Переходы между брейкпоинтами -- Проверка поведения при ресайзе - ---- - -## 12. QA и проверка адаптивности -- Ресайз фрейма вручную до min/max диапазона -- Проверка компонентов отдельно -- Проверка экстремальных значений -- Макет готов, если ресайз работает корректно во всём диапазоне и нет коллизий - ---- - -## 13. Передача разработчику -- Dev Mode включён -- Комментарии с логикой адаптивности -- Описаны брейкпоинты, поведение блоков, скрытие/появление элементов - ---- - -## 14. Запрещено -- Фиксированные ширины без причины -- Дубли компонентов под каждый экран -- Текст как вектор -- Ручные отступы -- Отсутствие Auto Layout - ---- - -## 15. Минимальный стандарт качества -Макет считается адаптивным, если: -1. Корректно ресайзится во всём диапазоне -2. Использует Auto Layout + Constraints -3. Имеет брейкпоинты -4. Понятен разработчику без дополнительных объяснений +## Документы +- Сжатая версия (для быстрого ознакомления): [adaptive-layout-requirements.short.md](adaptive-layout-requirements.short.md) +- Полная версия (подробные требования и правила): [adaptive-layout-requirements.full.md](adaptive-layout-requirements.full.md) +- Чеклист приёмки (QA макета перед передачей): [adaptive-layout-requirements.checklist.md](adaptive-layout-requirements.checklist.md) diff --git a/adaptive-layout-requirements.checklist.md b/adaptive-layout-requirements.checklist.md new file mode 100644 index 0000000..4bb7b5d --- /dev/null +++ b/adaptive-layout-requirements.checklist.md @@ -0,0 +1,133 @@ +# Чеклист приёмки макета (Figma) + +## 0. Структура файла и нейминг +- [ ] В файле есть рабочие страницы: Cover / Overview, Design / UI, Components, Styles / Tokens, Responsive / Breakpoints, Prototype (Archive / Old — при необходимости) +- [ ] Экраны названы по единому правилу (например: `Feature / Screen — Breakpoint`) +- [ ] Компоненты названы семантически и единообразно (без «Button 1 / Button 2») +- [ ] На странице `Responsive / Breakpoints` описаны правила перестроения для сложных зон (колонки, переносы, скрытие/появление элементов) + +--- + +## 1. Брейкпоинты +- [ ] Все якорные брейкпоинты созданы в виде отдельных фреймов + - Mobile, Tablet, Laptop, Desktop (диапазоны соблюдены) +- [ ] Границы диапазонов трактуются единообразно (например: `Mobile < 768`, `Tablet ≥ 768`) +- [ ] Фреймы логически и визуально связаны +- [ ] Дополнительные фреймы есть только при изменении сетки, навигации или структуры контента + +--- + +## 2. Адаптивность и ресайз +- [ ] Ресайз фрейма вручную до минимального значения диапазона +- [ ] Ресайз фрейма до максимального значения диапазона +- [ ] Проверены промежуточные значения (минимум 3–5 точек внутри диапазона) +- [ ] Макет корректно меняется во всём диапазоне без создания дублирующих фреймов +- [ ] Нет коллизий при ресайзе (наезды, обрезания, неожиданные перекрытия) +- [ ] Карточки и блоки тянутся или сжимаются корректно +- [ ] Текст переносится/обрезается по правилам и не выходит за пределы контейнеров +- [ ] Навигация корректно адаптируется под ширину + +--- + +## 3. Auto Layout и Constraints +- [ ] Все контейнеры, списки, карточки, кнопки, хедеры, футеры, сайдбары используют Auto Layout +- [ ] Padding задан со всех сторон через Auto Layout (без «ручных» отступов) +- [ ] Spacing между элементами задан через Auto Layout +- [ ] Режимы ресайза настроены осознанно (`Hug / Fill / Fixed`) для ключевых контейнеров и элементов +- [ ] При необходимости заданы min/max (для предотвращения поломок на крайних ширинах) +- [ ] Constraints заданы корректно (Left / Right / Top / Bottom / Center / Scale) там, где Auto Layout не покрывает сценарий +- [ ] Нет ручного позиционирования или абсолютных размеров без причины + +--- + +## 4. Сетка / Layout Grid +- [ ] Layout Grid настроен на фреймах каждого брейкпоинта (колонки соответствуют принятому стандарту) +- [ ] Margin и gutter заданы и согласованы с версткой +- [ ] Поведение сетки выбрано осознанно (Stretch/Center — по модели проекта) +- [ ] Основные блоки выровнены по сетке и используют согласованный шаг отступов + +--- + +## 5. Компоненты +- [ ] Все повторяющиеся элементы оформлены как Components +- [ ] Используются Variants вместо копий +- [ ] Состояния компонентов показаны (минимум: Default, Hover, Active/Pressed, Disabled, Focus — если применимо) +- [ ] Компоненты корректно тянутся и меняют высоту по контенту +- [ ] Адаптивное поведение проверено во всех типовых контейнерах (экран, модалка, сайдбар, список/сетка) + +--- + +## 6. Типографика +- [ ] Используются Text Styles (`H1 / H2 / Body / Caption / Button` или принятый набор) +- [ ] Размер шрифта адаптируется между брейкпоинтами (если это предусмотрено) +- [ ] Line-height задан осознанно (в % или по принятому стандарту) +- [ ] Ограничение количества строк соблюдено там, где это критично +- [ ] Правила для текста определены: перенос или обрезка (truncate), поведение при переполнении проверено + +--- + +## 7. Цвета и стили +- [ ] Все цвета через Color Styles +- [ ] Семантические названия соблюдены (`Primary / Secondary`, `Text / Background / Border`, `Success / Error / Warning`) +- [ ] Дополнительные стили (тени/обводки/радиусы), если используются, применены единообразно + +--- + +## 8. Контент и состояния UI +- [ ] Текст проверен на короткие / нормальные / длинные варианты +- [ ] Проверка переполнения и переноса строк выполнена +- [ ] Состояния UI присутствуют: Default, Hover, Active, Disabled, Focus, Loading, Empty, Error +- [ ] Для форм/инпутов показаны состояния ошибок и валидации (включая сочетания вроде `Focus + Error`, если применимо) + +--- + +## 9. Изображения и медиа +- [ ] Fill / Fit задан корректно +- [ ] Safe area для обрезки изображений соблюдена +- [ ] Поддерживаются разные соотношения сторон (описано поведение при изменении ratio) +- [ ] Форматы и размеры соответствуют требованиям проекта (если есть требования к экспорту) + +--- + +## 10. Навигация +- [ ] Desktop → горизонтальное меню +- [ ] Tablet → сокращённое меню +- [ ] Mobile → бургер / bottom bar +- [ ] Описаны правила overflow/сокращения (что уходит в «ещё», что скрывается/переезжает) + +--- + +## 11. Accessibility (A11y) +- [ ] Контраст ≥ WCAG AA +- [ ] Минимальный размер клика 44×44 px +- [ ] Focus states проверены +- [ ] Логичный tab order соблюден + +--- + +## 12. Прототипирование +- [ ] Основные пользовательские флоу представлены +- [ ] Переходы между брейкпоинтами реализованы (если требуется) +- [ ] Поведение при ресайзе проверено/продемонстрировано + +--- + +## 13. Передача в разработку +- [ ] Dev Mode включён +- [ ] Все комментарии с логикой адаптивности оставлены +- [ ] Брейкпоинты, поведение блоков, скрытие/появление элементов описаны +- [ ] Ассеты к экспорту подготовлены (если требуется): корректные имена, форматы, настройки экспорта + +--- + +## 14. Запрещено +- [ ] Фиксированные ширины без причины +- [ ] Дубли компонентов под каждый экран +- [ ] Текст как вектор +- [ ] Ручные отступы +- [ ] Отсутствие Auto Layout + +--- + +## ✅ Итоговое решение +Макет считается **готовым к разработке**, если выполнены все пункты чеклиста и ресайз работает корректно во всех диапазонах. diff --git a/adaptive-layout-requirements.full.md b/adaptive-layout-requirements.full.md new file mode 100644 index 0000000..0ae3ddc --- /dev/null +++ b/adaptive-layout-requirements.full.md @@ -0,0 +1,459 @@ +# Требования к адаптивному дизайну в Figma (Полная версия) + +Документ описывает стандарт подготовки **адаптивных** макетов в Figma так, чтобы они: + +- корректно **ресайзились** в пределах заданных диапазонов ширин; +- были **предсказуемы** для разработки (верстки); +- минимизировали количество «ручных» правок и дублирования; +- содержали достаточные пояснения по поведению UI. + +## Кому адресовано +- Дизайнерам интерфейсов +- Team Lead / DesignOps +- Разработчикам (для валидации качества и передачи в работу) + +## Термины (коротко) +- **Брейкпоинт** — якорная ширина и набор правил компоновки, по которым интерфейс меняет структуру. +- **Диапазон** — интервал ширин, где **один** макет обязан работать корректно при ресайзе. +- **Auto Layout** — основной механизм адаптивности в Figma для контейнеров и компонентов. +- **Hug / Fill / Fixed** — режимы ресайза (по контенту / заполнять контейнер / фиксированно). +- **Constraints** — привязки объектов внутри Frame (Left/Right/Top/Bottom/Center/Scale). + +--- + +## 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 +Все тексты обязаны использовать **Text Styles**. + +Минимальный набор (пример семантики): +- `H1`, `H2`, `H3` +- `Body / Regular`, `Body / Medium` +- `Caption` +- `Button` + +Требования: +- одинаковая семантика должна выглядеть согласованно во всех экранах; +- локальные «ручные» размеры шрифта недопустимы, если это не исключение, закреплённое в системе. + +### 5.2. Адаптация типографики между брейкпоинтами +Допускается изменение: +- размера шрифта; +- межстрочного интервала; +- межбуквенного интервала (редко и осознанно); +- ограничения количества строк. + +Правило: +- изменения типографики между брейкпоинтами должны быть предсказуемыми и фиксироваться как правило (например: `H1` на Mobile меньше на 2–4px). + +### 5.3. Многострочный текст: переносы и ограничения +Для ключевых текстовых блоков обязаны быть определены правила: +- переносится ли текст (wrap) или обрезается (truncate); +- сколько максимум строк допустимо в карточке/ячейке; +- что происходит при переполнении (например, `…` + tooltip в продуктовых требованиях — если применимо). + +Минимальная проверка контента: +- короткий текст; +- нормальный (ожидаемый); +- длинный; +- «экстремальный» (очень длинный) — для выявления поломок. + +--- + +## 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. Понятен разработчику без дополнительных «устных» пояснений: правила адаптивности описаны в файле. diff --git a/adaptive-layout-requirements.short.md b/adaptive-layout-requirements.short.md new file mode 100644 index 0000000..a9da7b1 --- /dev/null +++ b/adaptive-layout-requirements.short.md @@ -0,0 +1,150 @@ +# Требования к адаптивному дизайну в Figma (Сжатая версия) + +## 1. Структура файла Figma +Рекомендуемая структура: + +- **Cover / Overview** — описание проекта, цели, контакты, ссылки +- **Design / UI** — финальные экраны +- **Components** — повторяющиеся элементы и Variants +- **Styles / Tokens** — цвета, типографика, эффекты +- **Responsive / Breakpoints** — логика адаптивного поведения +- **Prototype** — интерактивные сценарии и флоу +- **Archive / Old** — устаревшие версии + +> Примечание: Страницы `Responsive / Breakpoints` и `Prototype` не дублируют дизайн-экраны, служат для объяснения поведения интерфейса и интерактивности. + +--- + +## 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 в Figma. +- Количество брейкпоинтов **может корректироваться** (визуальная иерархия, контент, сетка, навигация). +- Все брейкпоинты должны быть **логически и визуально связаны**. + +### 2.2. Принцип «один фрейм — один диапазон» +- Один фрейм описывает **диапазон ширин**, а не отдельное устройство. +- Дополнительный фрейм — только при изменении сетки, навигации или структуры контента. + +### 2.3. Обязательное требование к ресайзу +- Макеты должны **корректно ресайзиться во всём диапазоне**, без дополнительных фреймов. +- Проверяется: + - изменение ширины фрейма вручную до min/max диапазона + - поведение сетки, карточек, текста, навигации + - отсутствие коллизий и переполнений + - сохранение визуальной иерархии + +> Макет некорректен, если работает только на базовой ширине. + +### 2.4. Реализация в Figma +- **Обязательно:** Auto Layout на всех контейнерах, осознанные `Hug / Fill / Fixed`, Constraints, min/max width для ключевых блоков. +- **Запрещено:** ручное позиционирование без Auto Layout, абсолютные размеры без необходимости, дубли фреймов для адаптивности. + +--- + +## 3. Компоненты +- Все повторяющиеся элементы — **Components**; использовать **Variants** вместо копий. +- Адаптивность компонентов: + - тянутся по ширине + - меняют высоту по контенту + - корректно ведут себя в разных контейнерах + +--- + +## 4. Сетка / Layout Grid +| Device | Колонки | +|---------|---------| +| Mobile | 4 | +| Tablet | 8 | +| Desktop | 12 | + +- Настройки: margin, gutter, column width +- Сетка должна соответствовать верстке + +--- + +## 5. Типографика +- Только через **Text Styles** (`H1 / H2 / Body / Caption / Button`) +- Размеры шрифтов могут меняться между брейкпоинтами +- Line-height в %, ограничения по количеству строк + +--- + +## 6. Цвета и стили +- **Color Styles** с семантическими названиями: + `Primary / Secondary`, `Text / Background / Border`, `Success / Error / Warning` + +--- + +## 7. Контент и состояния UI +- Текст: короткий / нормальный / длинный, проверка переполнения +- Состояния UI: Default, Hover, Active, Disabled, Focus, Loading, Empty, Error + +--- + +## 8. Изображения и медиа +- Использовать `Fill / Fit` осознанно +- Safe area для обрезки +- Поддержка разных соотношений сторон +- Форматы и размеры соответствуют проекту + +--- + +## 9. Навигация +- Desktop → горизонтальное меню +- Tablet → сокращённое меню +- Mobile → бургер / bottom bar + +--- + +## 10. Accessibility (A11y) +- Контраст ≥ WCAG AA +- Минимальный размер клика: 44×44 px +- Focus states, логичный tab order + +--- + +## 11. Прототипирование +- Основные пользовательские флоу +- Переходы между брейкпоинтами +- Проверка поведения при ресайзе + +--- + +## 12. QA и проверка адаптивности +- Ресайз фрейма вручную до min/max диапазона +- Проверка компонентов отдельно +- Проверка экстремальных значений +- Макет готов, если ресайз работает корректно во всём диапазоне и нет коллизий + +--- + +## 13. Передача разработчику +- Dev Mode включён +- Комментарии с логикой адаптивности +- Описаны брейкпоинты, поведение блоков, скрытие/появление элементов + +--- + +## 14. Запрещено +- Фиксированные ширины без причины +- Дубли компонентов под каждый экран +- Текст как вектор +- Ручные отступы +- Отсутствие Auto Layout + +--- + +## 15. Минимальный стандарт качества +Макет считается адаптивным, если: +1. Корректно ресайзится во всём диапазоне +2. Использует Auto Layout + Constraints +3. Имеет брейкпоинты +4. Понятен разработчику без дополнительных объяснений diff --git a/checklist.md b/checklist.md deleted file mode 100644 index 2e30363..0000000 --- a/checklist.md +++ /dev/null @@ -1,107 +0,0 @@ -# Чеклист приёмки макета (Figma) - -## 1. Брейкпоинты -- [ ] Все якорные брейкпоинты созданы в виде отдельных фреймов - - Mobile, Tablet, Laptop, Desktop (диапазоны соблюдены) -- [ ] Фреймы логически и визуально связаны -- [ ] Дополнительные фреймы есть только при изменении сетки, навигации или структуры контента - ---- - -## 2. Адаптивность и ресайз -- [ ] Ресайз фрейма вручную до минимального значения диапазона -- [ ] Ресайз фрейма до максимального значения диапазона -- [ ] Макет корректно меняется во всём диапазоне без создания дублирующих фреймов -- [ ] Сетка ведёт себя предсказуемо (колонки, отступы, порядок элементов) -- [ ] Карточки и блоки тянутся или сжимаются корректно -- [ ] Текст переносится и не выходит за пределы контейнеров -- [ ] Навигация корректно адаптируется под устройство - ---- - -## 3. Auto Layout и Constraints -- [ ] Все контейнеры, списки, карточки, кнопки, хедеры, футеры, сайдбары используют Auto Layout -- [ ] Padding задан со всех сторон -- [ ] Spacing между элементами через Auto Layout -- [ ] Constraints заданы корректно (Left / Right / Top / Bottom / Center / Scale) -- [ ] Нет ручного позиционирования или абсолютных размеров без причины - ---- - -## 4. Компоненты -- [ ] Все повторяющиеся элементы оформлены как Components -- [ ] Используются Variants вместо копий -- [ ] Компоненты корректно тянутся и меняют высоту по контенту -- [ ] Адаптивное поведение проверено во всех контейнерах - ---- - -## 5. Типографика -- [ ] Используются Text Styles (`H1 / H2 / Body / Caption / Button`) -- [ ] Размер шрифта адаптируется между брейкпоинтами -- [ ] Line-height задан в % -- [ ] Ограничение количества строк соблюдено - ---- - -## 6. Цвета и стили -- [ ] Все цвета через Color Styles -- [ ] Семантические названия соблюдены (`Primary / Secondary`, `Text / Background / Border`, `Success / Error / Warning`) - ---- - -## 7. Контент и состояния UI -- [ ] Текст проверен на короткие / длинные варианты -- [ ] Проверка переполнения и переноса строк выполнена -- [ ] Состояния UI присутствуют: Default, Hover, Active, Disabled, Focus, Loading, Empty, Error - ---- - -## 8. Изображения и медиа -- [ ] Fill / Fit задан корректно -- [ ] Safe area для обрезки изображений соблюдена -- [ ] Поддерживаются разные соотношения сторон -- [ ] Форматы и размеры соответствуют требованиям проекта - ---- - -## 9. Навигация -- [ ] Desktop → горизонтальное меню -- [ ] Tablet → сокращённое меню -- [ ] Mobile → бургер / bottom bar - ---- - -## 10. Accessibility (A11y) -- [ ] Контраст ≥ WCAG AA -- [ ] Минимальный размер клика 44×44 px -- [ ] Focus states проверены -- [ ] Логичный tab order соблюден - ---- - -## 11. Прототипирование -- [ ] Основные пользовательские флоу представлены -- [ ] Переходы между брейкпоинтами реализованы -- [ ] Поведение при ресайзе проверено - ---- - -## 12. Передача в разработку -- [ ] Dev Mode включён -- [ ] Все комментарии с логикой адаптивности оставлены -- [ ] Брэйкпоинты, поведение блоков, скрытие/появление элементов описаны - ---- - -## 13. Запрещено -- [ ] Фиксированные ширины без причины -- [ ] Дубли компонентов под каждый экран -- [ ] Текст как вектор -- [ ] Ручные отступы -- [ ] Отсутствие Auto Layout - ---- - -## ✅ Итоговое решение -Макет считается **готовым к разработке**, если выполнены все пункты чеклиста и ресайз работает корректно во всех диапазонах.