Этапы проектирования интерфейса: 5 шагов к удобному UX

Уходит к конкуренту, а команда потом открывает Figma и долго двигает карточки на два пикселя.

Так выглядит плохое проектирование интерфейса: визуально всё собрано, компоненты названы по BEM, макеты разложены по страницам, а сценарий пользователя не работает. UI есть. UX отсутствует. Костыль аккуратно задеплоен.

Процесс проектирования интерфейсов обычно разбивают на пять этапов: исследование, построение сценариев и архитектуры, вайрфрейминг, UI-дизайн, тестирование и передача в разработку. Это не ГОСТ и не религия. В одной студии этапы объединяют, в другой дробят на шесть подпроцессов. Но логика остаётся той же: сначала понять задачу, затем описать поведение системы, после этого рисовать поверхность.

Фундамент продукта: исследование и анализ бизнес-целей

Первый этап проектирования интерфейса часто пытаются пропустить. Заказчик уже показал референс. Продакт уже сказал, что нужен «современный личный кабинет». Разработчик уже поднял React-приложение. Осталось только подобрать шрифт и добавить плавное появление модального окна.

Это сценарий, в котором проблемы обнаруживаются не на исследовании, а в проде. Логи бесполезны: сервер отвечает 200 OK, база не горит, метрики зелёные. Пользователь всё равно не завершает действие. Система формально исправна. Продукт — нет.

Исследование нужно не ради красивого отчёта. Его задача — зафиксировать, кто пользуется интерфейсом, какую задачу решает и в каких условиях это происходит. Для этого изучают:

• бизнес-цели продукта: продажа, активация, оформление заявки, снижение нагрузки на поддержку или удержание пользователя;
• целевые группы и их различия;
• текущие сценарии и точки отказа;
• существующую аналитику, обращения в поддержку и результаты опросов;
• конкурентов и привычные для аудитории паттерны;
• технические и контентные ограничения.

У одного сервиса может быть несколько аудиторий с разными требованиями. Новичку нужен подробный маршрут и понятные подсказки. Опытному пользователю — скорость и возможность обходить очевидные шаги. Если дать обоим один интерфейс, получится компромисс: новичок потеряется, опытный начнёт искать горячие клавиши, а дизайнер назовёт это универсальностью.

Что именно выясняется на старте

Исследование не обязано превращаться в многонедельную экспедицию с десятками интервью. Но вопросы должны быть конкретными. Не «нравится ли вам наш сайт», а:

1. Как пользователь приходит к задаче?

2. Что он считает успешным результатом?

3. Какие данные у него уже есть?

4. На каком шаге он сомневается или прерывается?

5. Что произойдёт, если он ошибётся?

6. Какую информацию интерфейс обязан показать до действия?

7. Какие ограничения есть у бизнеса и разработки?

Ответы переводятся в рабочие артефакты: персоны, пользовательские сценарии, карту проблем, список задач и ограничений. Здесь уже можно понять, что именно требуется проектировать. Иногда выясняется, что проблема не в интерфейсе, а в тарифной логике, структуре продукта или непонятном контенте. Рисовать ещё одну кнопку в такой ситуации — примерно как чинить сетевой кабель перезапуском базы данных.

Полезно разделять требования на три слоя:

Последний пункт особенно часто появляется слишком поздно. Команда сначала утверждает красивый интерфейс, а потом узнаёт, что в API нет данных для нужного состояния. Скелет пользовательского сценария уже сломан, но в Figma всё выглядит убедительно.

Хороший интерфейс начинается не с фрейма в Figma. Он начинается с ответа на вопрос: какое действие пользователь должен выполнить и почему система вообще имеет право его усложнять.

Архитектура взаимодействия: CJM и логические сценарии

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

Для этого используют CJM — Customer Journey Map, карту пути пользователя. Она показывает последовательность действий, ожидания, вопросы и точки контакта с продуктом. Для сложных сервисов дополнительно строят информационную архитектуру: какие разделы существуют, как они связаны, где находится нужная функция и какие данные нужны на каждом шаге.

От задачи к сценарию

Сценарий лучше описывать не формулировкой «пользователь открывает страницу профиля», а через намерение:

• пользователь хочет изменить платёжные данные;
• система должна показать текущий статус и ограничения;
• пользователь вводит новые данные;
• интерфейс валидирует поля;
• система подтверждает операцию;
• пользователь понимает, что изменения применились.

В такой записи сразу видны состояния, которые обычно забывают при отрисовке главного экрана:

• загрузка;
• пустой результат;
• ошибка сети;
• ошибка валидации;
• недостаток прав;
• конфликт данных;
• успешное завершение;
• повторное действие;
• отмена операции.

В макете часто есть только happy path. В проде happy path занимает примерно ту же долю, что и идеальный кабель-менеджмент в серверной. Остальное приходится проектировать отдельно.

Архитектура как защита от интерфейсного хаоса

Информационная архитектура определяет, как пользователь находит сущности и функции. Если разделы названы языком внутренней оргструктуры компании, интерфейс начинает требовать от человека изучить устройство бизнеса. Пользователю не нужно знать, что «операционный контур» внутри продукта отвечает за документы. Ему нужно найти документы.

При проектировании архитектуры полезно фиксировать:

• какие сущности являются основными;
• какие действия доступны для каждой сущности;
• какие роли имеют доступ к этим действиям;
• где пользователь увидит результат операции;
• какие действия обратимы;
• где нужны подтверждение и предупреждение;
• какие данные должны быть доступны без перехода на отдельный экран.

Отдельно проверяют навигацию. Один и тот же объект может быть доступен через меню, поиск, уведомление и список последних действий. Это не проблема само по себе. Проблема начинается, когда каждый маршрут ведёт в разный вариант сущности и показывает разные действия.

Модель пяти уровней UX

Традиционная модель Джесси Гарретта описывает UX через пять уровней:

1. Стратегия — цели бизнеса и потребности пользователя.

2. Возможности — функции и контент, которые должен предоставить продукт.

3. Структура — логика взаимодействия и организация информации.

4. Компоновка — расположение элементов на экране.

5. Поверхность — визуальный слой: цвет, типографика, изображения и детали интерфейса.

Модель полезна не тем, что заставляет команду пройти ровно пять церемоний. Она показывает зависимость уровней. Нельзя качественно настроить поверхность, если неизвестна структура. Нельзя выбрать структуру, если продукт не определил возможности. А выбор цвета до определения задачи — не ранний этап дизайна. Это просто попытка создать видимость прогресса.

Вайрфрейминг и прототипирование: проверка гипотез до вёрстки

Вайрфрейм — это не «серый макет, который потом станет красивым». Это инструмент проверки логики. В нём намеренно мало декоративных решений, чтобы команда не спорила о радиусе карточки вместо обсуждения сценария.

На этом этапе определяют:

• состав экранов;
• порядок блоков;
• структуру навигации;
• расположение ключевых действий;
• связи между состояниями;
• приоритет контента;
• поведение форм и ошибок;
• переходы между шагами.

Вайрфреймы могут быть низкой детализации — быстрыми схемами для проверки идеи — или более подробными, если нужно согласовать сложный сценарий. Здесь нет смысла рано фиксировать финальную графику. Она создаёт ложную уверенность: раз экран уже похож на продукт, значит, продукт почти готов. Нет. Пока это только UI-обёртка над гипотезой.

Прототип должен ломаться

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

• открыть нужный раздел;
• найти объект;
• изменить данные;
• ошибиться в поле;
• вернуться назад;
• отменить действие;
• понять результат.

Если прототип нельзя нормально использовать, это не трагедия. Наоборот. Хорошо, что проблема обнаружилась до верстки, адаптива, интеграции с API и ночного сообщения в общем чате.

Практика с 3–5 черновыми прототипами позволяет выявить логические ошибки до написания кода. Речь не о пяти полностью готовых версиях продукта. Это могут быть разные варианты одного сценария: с пошаговой формой, с одним длинным экраном, с боковой панелью или с контекстным действием в таблице.

Сравнивать следует не эстетическую привлекательность, а поведение:

Прототипирование не отменяет техническую проверку. Если сценарий зависит от внешнего сервиса, статуса платежа или долгой фоновой операции, на макете должны появиться соответствующие состояния. Нельзя показывать моментальный успех для операции, которая в реальности выполняется сорок секунд. Иначе разработка потом будет выбирать между ложным интерфейсом и костылём с бесконечным спиннером.

Что тестируют уже на вайрфрейме

На раннем прототипе проверяют не пиксели. Проверяют:

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

Тексты тоже тестируют. Заголовок «Настройки» ничего не объясняет, если внутри находятся управление доступом, биллинг и удаление аккаунта. Название должно помогать выбрать действие, а не соответствовать структуре меню в старом корпоративном портале.

Визуальный слой: UI-кит, типографика и микровзаимодействия

Когда логика сценариев выдержала проверку, появляется смысл заниматься UI. Здесь UX и UI наконец встречаются, но не сливаются в одно мутное слово.

UX отвечает за логику, структуру, пользовательский опыт и сценарии. UI отвечает за визуальную презентацию: цвета, шрифты, иконки, состояния компонентов, микровзаимодействия и композицию. Удобная форма может выглядеть скучно. Красивый экран может быть полностью бесполезен. Оба утверждения не противоречат друг другу.

UI-кит как контракт, а не коллекция скриншотов

UI-кит фиксирует повторяемые элементы интерфейса:

• кнопки и их состояния;
• поля ввода;
• чекбоксы, переключатели и селекты;
• таблицы и списки;
• уведомления;
• модальные окна;
• вкладки;
• навигацию;
• типографическую шкалу;
• цвета и токены;
• отступы и сетку.

Если компонент существует только на одном экране, это ещё не дизайн-система. Это локальная договорённость. Дизайн-система начинается там, где правила можно повторно использовать и передать разработке без археологических раскопок в слоях Figma.

У компонента должны быть состояния. Для кнопки это не только default и hover, но и:

• disabled;
• loading;
• focus;
• success;
• destructive action;
• состояние ошибки рядом с результатом действия.

Для поля ввода важны пустое состояние, фокус, введённое значение, ошибка, подсказка, недоступность и длинный текст. Если этих вариантов нет в библиотеке, они появятся в коде самостоятельно. Каждый разработчик соберёт собственный вариант. Потом команда назовёт это «небольшим расхождением».

Типографика — часть интерфейсной логики

Типографика определяет не только настроение. Она задаёт иерархию информации, скорость сканирования и плотность экрана. Для интерфейса с таблицами, фильтрами и формами особенно важны:

• различимость уровней заголовков;
• читаемый размер основного текста;
• достаточная высота строки;
• заметная разница между меткой, значением и подсказкой;
• предсказуемая длина строк;
• корректное поведение на узких экранах;
• поддержка нужных начертаний и кириллицы.

Шрифт нельзя выбирать только по красивому заголовку на первом экране. Нужно проверить цифры, длинные русские слова, даты, валюты, табличные данные и сообщения об ошибках. В интерфейсе пользователь видит не рекламный слоган, а «Платёж не прошёл: проверьте реквизиты и повторите попытку». Если шрифт разваливается на этом сообщении, проблема уже не эстетическая.

Микровзаимодействия без цирка

Анимация должна объяснять изменение состояния. Она может показать, что карточка открылась, операция выполняется, элемент переместился или уведомление относится к предыдущему действию. Но если интерфейс анимирует каждый чих, пользователь получает не обратную связь, а визуальный шум.

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

• что произошло;
• где находится результат;
• можно ли отменить действие;
• сколько примерно ждать;
• завершилась ли операция;
• почему элемент изменил вид.

Пять параллакс-слоёв не компенсируют отсутствие сообщения об ошибке. Это просто дорогой спиннер.

Финальное тестирование и передача макетов в разработку

Тестирование — не финальная проверка, когда всё уже нарисовано и осталось поставить галочку. Оно начинается раньше, но на финальном этапе команда проверяет целостность интерфейса: сценарии, состояния, тексты, адаптивность и соответствие технической реализации.

Пользовательское тестирование можно проводить на интерактивном прототипе. Участнику дают задачу, а не инструкцию по кликам. Не «нажмите на раздел Профиль», а «измените данные для получения уведомлений». Иначе исследователь проверяет не интерфейс, а способность человека выполнять команды.

Как читать результаты тестирования

Одна ошибка пользователя ещё не означает, что весь экран нужно выбросить. Но повторяющийся сбой в одном месте — сигнал. Анализируют:

• где участник начал искать решение;
• какую формулировку он использовал;
• что ожидал увидеть;
• какое действие выбрал;
• где остановился;
• понял ли результат;
• мог ли восстановиться после ошибки.

Нельзя подсказывать пользователю, а потом записывать прохождение как успешное. Это тот же подход, что проверять отказоустойчивость, вручную перезапуская сервис за мониторингом. Формально система жива. Проверка бесполезна.

Тестировать нужно не только основной сценарий. В реальном интерфейсе есть медленное соединение, пустая база, длинные имена, несколько ролей, отсутствие прав, повторное нажатие, устаревшие данные и ошибка внешнего сервиса. Если макет знает только состояние «всё хорошо», он не готов к разработке.

Передача в разработку

Передача макетов — это не экспорт PNG и сообщение «если что, спрашивайте». Разработчику нужны правила поведения, а не только координаты объектов.

Минимальный комплект включает:

• финальные экраны и интерактивные связи;
• UI-библиотеку с компонентами;
• состояния элементов;
• адаптивные варианты;
• описание переходов;
• тексты ошибок и системных сообщений;
• требования к валидации;
• ограничения по контенту;
• приоритеты для мобильных и десктопных экранов;
• связь макетов с задачами в трекере.

Хорошая передача отвечает на вопрос: что должно произойти, если пользователь сделал не то, что ожидал дизайнер? Если ответа нет, его напишут в коде. Обычно поздно. Обычно в пятницу.

Полезно заранее разделить ответственность. Дизайнер не должен придумывать поведение API, а разработчик — молча угадывать UX-логику. На стыке должны быть зафиксированы:

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

После реализации нужен короткий дизайн-QA. Проверяют не только соответствие отступов, но и смысл: правильный ли порядок действий, видны ли ошибки, не пропали ли состояния, совпадают ли тексты, не превращается ли сложный сценарий в бесконечный loader.

Как пять этапов превращаются в рабочий цикл

Последовательность нужна, но линейной разработка интерфейса не бывает. Тестирование может вернуть команду к архитектуре. Техническая проверка может изменить прототип. Новые данные от пользователей могут заставить пересобрать бизнес-сценарий. Это не провал процесса. Провал — продолжать рисовать по первоначальному ТЗ после того, как выяснилось, что оно описывает не ту задачу.

Практический процесс проектирования UX/UI можно собрать в такой цикл:

1. Зафиксировать задачу. Определить цель бизнеса, пользовательскую проблему и ограничения.

2. Описать аудиторию и контекст. Понять, кто выполняет действие, с какого устройства и с каким уровнем подготовки.

3. Собрать сценарии. Разложить путь на действия, решения, ошибки и результаты.

4. Проверить архитектуру. Убедиться, что нужные функции и данные находятся там, где их ищут.

5. Собрать несколько прототипов. Проверить варианты до визуальной детализации и верстки.

6. Провести тестирование. Найти места, где пользователь останавливается, ошибается или неверно понимает результат.

7. Собрать UI-слой. Зафиксировать компоненты, типографику, цвета, состояния и адаптивность.

8. Передать реализацию без белых пятен. Описать поведение, ошибки, ограничения и данные.

9. Проверить готовый интерфейс. Сверить не только пиксели, но и реальные сценарии.

Figma остаётся стандартным инструментом для вайрфреймов, интерактивных прототипов и библиотек UI-компонентов. Но инструмент не исправляет процесс. В Figma можно одинаково быстро собрать понятный сценарий и очень красивую катастрофу.

Главный артефакт UX — не макет. Это предсказуемое поведение продукта в момент, когда пользователь ошибся.

Что обычно ломается в процессе

Есть несколько повторяющихся причин, по которым этапы разработки UI/UX проходят формально.

UI начинают раньше исследования

Команда выбирает визуальный стиль, собирает первый экран и уже потом пытается понять, кому он нужен. В результате интерфейс оптимизируют под презентацию, а не под задачу. Исправлять это на готовом UI дорого: каждый новый вывод затрагивает сетку, контент, компоненты и вёрстку.

Сценарий заменяют набором экранов

Десять макетов не равны одному рабочему потоку. Можно нарисовать страницу списка, карточку и модальное окно, но не показать, что происходит после ошибки сохранения. Такой проект выглядит завершённым только в режиме просмотра.

Не проектируют пограничные состояния

Пустые списки, длинные тексты, плохая сеть и отсутствие прав не являются экзотикой. Это базовая среда эксплуатации. Если она не отражена в макетах, разработка всё равно её встретит. Просто уже без дизайнера.

UI-кит собирают после разработки

Это приводит к расхождениям: разные отступы, разные размеры кнопок, несколько вариантов одного статуса. Потом запускается миграция компонентов, которая называется «быстро привести всё к единому виду». Костыль, размноженный на весь продукт.

Тестирование превращают в согласование

Если на тестировании участнику объясняют, куда смотреть и что нажимать, команда проверяет сценарий презентации. Настоящая проверка начинается там, где пользователь должен сам понять, как решить задачу.

Итог: интерфейс проектируют до того, как его начинают украшать

Пять этапов проектирования интерфейса — это не обязательный набор слайдов для отчёта. Это порядок снижения риска.

Исследование отвечает, какую проблему решает продукт. Архитектура показывает, как пользователь доходит до результата. Вайрфрейминг проверяет логику без декоративного шума. UI превращает проверенную структуру в цельную систему. Тестирование ловит ошибки до того, как они попадут в код и аналитику.

Если перепутать порядок, получится знакомая инженерная история: сначала собрали красивую оболочку, потом обнаружили отсутствие данных, затем добавили временное решение, после чего временное решение стало частью архитектуры. Через год его никто не трогает, потому что «там всё завязано».

Перед отправкой макетов в разработку полезно выполнить хотя бы такой минимальный ритуал:

• git status — проверить, что в проекте нет случайного мусора и незакоммиченных изменений;
• git diff — посмотреть, что именно уйдёт в реализацию, а не надеяться на память;
• npm test — убедиться, что базовые проверки проходят;
• npm run lint — не отправлять в репозиторий код, собранный из копипаста;
• git commit -m "ui: finalize user flow" — зафиксировать состояние перед дальнейшими правками;
• git push — отправить изменения в удалённый репозиторий;
• резервная копия макетов, токенов и текстов — потому что Figma тоже не является стратегией бэкапа.

Дизайн, как и прод, не прощает отсутствия планов восстановления. Сначала сценарий. Потом интерфейс. Потом код. В обратном порядке обычно получается только дорогое объяснение, почему пользователи опять нажимают не туда.