Обновить README.md

This commit is contained in:
2026-01-13 13:08:04 +03:00
parent be99cd5d16
commit 5173f9baa4

379
README.md
View File

@@ -1,358 +1,139 @@
# Требования к адаптивному дизайну в Figma
# Требования к адаптивному дизайну в Figma (Сжатая версия)
## 1. Структура файла Figma
### 1.1. Страницы (Pages)
Рекомендуемая структура файла Figma:
Рекомендуемая структура:
- **Cover / Overview** — описание проекта, цели, контакты, ссылки
- **Design / UI** — финальные дизайн-экраны
- **Components** — все компоненты и их варианты
- **Styles / Tokens** — цветовые, текстовые и эффектные стили
- **Responsive / Breakpoints** — документация адаптивного поведения
- **Prototype** — пользовательские сценарии и интерактивность
- **Design / UI** — финальные экраны
- **Components** — повторяющиеся элементы и Variants
- **Styles / Tokens** — цвета, типографика, эффекты
- **Responsive / Breakpoints** — логика адаптивного поведения
- **Prototype** — интерактивные сценарии и флоу
- **Archive / Old** — устаревшие версии
---
#### Страница `Responsive / Breakpoints`
Служебная страница, предназначенная для фиксации и объяснения
адаптивной логики интерфейса.
Содержит:
- описание системы брейкпоинтов и диапазонов
*(например: Mobile 375 → 320768, Tablet 768 → 7681024)*
- примеры поведения ключевых блоков при ресайзе
*(например: перестроение карточек, скрытие sidebar, переход навигации в бургер-меню)*
- визуальные пояснения изменений layoutа
*(например: смена количества колонок, изменение порядка блоков)*
- комментарии для разработки
*(например: max-width контейнера, min-width карточки)*
Страница не дублирует дизайн-экраны и не содержит полные версии интерфейса.
> Примечание: Страницы `Responsive / Breakpoints` и `Prototype` не дублируют дизайн-экраны, служат для объяснения поведения интерфейса и интерактивности.
---
#### Страница `Prototype`
Страница, содержащая интерактивные пользовательские сценарии.
Содержит:
- ключевые пользовательские флоу
*(например: авторизация, оформление заказа, создание сущности)*
- интерактивные состояния интерфейса
*(например: открытие мобильного меню, модальное окно, dropdown)*
- переходы между экранами и состояниями
*(например: шаги формы, успешное/ошибочное состояние)*
Страница не предназначена для хранения всех экранов проекта
и используется только для демонстрации поведения интерфейса.
---
## 2. Брейкпоинты и принцип fluid-адаптива
### 2.1. Якорные брейкпоинты (структура)
В проекте используются **якорные брейкпоинты**, которые являются
основными контрольными точками дизайна и описывают
**диапазоны ширин экранов**, а не конкретные устройства.
## 2. Брейкпоинты и адаптивность
### 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 |
|---------|----------------|---------------|
| 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**.
- Каждый брейкпоинт отдельный Frame в Figma.
- Количество брейкпоинтов **может корректироваться** (визуальная иерархия, контент, сетка, навигация).
- Все брейкпоинты должны быть **логически и визуально связаны**.
### 2.2. Принцип «один фрейм — один диапазон»
- Один фрейм описывает **диапазон ширин**, а не отдельное устройство.
- Дополнительный фрейм — только при изменении сетки, навигации или структуры контента.
### 2.3. Обязательное требование к ресайзу
- Макеты должны **корректно ресайзиться во всём диапазоне**, без дополнительных фреймов.
- Проверяется:
- изменение ширины фрейма вручную до min/max диапазона
- поведение сетки, карточек, текста, навигации
- отсутствие коллизий и переполнений
- сохранение визуальной иерархии
> Макет некорректен, если работает только на базовой ширине.
### 2.4. Реализация в Figma
- **Обязательно:** Auto Layout на всех контейнерах, осознанные `Hug / Fill / Fixed`, Constraints, min/max width для ключевых блоков.
- **Запрещено:** ручное позиционирование без Auto Layout, абсолютные размеры без необходимости, дубли фреймов для адаптивности.
---
#### 2.1.1. Гибкость системы брейкпоинтов
Количество брейкпоинтов **не является фиксированным** и может быть
увеличено или сокращено в процессе работы, если:
- в рамках диапазона невозможно корректно отобразить дизайн,
- страдает визуальная иерархия или читаемость,
- меняется структура, сетка или навигация,
- этого требует продукт, контент или бизнес-логика.
Решение об изменении количества брейкпоинтов принимается
дизайнером, заказчиком или менеджером проекта.
## 3. Компоненты
- Все повторяющиеся элементы — **Components**; использовать **Variants** вместо копий.
- Адаптивность компонентов:
- тянутся по ширине
- меняют высоту по контенту
- корректно ведут себя в разных контейнерах
---
#### 2.1.2. Связность брейкпоинтов
## 4. Сетка / Layout Grid
| Device | Колонки |
|---------|---------|
| Mobile | 4 |
| Tablet | 8 |
| Desktop | 12 |
При любом изменении системы брейкпоинтов должно соблюдаться правило:
> Каждый брейкпоинт обязан логически и визуально
> связываться с предыдущим и следующим брейкпоинтом.
Это означает:
- согласованную структуру layoutа,
- предсказуемые изменения между диапазонами,
- отсутствие «изолированных» версий дизайна.
Брейкпоинт не может существовать как самостоятельный,
не связанный с соседними диапазонами.
- Настройки: margin, gutter, column width
- Сетка должна соответствовать верстке
---
### 2.2. Обязательное требование к ресайзу
Каждая версия дизайна **обязана корректно ресайзиться во всём своём диапазоне**,
**без создания дополнительных фреймов**.
Это означает:
- изменение ширины фрейма **не ломает layout**,
- элементы корректно тянутся или сжимаются,
- отступы и визуальная иерархия сохраняются,
- контент не выходит за границы контейнеров.
Макет считается некорректным, если он работает
только на базовой ширине брейкпоинта.
## 5. Типографика
- Только через **Text Styles** (`H1 / H2 / Body / Caption / Button`)
- Размеры шрифтов могут меняться между брейкпоинтами
- Line-height в %, ограничения по количеству строк
---
### 2.3. Реализация в Figma (обязательно)
Для обеспечения корректного ресайза должны использоваться:
- **Auto Layout** на всех контейнерах
- осознанные значения `Hug / Fill / Fixed`
- корректные **Constraints**
- min / max width для ключевых блоков (логически, не визуально)
Запрещено:
- проектировать макет только под фиксированную ширину
- компенсировать адаптивность дублированием фреймов
- использовать абсолютные размеры без необходимости
## 6. Цвета и стили
- **Color Styles** с семантическими названиями:
`Primary / Secondary`, `Text / Background / Border`, `Success / Error / Warning`
---
### 2.4. Проверка адаптивности (обязательная)
Для каждого якорного брейкпоинта дизайнер обязан:
1. Ресайзить фрейм до минимального значения диапазона
2. Ресайзить фрейм до максимального значения диапазона
3. Проверить:
- поведение сетки
- переносы текста
- масштабирование карточек
- поведение навигации
- отсутствие коллизий
Макет считается **не готовым**, если он корректно работает только
на базовой ширине.
## 7. Контент и состояния UI
- Текст: короткий / нормальный / длинный, проверка переполнения
- Состояния UI: Default, Hover, Active, Disabled, Focus, Loading, Empty, Error
---
### 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` задан осознанно
## 8. Изображения и медиа
- Использовать `Fill / Fit` осознанно
- Safe area для обрезки
- Поддержка разных соотношений сторон
- Форматы и размеры соответствуют проекту
---
## 11. Навигация
### 11.1. Поведение на разных экранах
## 9. Навигация
- Desktop → горизонтальное меню
- Tablet → сокращённое меню
- Mobile → бургер / bottom bar
---
## 12. Accessibility (A11y)
### 12.1. Минимальные требования
## 10. Accessibility (A11y)
- Контраст ≥ WCAG AA
- Минимальный размер клика: 44×44 px
- Focus states
- Логичный tab order
- Focus states, логичный tab order
---
## 13. Прототипирование
### 13.1. Обязательные сценарии
## 11. Прототипирование
- Основные пользовательские флоу
- Переходы между брейкпоинтами
- Проверка поведения при resize
- Проверка поведения при ресайзе
---
## 14. Проверка адаптивности (QA в Figma)
### 14.1. Чеклист
- Ресайз фрейма вручную
- Переключение брейкпоинтов
## 12. QA и проверка адаптивности
- Ресайз фрейма вручную до min/max диапазона
- Проверка компонентов отдельно
- Проверка экстремальных значений
- Макет готов, если ресайз работает корректно во всём диапазоне и нет коллизий
---
## 15. Передача в разработку
### 15.1. Требования
## 13. Передача разработчику
- Dev Mode включён
- Комментарии с логикой адаптивности
- Описаны:
- брейкпоинты
- поведение блоков
- скрытие/появление элементов
- Описаны брейкпоинты, поведение блоков, скрытие/появление элементов
---
## 16. Документация
### 16.1. Обязательно
- Описание принципов адаптива
- Таблица брейкпоинтов
- Примеры поведения блоков
---
## 17. Типичные ошибки (запрещено)
## 14. Запрещено
- Фиксированные ширины без причины
- Дубли компонентов под каждый экран
- Текст как вектор
@@ -361,9 +142,9 @@
---
## 18. Минимальный стандарт качества
Макет считается **адаптивным**, если:
- Корректно ресайзится
- Использует Auto Layout + Constraints
- Имеет брейкпоинты
- Понятен разработчику без дополнительных объяснений
## 15. Минимальный стандарт качества
Макет считается адаптивным, если:
1. Корректно ресайзится во всём диапазоне
2. Использует Auto Layout + Constraints
3. Имеет брейкпоинты
4. Понятен разработчику без дополнительных объяснений