Стандарты Web UI

(структура для Ильи — наполняй)

---

1. Цель документа

Коротко (2–3 предложения):

Зачем мы вводим стандарты.

Какой результат хотим получить.

Что это даст команде и проектам.

Версия: v0.1 Draft

Пример:
“Этот документ фиксируетустанавливает базовыеединые правиластандарты планированияработы дизайнанад дизайном для заказчиков, чтобы минимизировать правки, повысить предсказуемость процесса и версткиобеспечить встабильное проектахкачество Webрезультата. UI,Он чтобыпомогает снизитькоманде количествоговорить переделок,с ускоритьклиентами разработкуна одном языке, быстрее согласовывать решения и выровнятьформировать качество.профессиональный Документподход служитк отправнойкаждому точкой — он не финален и будет расти по мере накопления опыта.”проекту.

---

2. Базовые принципы

Пусть Илья сформулирует 6–10 принципов.
Это должен быть краткий список, не объяснения.

Примеры (пусть перепишет своими словами):

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

• МаксимумВизуальное решенийнаправление принимаетсявсегда согласуется через мудборды или по брендбуку до проработки макетов

При наличии брендбука строго соблюдаются его правила

Макеты строятся на этапесетках дизайна,с апродуманной неструктурой вконтента

верстке.

Адаптивный дизайн делается только при наличии задачи/заказа на адаптив

Интерфейсы собираются из системных компонентов и UI Kit

Все макеты — толькоделаются на автолэйаутах.автолейаутах

ДизайнПеред долженфинальным бытьутверждением адаптивензаказчику повсегда определённойпредоставляется сетке.

Все интерфейсы строятся из повторяемых компонент.

Правки должны быть заранее обсуждены на фазе прототипа.прототип

Дизайнер исам фронтендерпредставляет синхронизируютсясвой передпрототип стартом верстки.заказчику

ВПосле заказчикеутверждения заложитьдизайна ожидания:любые будетизменения 1–2вносятся волнытолько правок,при нокрайней ненеобходимости 10.(недоработки со стороны дизайнера, несоответствие логики и действий, критичные правки от заказчика)

---

3. Процесс работы (Pipeline)

Короткий pipeline из 6 шагов.

Шаг 1. Получение задачи и всех материалов

• Менеджер формулирует ТЗ →и дизайнерпередаёт получаетдизайнеру контекст.весь контекст задачи и материалы полученные от заказчика

Шаг 2. Прототипирование (быстрый черновик)

• Ч/Б структура.Мудборд/брендбук

• Сетка.Расстановка элементов по сетке/правилам
  

• Базовая

  Примерныелогика компоненты.

  переходов/реакций компонентов

Шаг 3. Согласование прототипа с менеджером и Art (Artem)

• Только одна встреча.

Утверждаются ключевые элементы.элементы/логика/цвета/картинки

Шаг 4. Полноценный дизайн

• Цвета,Работа типографика,с отступы,цветами

Типографика

Названия компонентов

UI-kit

элементы, автолэйаут везде.

Автолэйаут

Шаг 5. Передача дизайна фронту

• Дизайнер делаетпередаёт короткийфинальные walkthrough:
  —макеты какиефронтенду блокивместе повторяются
  —с чтонеобходимыми компонент
  —пояснениями: какиеповторяющиеся отступыблоки, компоненты, намеренные
  — чтоотступы, допускдопустимые ±10pxвариации.

• ФронтФронтенд проверяет дизайн и задаёт вопросы. Если обнаружены элементы, которые невозможно реализовать или реализация чрезмерно сложна, дизайн возвращается на доработку или обсуждается альтернативное решение, исходя из потребностей заказчика.

Шаг 6. Доработки на этапе интеграции

• Мелкие правки принимаем(коррекции спокойно.цветов, шрифтов, иконок, изображений) принимаются без проблем

• Крупные —изменения фиксируем(перестройка структуры, изменение расположения элементов, добавление новых блоков или новых версий макета) отклоняются, так как требуют значительного переработки дизайна и учитываемвёрстки. вМасштабные следующихправки проектах.согласуются отдельно и выполняются только при дополнительном бюджете и сроках

---

4. Требования к дизайну (Design Standards)

Здесь Илья должен написать конкретные пункты:

4.1 Сетка

Сетка — основа композиции и структурирования контента. Она обеспечивает порядок, предсказуемость и согласованность элементов внутри макетов.
Сетка должна быть создана в Figma инструментом Layout Grid и применена ко всем фреймам и страницам проекта.

4.1.1 Типы сеток

В Figma используются 3 вида сеток:

Column Grid (например)колонки)
Подходит для лендингов, сайтов, сложных интерфейсов, адаптивной верстки.
Примеры использования:

• 8-поинтовая12 системаколонок отступов.с gutter 20–32

• Базовый8 контейнер:колонок 320для →мобильных

  540

→ 960

4 →колонки 1200.для компактных блоков

Row Grid (ряды)
Используется реже, но помогает выстроить строгий вертикальный ритм.

Grid (равномерная сетка)
Идеальна для карточек, плиток, галерей, иконок, dashboard-интерфейсов.

4.1.2 АвтолэйаутВыбор сетки

Выбор сетки зависит от задач проекта:

• Требование:Корпоративный сайт / лендинг — 12 колонок (desktop), 4–8 колонок (tablet), 2–4 (mobile).

Личный кабинет / платформа / интерфейс с таблицами — сетка с широкими колонками + плотный вертикальный ритм.

Каталоги, плитки, карточки — grid 4–8 px step.

Простые страницы — 960 px или 1200 px контейнер.

Важно:
Сетка должна быть выбрана и утверждена на этапе прототипа и неизменно применяться на всех страницах.

4.1.3 Применение сетки

Сетка включается у всех главных фреймов.

Элементы выравниваются строго по колонкам и кратно выбранным отступам.

Блоки, заголовки, карточки, формы следуют вертикальному ритму (например 100 px между секциями).

Если используется адаптив — создаётся отдельная сетка для каждой точки перелома (mobile / tablet / desktop).

 

4.2 Auto Layout

Auto Layout — обязательный инструмент для всех элементов.
100% блоковблоков, карточек, кнопок, форм и секций должны быть всобраны автолэйаутах.через Auto Layout.

4.2.1 Основные правила Auto Layout

Все компоненты и фреймы должны иметь Auto Layout.

Отступы задаются только через Auto Layout (padding / gap).

Никаких ручных отступов.pixel-perfect отступов между элементами.

Выравнивание внутри контейнера: left, center, space-between — задаётся заранее и одинаково используется в проекте. Не используем нижнее выравнивание.

Auto Layout применяется даже для мелких элементов:

кнопок

карточек

тегов

списков

пунктов меню

табов

любых повторяющихся структур

4.2.3 Почему нельзя использовать ручные отступы

Ручные расстояния ломают масштабирование.

При адаптиве или любом изменении текстов блок разваливается.

При переносе в UI Kit компонент перестаёт быть универсальным.

Разметка становится несинхронной с фронтендом.

4.2.4 Стандартизация отступов

Отступы — не «на глаз». Их нужно утверждать заранее и использовать одинаково по проекту.

Примеры стандартизации:

Отступ после заголовка: 30 px

Расстояние между секциями: 100 px

Между карточками: 24 px

Между строками таблицы: 16 px

Внутренние отступы кнопки: 12–16 px по вертикали

Все эти значения:

согласуются заранее

записываются в документацию

применяются авто-лэйаутами

НЕ меняются в каждом новом блоке

4.2.5 Variables для отступов и размеров

Если проект крупный, количество размеров растёт. Чтобы не хранить их в голове — используется:

Figma Variables → Spacing Variables

Создаются переменные:

Spacing/Section = 100 px

Spacing/Title = 30 px

Spacing/CardGap = 24 px

Padding/ButtonY = 12 px

Padding/ButtonX = 24 px

Преимущества:

можно менять отступы централизованно

можно ограничивать их применение (например, variable только для paddings)

дизайнер не ошибётся в цифрах

все блоки сохраняют единый ритм

4.2.6 Auto Layout как структура интерфейса

Любой сложный блок собирается как дерево Auto Layout:

Секция → Контейнер → Колонка/Ряд → Компоненты → Элементы

Для примера:

Главный блок

Внутри контейнер шириной 1200

Внутри — заголовок (auto layout)

Под заголовком — текстовый блок (auto layout)

Карточки (auto layout grid)

Каждая карточка — компонент из auto layout

Кнопка внутри карточки — тоже auto layout

4.3 Типографика

4.3.1 Шрифты

• Основной шрифт:шрифт Interутверждается /в Montserratначале (указатьпроекта:
  — какойлибо именноиз побрендбука, проекту).если он существует;
  — либо выбирается дизайнером и согласуется с заказчиком до начала дизайна.

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

4.3.2 Стиль текста (Text Styles)

В Figma создаются текстовые стили для всех уровней иерархии: H1, H2, H3, Body, Caption и т. д.

ЧёткоеНазвания правилостилей использованиядолжны Bold/Medium/Regular.быть структурированы и информативны, например:
H1_Montserrat_B_64_21
где:
— шрифт,
— насыщенность,
— размер,
— line-height.

На всех макетах используется только стиль, никакой ручной типографики.

Изменения типографики в будущем делаются в одном месте — через обновление стиля.

4.3.3 Иерархия и насыщенность

Bold — ключевые заголовки и визуальные акценты.

Medium — структурные подзаголовки и ключевые UI-подписи.

Regular — основной текст, длинные параграфы, описания.

4.4 КомпонентыЦвета

4.4.1 Основная палитра

• Кнопки:Цветовая 3палитра размерадолжна (S,быть M,утверждена L).заранее:
  — из брендбука,
  — или согласуется как часть визуальной концепции.

• Формы:Определяются:
  — стандартныеосновные отступы,цвета
  — поля,акцентный
  — ошибки.фоновые
  — состояния (hover, active, disabled)

4.4.2 Color Styles

В Figma создаются цветовые стили:
Primary/Brand, Secondary, Accent, BG/Light, Error/Red и т. д.

Карточки:Все единыйэлементы паттерн.интерфейса используют только эти стили.

Если цвет меняется — обновление происходит в одном месте через стиль.

 

4.4.3 Градиенты и эффекты

Используются только если они согласованы как часть визуальной системы.

Градиенты, тени, размытия — тоже оформляются как отдельные стили эффектов.

4.5 ЦветаКомпоненты

4.5.1 Общие правила

• Палитра.Все повторяющиеся элементы упаковываются в компоненты.

• АкцентныйНикаких цвет.«одноразовых» копий — всё идёт в UI Kit.

• ДопустимыеКомпоненты градиенты.строятся через авто-лэйауты и используют стили типографики и цветов.

4.5.2 Состояния

Каждый компонент обязан иметь необходимые стейты:

Default

Hover

Active

Disabled

Focused
(если релевантно, может быть Loading / Error / Success)

 

4.5.3 Примеры компонентов

Кнопки — при необходимости размеры (S, M, L), обязательные состояния.

Формы — поля, подписи, хинты, ошибки, валидации, маски.

Карточки — единый паттерн построения, масштабируемая структура.

Элементы навигации — меню, пагинация, табы.

Иконки — единый стиль, единые размеры.

4.6 UI KIT

4.6.1 Структура и хранение

• ГдеUI хранится.Kit хранится в Figma Team Library, подключённой ко всем проектам, либо в рабочем проекте.

• КакКомпоненты обновляется.организуются по разделам:
  — Buttons
  — Forms
  — Navigation
  — Cards
  — Icons
  — Layout / Grid
  — Typography
  — Colors / Effects

4.6.2 Обновление

Все обновления выполняются централизованно дизайнером проекта.

КакиеИзменения компонентысопровождаются обязательны.комментариями при необходимости.

Никакие локальные копии компонентов в макетах не допускаются.

4.6.3 Использование

Все макеты собираются только из компонентов UI Kit.

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

---

5. Требования к верстке (Frontend Standards)

ПустьФронтенд-разработка Ильядолжна добавитбыть 5–10структурированной, правил:стандартизированной и основанной на утверждённом дизайне. Все правила ниже направлены на уменьшение количества правок, повышение стабильности и ускорение разработки.

---

5.1 Структура проекта и организация репозитория

Создание CORE-репозитория
Ведущий фронтендер создаёт базовое Git-хранилище (CORE), где размещаются:

основная структура проекта

базовые зависимости

настройки линтеров и форматтеров

глобальные темы (цвета, размеры, шрифты)

базовая архитектура модулей

единые UI-компоненты

Фиксация архитектурного подхода
До начала разработки команда фиксирует:

структуру директорий

логику именования компонентов

способ подключения стилей

принципы адаптива

оформление глобальных переменных (теминг, токены)

Разделение задач внутри команды

Один разработчик занимается версткой (UI), другой — логикой и бизнес-правилами, третий — интеграцией.

Или: один делает страницу А, другой — страницу Б.
Важно: разные разработчики не пересекаются в одних и тех же блоках, чтобы избежать конфликтов.

Сборка результата перед тестированием
После завершения задач ведущий фронтенд:

собирает работу команды в отдельную ветку (например feature/ui-assembly)

приводит код к единым стандартам

проверяет консистентность компонентов

отправляет версию на тестирование

5.2 Требования к стилям

Работа строго по дизайн-системе

Цвета, размеры, расстояния, шрифты — строго по UI Kit, без самодеятельности.

Никаких произвольных значений в стилях: каждый размер должен соответствовать токену дизайна.

Использование токенов (design tokens)
Все базовые параметры оформляются как переменные:

токены цветов

токены типографики

токены отступов

токены компонентов
Это исключает расхождения между дизайном и версткой.

Единая система отступов
Все spacing-значения берутся только из списка утверждённых размеров.
Никаких случайных значений типа 17px, 23px.
Если в дизайне 30px → значит 30px в коде.

Модульность и переиспользование

Каждый визуальный элемент должен быть оформлен как компонент.

Общие компоненты (кнопки, карточки, поля) находятся в CORE и не копируются локально.

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

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

Строго соблюдается сетка, выбранная в дизайне.

Разработчик не имеет права менять структуру блоков без согласования.

Пиксельная точность (Pixel-Perfect)

• Все размеры и расстояния должны соответствовать макету.

Допуск по отклонениям — rem/em,такой, некакой pxустановил дизайнер при передаче макетов (илиобычно наоборот,±10 px).

5.3 Работа с компонентами

Полное соответствие компонентам Figma
Если в UI Kit есть компонент — он должен быть использован.
Если нет — фронт обращается к дизайнеру для добавления.

Состояния элементов
Все состояния кнопок, полей, карточек должны быть реализованы так же, как выв решите)дизайне:

default

hover

active

disabled

focus

error (для форм)

Гибкость и масштабируемость
Компонент должен быть готов к:

изменению текста

изменению количества элементов

адаптиву

локализации

---

5.4 Кодовые стандарты

Линтеры обязательны (ESLint / Stylelint / Prettier) — ведущий фронт настраивает их в CORE.

Коммиты оформляются по единому стандарту (Conventional Commits или договорённый вариант).

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

НикакихКаждый “магическихPR чисел”должен проходить:

code review

проверку соответствия макету

проверку на совпадение с токенами дизайна

---

5.5 Требования к взаимодействию с дизайном

Фронт старается задать все вопросы до начала разработки, а не в процессе.

Если элемент кажется неполным — дизайнер обновляет UI Kit, а не разработчик «делает как кажется логичным».

СтилиЛюбые —расхождения черезмежду CSS-модули/Tailwindмакетом (указатьи вашверсткой подход).фиксируются.

МобильнаяПосле адаптациясборки обязательна.версии — проводится walkthrough с дизайнером.

Сетка должна совпадать с дизайнерской.

---

6. Коммуникации

Коротко:

• Дизайнер не ходит на все созвоны.созвоны

• Дизайнер подключается только на старт + прототип.прототип

• Все правки проходят через менеджера.менеджера

• Спорные моменты решает Артем.Артем

• Прямолинейная критика — через Артема, а не напрямую.напрямую

---

7. Уроки с проекта X (конкретика)

Это ключевая часть — ты сам просил.

Пусть Илья кратко перечислит:

• Какие именно ошибки были.

• Как он их исправил.

• Как избежать этого в будущем.

Пример:

1. Не было автолэйаута → верстка разваливалась.
   Решение: перешёл на структурный лэйаут.
   Как избегать: автолэйауты обязательны.

2. Цвета выбраны не по бренду → дисбаланс интерфейса.
   Решение: подобрал палитру из брендбука.
   Как избегать: всегда смотреть брендбук.

…и так далее.

---

8. Предложения по улучшению

Пусть он перечислит:

• что предложил внедрить сейчас,

• что можно сделать в ближайший месяц,

• что можно сделать позже (UI KIT, виджеты, конструктор форм).

---

9. V0.1 → Что будем добавлять дальше

Например:

• Стандарты анимаций.

• Стандарты текста.

• Стандарты иконок.

• Палитра состояния ошибок/валидаторов.

• Общий компонентный UI KIT Metarex.

---