# Методология # Методика разработки дизайна ## 1. Введение Процесс разработки дизайна для заказчика требует от специалиста не только владения инструментами и принципами визуальной коммуникации, но и умения выстраивать грамотное взаимодействие с клиентом. Главная задача дизайнера заключается в создании эстетически привлекательного и функционального продукта, который решает конкретные задачи бизнеса и пользователей. Для достижения этой цели дизайнер должен организовать рабочий процесс так, чтобы: - все ключевые решения фиксировались и согласовывались с заказчиком на ранних этапах; - коммуникация происходила напрямую, без посредников; - визуальные и функциональные решения имели обоснование с точки зрения пользовательского опыта и профессиональных стандартов. --- ## 2. Этап визуальной концепции (мудборды) ### 2.1. Назначение и значение этапа Мудборд (moodboard) — это инструмент визуализации стилистического направления проекта. Он представляет собой подборку изображений, шрифтов, цветовых сочетаний и композиционных решений, отражающих предполагаемое настроение и атмосферу будущего продукта. Создание мудборда необходимо для: - согласования визуального направления с заказчиком до начала детальной проработки макетов; - минимизации количества правок на последующих этапах; - формирования общего понимания эстетики проекта. Рекомендуемые материалы: - [Что такое мудборд — Яндекс.Практикум](https://practicum.yandex.ru/blog/chto-takoe-moodboard/) - [Мудборд — глоссарий Contented](https://media.contented.ru/glossary/mudbord/) ### 2.2. Практические рекомендации - Подготовьте несколько вариантов мудбордов, отражающих разные стилистические решения. - Обсудите и согласуйте выбранное направление напрямую с заказчиком. - После утверждения мудборда зафиксируйте его как основу визуальной концепции проекта. --- ## 3. Типографика Типографика определяет структуру и читаемость интерфейса. Правильный выбор шрифтов и их иерархия обеспечивают удобство восприятия информации пользователями. Рекомендуемые материалы: - [10 правил типографики в интерфейсах — Contented](https://media.contented.ru/opyt/instrukcii/10-pravil-tipografiki-v-interfejsah/) - [Типографика в веб-дизайне в цифрах — VC.ru](https://vc.ru/design/385060-tipografika-v-veb-dizaine-v-cifrah) ### Рекомендации: - Используйте не более двух-трёх шрифтовых пар в одном проекте. - Формируйте чёткую иерархию заголовков, подзаголовков и основного текста. - Проверяйте читаемость на различных разрешениях экранов. --- ## 4. Сетки и структурирование контента Сетка является основой композиционной организации макета. Она обеспечивает визуальный порядок и согласованность элементов. Рекомендуемые материалы: - [Сетки в веб-дизайне — VC.ru](https://vc.ru/design/1060731-setki-v-veb-dizaine) - [Сетки в веб-дизайне — Skedraw](https://blog.skedraw.ru/articles/setki-v-veb-dizajne) - [Пример сетки — Figma Community](https://www.figma.com/community/file/960115608622696069) ### Рекомендации: - Используйте модульные и колоночные сетки. - Соблюдайте пропорциональность и единообразие отступов. - Структура должна быть адаптивной для различных устройств. --- ## 5. Цветовое решение Цветовая палитра формирует эмоциональный отклик и визуальный баланс интерфейса. Цвет должен подбираться осознанно, с учётом целевой аудитории и контекста бренда. Рекомендуемые материалы: - [Цветовая палитра для сайта — Яндекс.Практикум](https://practicum.yandex.ru/blog/cvetovaya-palitra-dlya-sayta-kak-podobrat-cvet/) - [Цвет в веб-дизайне и его влияние — VC.ru](https://vc.ru/id1328489/538417-cvet-v-veb-dizaine-i-ego-vliyanie-na-celevuyu-auditoriyu) ### Рекомендации: - Используйте ограниченную палитру: 1–2 основных цвета и 1 акцентный. - Проверяйте контрастность и читаемость текста. - При наличии брендбука следуйте корпоративным цветовым стандартам. --- ## 6. Композиция Композиция определяет визуальный ритм, баланс и иерархию элементов интерфейса. Рекомендуемые материалы: - [Основы композиции в дизайне — Contented](https://media.contented.ru/znaniya/instrumenty/osnovy-kompoziczii-v-dizayne/) - [Основные правила композиции — Яндекс.Практикум](https://practicum.yandex.ru/blog/osnovnye-pravila-kompozitsii/) ### Рекомендации: - Используйте принципы визуального равновесия и акцентирования. - Избегайте перегруженности экрана второстепенными элементами. - Соблюдайте целостность восприятия интерфейса. --- ## 7. UI Kit (дизайн-система проекта) UI Kit — это систематизированный набор компонентов интерфейса (кнопки, поля ввода, карточки, иконки, стили текста и пр.), который обеспечивает единообразие визуальных решений. Рекомендуемые материалы: - [UI Kit — Яндекс.Практикум](https://practicum.yandex.ru/blog/ui-kit-chto-eto-i-zachem-nuzhen/) - [Глоссарий Contented: UI Kit](https://media.contented.ru/glossary/ui-kit/) - [UI Kits — Figma Community](https://www.figma.com/community/ui-kits) ### Рекомендации: - Создавайте компоненты со всеми необходимыми состояниями. - Настраивайте связь UI Kit с автолейаутами. - Используйте UI Kit как единый источник истины по стилю проекта. --- ## 8. Автолейауты Автолейаут (Auto Layout) — инструмент Figma, позволяющий создавать гибкие и адаптивные интерфейсы. Рекомендуемые материалы: - [Auto Layout в Figma — Contented](https://media.contented.ru/znaniya/instrumenty/auto-layout-figma/) - [Пример файла — Figma Community](https://www.figma.com/community/file/1106166785003688589) ### Рекомендации: - Используйте автоотступы и выравнивание для стабильности макета. - Комбинируйте автолейауты с компонентами и вариантами. - Применяйте для подготовки кликабельных прототипов. --- ## 9. Кликабельные прототипы Кликабельный прототип имитирует поведение готового продукта и позволяет наглядно продемонстрировать структуру и логику интерфейса заказчику. Рекомендуемый ресурс: - [Бесплатный курс по Figma — Tilda School](https://tilda.school/figma-free-course-0) ### Рекомендации: - Обязательно предоставляйте заказчику кликабельный прототип перед финальным утверждением. - Прототип помогает выявить UX-проблемы на раннем этапе. - Презентацию макета проводите лично, сопровождая её профессиональными комментариями. --- ## 10. Коммуникация с заказчиком ### 10.1. Прямое взаимодействие Дизайнер должен **всегда взаимодействовать с заказчиком напрямую**, а не через посредников (например, менеджеров без дизайнерской компетенции). Прямой контакт позволяет: - корректно понимать требования и контекст задач; - оперативно согласовывать решения; - минимизировать искажения при передаче информации. Отсутствие прямой коммуникации часто приводит к некорректным правкам и неверному пониманию целей проекта. --- ### 10.2. Работа с брендбуком Если у заказчика имеется **брендбук**, дизайнер обязан строго следовать указанным в нём правилам: - использовать утверждённые шрифты, цвета и логотипы; - соблюдать композиционные и визуальные принципы бренда. Если брендбук отсутствует, **недопустимо ориентироваться** на формулировки вроде «сделайте, как у нас на сайте». Существующий сайт может содержать устаревшие или некорректные решения, поэтому дизайнер должен опираться на профессиональные стандарты, принципы эргономики и визуальной гармонии. --- ### 10.3. Согласование и правки - Все ключевые визуальные и функциональные решения фиксируются и утверждаются на этапе дизайна. - После утверждения дизайн считается согласованным. Внесение изменений осуществляется **только при дополнительной оплате** или по технической необходимости. - Любые корректировки должны иметь обоснование, связанное с задачами продукта, а не субъективными предпочтениями заказчика. --- ## Заключение Методика разработки дизайна для заказчиков основана на профессиональной экспертизе, чёткой коммуникации и документировании решений. Дизайнер обязан выступать не исполнителем пожеланий, а экспертом, формирующим визуальную стратегию проекта. Только системный подход, прямой диалог с заказчиком и следование правилам визуальной организации позволяют создать эффективный и качественный продукт. # Стандарты Web UI 1. **Цель документа** Этот документ устанавливает единые стандарты работы над дизайном для заказчиков, чтобы минимизировать правки, повысить предсказуемость процесса и обеспечить стабильное качество результата. Он помогает команде говорить с клиентами на одном языке, быстрее согласовывать решения и формировать профессиональный подход к каждому проекту. --- ## 2. **Базовые принципы** - Все ключевые решения принимаются и фиксируются на этапе дизайна - Визуальное направление всегда согласуется через мудборды или по брендбуку до проработки макетов - При наличии брендбука строго соблюдаются его правила - Макеты строятся на сетках с продуманной структурой контента - Адаптивный дизайн делается только при наличии задачи/заказа на адаптив - Интерфейсы собираются из системных компонентов и UI Kit - Все макеты делаются на автолейаутах - Перед финальным утверждением заказчику всегда предоставляется прототип - Дизайнер сам представляет свой прототип заказчику - После утверждения дизайна любые изменения вносятся только при крайней необходимости (недоработки со стороны дизайнера, несоответствие логики и действий, критичные правки от заказчика) --- ## 3. **Процесс работы (Pipeline)** **Шаг 1. Получение задачи и всех материалов** - Менеджер формулирует ТЗ и передаёт дизайнеру весь контекст задачи и материалы полученные от заказчика **Шаг 2. Прототипирование** - Мудборд/брендбук - Расстановка элементов по сетке/правилам - Базовая логика переходов/реакций компонентов **Шаг 3. Согласование прототипа с менеджером и Art (Artem)** - Утверждаются ключевые элементы/логика/цвета/картинки **Шаг 4. Полноценный дизайн** - Работа с цветами - Типографика - Названия компонентов - UI-kit - Автолэйаут **Шаг 5. Передача дизайна фронту** - Дизайнер передаёт финальные макеты фронтенду вместе с необходимыми пояснениями: повторяющиеся блоки, компоненты, намеренные отступы, допустимые вариации. - Фронтенд проверяет дизайн и задаёт вопросы. Если обнаружены элементы, которые невозможно реализовать или реализация чрезмерно сложна, дизайн возвращается на доработку или обсуждается альтернативное решение, исходя из потребностей заказчика. **Шаг 6. Доработки на этапе интеграции** - Мелкие правки (коррекции цветов, шрифтов, иконок, изображений) принимаются без проблем - Крупные изменения (перестройка структуры, изменение расположения элементов, добавление новых блоков или новых версий макета) отклоняются, так как требуют значительного переработки дизайна и вёрстки. Масштабные правки согласуются отдельно и выполняются только при дополнительном бюджете и сроках --- ## 4. **Требования к дизайну (Design Standards)** ### 4.1 Сетка Сетка — основа композиции и структурирования контента. Она обеспечивает порядок, предсказуемость и согласованность элементов внутри макетов. Сетка должна быть **создана в Figma инструментом Layout Grid** и применена ко всем фреймам и страницам проекта. #### 4.1.1 Типы сеток В Figma используются 3 вида сеток: 1. **Column Grid (колонки)** Подходит для лендингов, сайтов, сложных интерфейсов, адаптивной верстки. Примеры использования: - 12 колонок с gutter 20–32 - 8 колонок для мобильных - 4 колонки для компактных блоков 2. **Row Grid (ряды)** Используется реже, но помогает выстроить строгий вертикальный ритм. 3. **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). [![image.png](https://docs.metabot24.ru/uploads/images/gallery/2025-11/scaled-1680-/dF7fI2QubxIYnzLl-image.png)](https://docs.metabot24.ru/uploads/images/gallery/2025-11/dF7fI2QubxIYnzLl-image.png) [![image.png](https://docs.metabot24.ru/uploads/images/gallery/2025-11/scaled-1680-/GJs2nhKZAKFzbkDO-image.png)](https://docs.metabot24.ru/uploads/images/gallery/2025-11/GJs2nhKZAKFzbkDO-image.png) ### 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 Шрифты - Основной шрифт утверждается в начале проекта: — **либо из брендбука**, если он существует; — либо выбирается дизайнером и **согласуется с заказчиком** до начала дизайна. - После утверждения шрифта весь проект использует **только его**, без самовольной подмены. #### 4.3.2 Стиль текста (Text Styles) - В Figma создаются **текстовые стили** для всех уровней иерархии: H1, H2, H3, Body, Caption и т. д. - Названия стилей должны быть структурированы и информативны, например: `H1_Montserrat_B_64_21` где: — шрифт, — насыщенность, — размер, — line-height. - На всех макетах используется **только стиль**, никакой ручной типографики. - Изменения типографики в будущем делаются в одном месте — через обновление стиля. [![image.png](https://docs.metabot24.ru/uploads/images/gallery/2025-11/scaled-1680-/6Lo1turdK6MMolEO-image.png)](https://docs.metabot24.ru/uploads/images/gallery/2025-11/6Lo1turdK6MMolEO-image.png) #### 4.3.3 Иерархия и насыщенность - Bold — ключевые заголовки и визуальные акценты. - Medium — структурные подзаголовки и ключевые UI-подписи. - Regular — основной текст, длинные параграфы, описания. ### 4.4 Цвета #### 4.4.1 Основная палитра - Цветовая палитра должна быть утверждена заранее: — из брендбука, — или согласуется как часть визуальной концепции. - Определяются: — основные цвета — акцентный — фоновые — состояния (hover, active, disabled) #### 4.4.2 Color Styles - В Figma создаются **цветовые стили**: `Primary/Brand`, `Secondary`, `Accent`, `BG/Light`, `Error/Red` и т. д. - Все элементы интерфейса используют только эти стили. - Если цвет меняется — обновление происходит в одном месте через стиль. [![image.png](https://docs.metabot24.ru/uploads/images/gallery/2025-11/scaled-1680-/JjW6zsqvliITbyOS-image.png)](https://docs.metabot24.ru/uploads/images/gallery/2025-11/JjW6zsqvliITbyOS-image.png) #### 4.4.3 Градиенты и эффекты - Используются только если они согласованы как часть визуальной системы. - Градиенты, тени, размытия — тоже оформляются как **отдельные стили эффектов**. ### 4.5 Компоненты #### 4.5.1 Общие правила - Все повторяющиеся элементы упаковываются в **компоненты**. - Никаких «одноразовых» копий — всё идёт в UI Kit. - Компоненты строятся через авто-лэйауты и используют стили типографики и цветов. #### 4.5.2 Состояния Каждый компонент обязан иметь необходимые стейты: - **Default** - **Hover** - **Active** - **Disabled** - **Focused** (если релевантно, может быть Loading / Error / Success) [![image.png](https://docs.metabot24.ru/uploads/images/gallery/2025-11/scaled-1680-/YaV9XguNcY2H2xsf-image.png)](https://docs.metabot24.ru/uploads/images/gallery/2025-11/YaV9XguNcY2H2xsf-image.png) [![image.png](https://docs.metabot24.ru/uploads/images/gallery/2025-11/scaled-1680-/ImmTlil2pUb81DOA-image.png)](https://docs.metabot24.ru/uploads/images/gallery/2025-11/ImmTlil2pUb81DOA-image.png) #### 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**. - Любой новый компонент сначала утверждается, затем добавляется в библиотеку. [![image.png](https://docs.metabot24.ru/uploads/images/gallery/2025-11/scaled-1680-/yVz1kykcoJ7XzqEK-image.png)](https://docs.metabot24.ru/uploads/images/gallery/2025-11/yVz1kykcoJ7XzqEK-image.png) --- ## 5. **Требования к верстке (Frontend Standards)** Фронтенд-разработка должна быть структурированной, стандартизированной и основанной на утверждённом дизайне. Все правила ниже направлены на уменьшение количества правок, повышение стабильности и ускорение разработки. --- #### 5.1 Структура проекта и организация репозитория 1. **Создание CORE-репозитория** Ведущий фронтендер создаёт базовое Git-хранилище (CORE), где размещаются: - основная структура проекта - базовые зависимости - настройки линтеров и форматтеров - глобальные темы (цвета, размеры, шрифты) - базовая архитектура модулей - единые UI-компоненты 2. **Фиксация архитектурного подхода** До начала разработки команда фиксирует: - структуру директорий - логику именования компонентов - способ подключения стилей - принципы адаптива - оформление глобальных переменных (теминг, токены) 3. **Разделение задач внутри команды** - Один разработчик занимается версткой (UI), другой — логикой и бизнес-правилами, третий — интеграцией. - Или: один делает страницу А, другой — страницу Б. Важно: разные разработчики **не пересекаются в одних и тех же блоках**, чтобы избежать конфликтов. 4. **Сборка результата перед тестированием** После завершения задач ведущий фронтенд: - собирает работу команды в отдельную ветку (например `feature/ui-assembly`) - приводит код к единым стандартам - проверяет консистентность компонентов - отправляет версию на тестирование #### 5.2 Требования к стилям 1. **Работа строго по дизайн-системе** - Цвета, размеры, расстояния, шрифты — **строго по UI Kit, без самодеятельности**. - Никаких произвольных значений в стилях: каждый размер должен соответствовать токену дизайна. 2. **Использование токенов (design tokens)** Все базовые параметры оформляются как переменные: - токены цветов - токены типографики - токены отступов - токены компонентов Это исключает расхождения между дизайном и версткой. 3. **Единая система отступов** Все spacing-значения берутся **только из списка утверждённых размеров**. Никаких случайных значений типа `17px`, `23px`. Если в дизайне 30px → значит 30px в коде. 4. **Модульность и переиспользование** - Каждый визуальный элемент должен быть оформлен как компонент. - Общие компоненты (кнопки, карточки, поля) находятся в CORE и не копируются локально. 5. **Адаптивность** - Используются те точки перелома, которые указаны в дизайн-системе. - Строго соблюдается сетка, выбранная в дизайне. - Разработчик не имеет права менять структуру блоков без согласования. 6. **Пиксельная точность (Pixel-Perfect)** - Все размеры и расстояния должны соответствовать макету. - Допуск по отклонениям — такой, какой установил дизайнер при передаче макетов (обычно ±10 px). #### 5.3 Работа с компонентами - **Полное соответствие компонентам Figma** Если в UI Kit есть компонент — он должен быть использован. Если нет — фронт обращается к дизайнеру для добавления. - **Состояния элементов** Все состояния кнопок, полей, карточек должны быть реализованы так же, как в дизайне: - default - hover - active - disabled - focus - error (для форм) - **Гибкость и масштабируемость** Компонент должен быть готов к: - изменению текста - изменению количества элементов - адаптиву - локализации --- #### 5.4 Кодовые стандарты 1. Линтеры обязательны (ESLint / Stylelint / Prettier) — ведущий фронт настраивает их в CORE. 2. Коммиты оформляются по единому стандарту (Conventional Commits или договорённый вариант). 3. Структура кода не должна зависеть от личных предпочтений каждого разработчика. 4. Каждый PR должен проходить: - code review - проверку соответствия макету - проверку на совпадение с токенами дизайна --- #### 5.5 Требования к взаимодействию с дизайном 1. Фронт старается задать все вопросы **до начала разработки**, а не в процессе. 2. Если элемент кажется неполным — дизайнер обновляет UI Kit, а не разработчик «делает как кажется логичным». 3. Любые расхождения между макетом и версткой фиксируются. 4. После сборки версии — проводится walkthrough с дизайнером. --- ## 6. **Коммуникации** Коротко: - Дизайнер не ходит на все созвоны - Дизайнер подключается только на старт + прототип - Все правки проходят через менеджера - Спорные моменты решает Артем - Прямолинейная критика — через Артема, а не напрямую --- ## 7. **V0.1 → Что будем добавлять дальше** Например: - Стандарты анимаций. - Стандарты текста. - Стандарты иконок. - Палитра состояния ошибок/валидаторов. - Общий компонентный UI KIT для всех проектов. --- # Типовые ошибки в дизайне интерфейсов при переходе от “рисования” к реальной UI/UX-разработке *(и как их избежать)* Когда дизайнер начинает работать не просто над красивыми картинками, а над настоящими интерфейсами (мини-аппы, формы, продукты, панели, CRM), всплывают типичные ошибки. Это не потому, что дизайнер “плохой”, а потому что **UI — это инженерная дисциплина, а не художественная**. Вот ключевые ошибки, которые совершают 90% начинающих дизайнеров — и рекомендации, как это исправить. --- #### 🔶 **Ошибка 1. “Картинка вместо системы”** Дизайнер делает интерфейс как постер в Photoshop: - ручные отступы, - элементы расставлены “на глаз”, - нет структуры, нет вложенности, - всё в одном слое, - блоки не связаны логически. #### Почему это плохо Такой дизайн невозможно: - адаптировать под разные экраны, - передавать фронтендеру, - масштабировать, - переиспользовать. #### Как правильно UI — не картинка, а **система элементов**: - каждый блок — контейнер, - внутри контейнера — логическая группа, - всё должно быть в единой архитектуре, - каждый элемент имеет своё место. #### ✔ Совет: Представляй интерфейс не как рисунок, а как **скелет + мышцы + кожа**. Сначала структура (скелет), потом функциональные группы (мышцы), потом визуал (кожа). --- ### 🔶 **Ошибка 2. Злоупотребление автолэйаутами (“20 контейнеров ради контейнеров”)** Новичок услышал “автолэйаут — это база” и начинает: - вкладывать блоки друг в друга без необходимости, - делать 10 уровней вложенности, - слепо wrap'ить всё, что видит, - использовать контейнеры не по логике, а “потому что надо”. #### Почему это плохо - структура становится нечитаемой, - фронтендеру страшно открывать макет, - невозможно понять, что адаптивно, а что статично, - всё “живёт собственной жизнью”. #### Как правильно Автолэйаут — не цель, а **инструмент**. Использовать его нужно: - когда элементы должны жить как группа, - когда блок должен масштабироваться, - когда есть логическая вертикаль/горизонталь, - когда UI строится как компонент. #### ✔ Совет: Если элемент не должен тянуться → **не делай его резиновым**. Если элемент не является логической группой → **не кладите его в контейнер**. --- ### 🔶 **Ошибка 3. Непонимание паттернов адаптивности** Новички делают: - фиксированные ширины, - вручную выставленные позиции, - нулевые минимальные и максимальные размеры, - текст, который не помещается при растяжении, - колонки, которые ломаются. #### Почему это плохо В реальном интерфейсе: - экраны бывают 320, 375, 414, 768, 1024, 1440, 1920… - UI должен жить на любом разрешении. #### Как правильно Задавать: - min-width / max-width, - фиксированные или резиновые контейнеры по назначению, - ограничение ширины текста, - грамотную поддержку “узкого”, “среднего” и “широкого” вида. #### ✔ Совет: Тестируй интерфейс в Figma: сожми фрейм → растяни → проверь, как ведут себя элементы. --- ### 🔶 **Ошибка 4. Отсутствие компонентного мышления** Новички делают: - каждый блок уникальным, - копируют элементы вручную, - вносят изменения в 15 мест одновременно, - не собирают UI KIT, - не используют компоненты. ### Почему это плохо - правки умножаются на количество копий, - дизайн не масштабируется, - фронт получает 100 вариаций одной и той же кнопки. ### Как правильно Мыслить **компонентами**: - кнопка - поле - карточка - модалка - теги - переключатели - и т.д. Все вариации — в **Variants**. #### ✔ Совет: Проектируй интерфейс так, будто его собирают в React — *из готовых компонентов*. --- #### 🔶 **Ошибка 5. Непонимание типографики** Типовые проблемы новичков: - 7–10 разных размеров текста, без логики, - смесь Regular / Medium / Bold в одном абзаце, - отсутствие иерархии заголовков, - большие расстояния между строками, - неправильный контраст. #### Как правильно - 3–4 уровня заголовков, - 1–2 вида параграфного текста, - единая иерархия, - строгая логика жирностей, - контраст согласно WCAG (или хотя бы визуальному здравому смыслу). #### ✔ Совет: Хорошая типографика = 70% ощущение “дорогого” интерфейса. --- ### 🔶 **Ошибка 6. Цвет как “интуиция”, а не система** Новички: - используют 10 оттенков синего, - берут цвета “на глаз”, - игнорируют брендбук, - смешивают пастель с кислотой, - нарушают контраст. #### Правильно - палитра: основной / вторичный / акцент / фон / текст - строгое использование, - никакой самодеятельности. #### ✔ Совет: Цвет = язык. Его нельзя менять “на вкус”. --- ### 🔶 **Ошибка 7. Ручные отступы vs система отступов** Новичок ставит: - 12px тут, - 14px там, - 17px снизу, - 9px сверху. И сам путается, фронтендер путается, всё плавает. #### Правильно Использовать единую сетку: 4pt / 8pt / 16pt — и никаких случайных чисел. #### ✔ Совет: Если отступ нельзя объяснить — он неправильный. --- ### 🔶 **Ошибка 8. Нет связи дизайнер ↔ фронтендер** Типично: - дизайнер думает “оно понятно”, - фронт открывает макет и видит хаос, - дизайнер не знает, что верстать сложно, - фронт не знает, что дизайнер хотел. #### Правильно 2 мини-связки: 1️⃣ Передача макета → дизайнер делает walkthrough: *“Вот компоненты, вот группы, вот отступы, вот логика адаптива.”* 2️⃣ Перед стартом верстки → фронтендер задаёт вопросы. #### ✔ Совет: UI — командная работа, не сольная. --- ### 🔶 **Ошибка 9. “На глазок” вместо UX** Новички принимают визуальные решения без понимания: - зачем элемент нужен, - какой сценарий он поддерживает, - какие у пользователя задачи, - что важно, что вторично. #### Правильно Каждому элементу нужен ответ: - какую проблему он решает? - зачем он здесь? - что пользователь должен сделать? - можно ли убрать это без потери смысла? #### ✔ Совет: UX начинается не в Figma, а в голове. --- ### 🔶 **Ошибка 10. Непонимание важности прототипа** Новички сразу рисуют дизайн, пропуская этап каркаса: несогласованная логика, невидимые ошибки, “симпатичная каша”. #### Правильно Сначала прототип (черно-белый), потом UI. #### ✔ Совет: Прототип — 80% успеха. --- ### 🟧 **Резюме: что нужно, чтобы перестать допускать эти ошибки** #### ✔ 1. Автолэйаут — да, но с головой Не везде и не “ради галочки”. #### ✔ 2. Компонентное мышление Думай как React-разработчик: системой. #### ✔ 3. Сетка и типографика Строгая дисциплина, минимум хаоса. #### ✔ 4. Прототип → дизайн → верстка Без прыжков через этапы. #### ✔ 5. Обратная связь от фронтендера Каждый макет должен пройти “технический осмотр”. #### ✔ 6. Менее “рисовать”, больше “проектировать” UI — это инженерия. #### ✔ 7. Постепенно: не революция, а эволюция Каждый проект — улучшение на 5–10%. # Тренды в UI/UX: перенос архитектуры на этап дизайна В данной публикации показан тренд куда движется UI/UX как индустрия. --- ### ✔ 1. Автолэйаут — это *перекладывание архитектурного мышления на дизайнера* Это ключевой момент. **Раньше**: дизайнер рисовал “красивую картинку” → фронтендер разбирал её мозгами, как умеет → получалось, как получится. **С автолэйаутами**: дизайнер *строит структуру*, аналогичную HTML/CSS: - контейнеры, - вложенность, - направление, - растягивание, - фиксированные/резиновые элементы, - ограничения (constraints), - поведение при resize. 👉 То есть дизайнер перестаёт быть “художником” и становится **архитектором интерфейса**. Это то, чему учат в сильных школах интерфейса. Это то, чего не хватает большинству новичков. --- ### ✔ 2. Figma эволюционирует в сторону “дизайн = полуверстка” Это важный тренд. Figma: - давно стала аналогом Flexbox/Grid; - уже экспортирует CSS для большинства компонентов; - умеет показывать DOM-структуру; - скоро будет делать полноценные прототипы с логикой; - уже внедряет Figma Dev Mode — почти окружение для фронта; - может экспортавать компонентные модели. Мир идёт к тому, что: > “Дизайн → почти готовая верстка”. --- ### ✔ 3. Продумывание архитектуры должно быть **на этапе дизайна**, а не на этапе разработки Это чистая истина. Есть золотое правило: > **Каждый час, потраченный дизайнером на архитектуру, экономит 3–5 часов разработки.** Поэтому автолэйаут: - уменьшает количество переделок на фронте, - уменьшает количество “а давайте поправим на глазок”, - уменьшает “случайные пиксели”, - избавляет от “вёрстка развалилась на 375px”. --- ### ✔ 4. Эта культура делает дизайнеров сильнее Дизайнер, который: - думает вложенностью, - понимает контентные блоки, - чувствует адаптивность, - видит где фикс, а где резина, - знает, что такое baseline grid, - понимает продуктовую логику, - делает прототипы, устойчивые к масштабированию, — это уже не “рисуем-как-чувствуем”. Это уже **UI/UX-специалист уровня компании**. Это стратегически правильно. --- ### ✔ 5. В будущем часть разработки будет делаться автоматически Уже сейчас: - Figma Plugins экспортируют React компоненты, Tailwind классы, HTML/CSS. - Locofy, Anima, Relume → генерируют рабочую верстку из Figma. - Vercel AI + Figma → создают JSX из макетов. - Figma Dev Mode → уже показывает почти готовые фрагменты кода. Через 2–3 года: > **“Макет → код” станет обычной практикой. > А разработчики будут дорабатывать только логику и интеграции.** Это направление всей индустрии. --- ### ✔ 6. А теперь ключевое: ### Автолэйаут — это НЕ про “делать всё правильно”. ### Это про **движение команды к будущему**, где дизайн = система. Важно строить систему: - стандарты, - UI KIT, - автолэйауты, - компоненты, - мини-конструктор виджетов, - Web UI-платформу, - возможность автоматической генерации UI, - построение интерфейсов “из коробки”, → это полностью совпадает с трендами. Но: 👉 Если команда НЕ ГОТОВА пересесть на это сразу. Нужно: - вести команду правильно, - не ломать людей, - вводить стандарты итеративно, - не создавать конфликтов, - не делать резких переходов. --- ### ✔ 8. Сложно ли этому научиться? #### Для нормального дизайнера: 🔹 Базовый автолэйаут — 1 день 🔹 Уверенная работа — 3–5 дней 🔹 Грамотные сложные структуры — 2–3 недели 🔹 Полное мышление “как фронтендер” — 1–2 месяца Это реализуемо. Только нужно: - обучающий модуль, - маленькие упражнения, - разбор ошибок, - примеры из проектов. # Как понимать контекст проекта Этот материал объясняет: - разницу типов проектов, - что такое mission critical / non-mission-critical, - когда дизайнер должен общаться с заказчиком, - а когда избыток коммуникаций — во вред, - как отличается клиентский опыт в продуктах и в мини-апах, - как всё это классифицировать, - как команда может ориентироваться в этих режимах и не путать одно с другим. --- ### 🟧 **Два мира разработки: продукты vs мини-аппы. Как отличать, как работать и какие процессы нужны** Мы сталкиваемся с разными типами проектов. Где-то мы делаем полноценный продукт, который живёт годами, влияет на бизнес-процессы и проходит десятки согласований. А где-то — небольшой мини-апп, простой инструмент или небольшую коммуникационную вставку внутри чат-бота. Чтобы команда работала эффективно и не пыталась применить “тяжёлые” процессы там, где они только мешают, важно понимать фундаментальную разницу между **двумя классами проектов**: - **Полноценные продукты / Mission Critical** - **Мини-аппы и поддерживающие интерфейсы / Non-Mission-Critical** Это два разных мира, требующих двух разных подходов — в дизайне, разработке, коммуникациях и управлении ожиданиями. --- ### 🟧 1. Что такое Mission Critical, и почему эти проекты другие **Mission Critical** — это продукты, без которых бизнес не сможет выполнять свою основную функцию. Примеры: - Яндекс.Такси — приложение не работает → такси не существует - Интернет-банк — ошибка → бизнес клиента остановился - Личный кабинет госуслуг → критичен для доступа к услугам - Управляющая панель в промышленности (логистика, производство, расчёты) У промышленной компании, например фармацевтической, mission critical — это производство таблеток, логистика, ERP, склад, документоборот. **Чат-боты, мини-формы, калькуляторы, маркетинговые инструменты — не mission critical.** Их можно улучшать, допиливать, полировать, но они не остановят бизнес. #### Отличительные признаки Mission Critical: - UI = бизнес-операция, ошибка стоит дорого - требуется глубокая выверенная архитектура - десятки согласований - UX-исследования - строгая типографика, модульные сетки, дизайн-системы - дизайнер обязан общаться напрямую с заказчиком - множество рабочих встреч - нужно понимать роли, сценарии, ограничения - всё должно быть документировано - много уровней ответственности Там нет “примерно нормально” — там только **идеально и надёжно**. --- ### 🟧 2. Что такое Non-Mission-Critical (наши текущие мини-аппы) Мини-аппы, калькуляторы, формы, промо-страницы, быстрые B2B-калькуляторы в мессенджерах — это **дополняющие** интерфейсы. Они помогают: - сократить путь пользователя, - поддержать маркетинг, - объяснить продукт, - загрузить данные, - собрать обратную связь. Но **не являются ядром бизнеса**. #### Отличительные признаки таких проектов: - одна или две встречи достаточно - можно опираться на вкус и здравый смысл - нет 50 согласований - нет десятков UX-сценариев - проще требования к цветам, сетке, блокам - допускаются разумные компромиссы - UI — не синоним бизнес-операции, а инструмент коммуникации Это не значит “делать плохо”, это значит **не переусложнять там, где это не нужно**. --- ### 🟧 3. Почему процессы должны быть разными Если на non-mission-critical проекты натянуть процессы от больших продуктовых студий, произойдёт следующее: - сроки вырастут x3–5 - стоимость выйдет за рамки бюджета - ценность UI станет ниже цены его производства - клиент удивится, почему такие простые задачи делаются так дорого - команда будет перегружена ненужными встречами - дизайнеры будут ловить лишние правки и вкусовщину - фронтендеры погрязнут в овердизайне Но если на mission critical проект натянуть подход “как для мини-аппа” — бизнес словит катастрофу. Поэтому нужен **двухрежимный подход**. --- ### 🟧 4. Должен ли дизайнер встречаться с заказчиком? Да — но не всегда. ### Два типа проектов = два типа участия дизайнера. #### 🟩 **Тип 1. Полноценные продукты — дизайнер участвует активно** Тут дизайнер — не художник и не исполнитель. Он — **аналитик**, **переговорщик**, **продуктовый партнёр**. Его обязанности: - собирать требования - уточнять задачи - выяснять сценарии - согласовывать логику - прототипировать - решать UX-проблемы - участвовать в созвонах - защищать решения с цифрами и логикой Без прямой коммуникации тут работать невозможно. --- #### 🟦 **Тип 2. Мини-аппы — дизайнеру достаточно 1-2 встречи** В этих проектах: - нет сложной логики, - нет рискованных пользовательских сценариев, - нет десятков ролей и use-case'ов, - нет mission critical-функций, - интерфейс не решает судьбу компании. Поэтому дизайнеру достаточно: - 1 вводной встречи, - 1 обсуждения прототипа, - остальная коммуникация — через менеджера. Прямой контакт с клиентом после этого **ничего не улучшит, а часто только ухудшит**: - начинается вкусовщина, - “попробуйте зелёный”, - “давайте кнопку побольше”, - “а сделайте фон потемнее”, - дизайнер теряет фокус, - дизайн разваливается, - сроки растут. Дизайнер защищает эстетику и логику → Менеджер фильтрует запросы → Команда работает спокойно. Это правильный процесс. --- ### 🟧 5. Разные типы клиентского опыта (CX): “деловой” vs “приятный” Чтобы правильно строить интерфейсы, важно понимать разницу между двумя видами клиентского опыта. #### 🟩 Тип 1. “Деловой” клиентский опыт (B2B, сервисный, утилитарный) Цель: **дать результат быстро, чётко и без лишних действий.** Примеры: - B2B калькуляторы - формы заказа - заявки - рабочие панели - кабинки операторов - функциональные мини-аппы Тут интерфейс должен быть: - быстрым - простым - прямым - без флейвора - без украшательств - минимум шагов - минимум когнитивной нагрузки Это “инструмент”, а не “впечатление”. --- #### 🟦 Тип 2. “Приятный” клиентский опыт (развлечения / эмоции / smacking experience) Цель: **вовлечь, развлечь, удержать внимание.** Примеры: - рестораны, еда, сервис, доставка - игры - развлекательные проекты - брендинг - storytelling-интерфейсы Здесь можно: - растягивать путь, - играть с эмоцией, - добавлять анимации, - давать “вкус” и “медленность”, - делать journey красивым. --- ### 🟧 6. Как классифицировать проект за 1 минуту Задаём два вопроса: #### ❓ Если интерфейс сломается — пострадает ли основная миссия бизнеса? Если **да** → это mission critical → полноценный продуктовый процесс. Если **нет** → это мини-апп → упрощённый процесс. --- ### 🟧 7. Что важно 1. **Не надо натягивать продуктовые процессы на мини-аппы.** Это убивает скорость и ценность проекта. 2. **Не надо упрощать миссион-критичные проекты.** Там нужна глубина. 3. **Дизайнер не должен общаться с заказчиком там, где это во вред.** Коммуникация — ресурс, его надо дозировать. 4. **Нужно уметь классифицировать тип задачи с первых минут проекта.** 5. **Наша цель — гибкость.** Мы должны одинаково уверенно вести оба типа проектов. --- ### 🟧 8. Тонкое различие, которое важно осознать **Мы не “студия, которая делает всё одинаково”.** Мы команда, которая умеет **менять подход под контекст**. Где-то нужен продуктовый UX, десятки встреч и прототипы. Где-то достаточно одного звонка, одного прототипа и менеджерского фильтра. Зрелость = умение различать.