Добавить README.md

This commit is contained in:
2026-01-13 12:41:29 +03:00
commit be99cd5d16

369
README.md Normal file
View File

@@ -0,0 +1,369 @@
# Требования к адаптивному дизайну в Figma
## 1. Структура файла Figma
### 1.1. Страницы (Pages)
Рекомендуемая структура файла Figma:
- **Cover / Overview** — описание проекта, цели, контакты, ссылки
- **Design / UI** — финальные дизайн-экраны
- **Components** — все компоненты и их варианты
- **Styles / Tokens** — цветовые, текстовые и эффектные стили
- **Responsive / Breakpoints** — документация адаптивного поведения
- **Prototype** — пользовательские сценарии и интерактивность
- **Archive / Old** — устаревшие версии
---
#### Страница `Responsive / Breakpoints`
Служебная страница, предназначенная для фиксации и объяснения
адаптивной логики интерфейса.
Содержит:
- описание системы брейкпоинтов и диапазонов
*(например: Mobile 375 → 320768, Tablet 768 → 7681024)*
- примеры поведения ключевых блоков при ресайзе
*(например: перестроение карточек, скрытие 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
- Имеет брейкпоинты
- Понятен разработчику без дополнительных объяснений