UX и UI разводят по разным ролям почти в каждой вакансии и почти в каждом коммерческом предложении, но на практике граница размыта: в небольшой команде оба слоя делает один человек. Путаница мешает не терминологически, а по делу — когда заказчик просит «поправить UI», имея в виду, что из корзины уходят без заказа, или когда дизайнер отрисовывает аккуратные экраны для сценария, которого у пользователей нет. Разбираем, чем на самом деле отличаются эти два слоя работы, что дает каждый и в каком порядке мы их делаем.
Разные вопросы к одному экрану
Проще всего запомнить так: UX отвечает на вопрос «что здесь должно происходить и в каком порядке», UI — «как это выглядит и как реагирует». Один и тот же экран оформления заказа можно оценивать с двух сторон.
- Вопросы UX: сколько шагов до оплаты, что спрашиваем и зачем, что происходит при ошибке, можно ли вернуться назад без потери данных, нужна ли вообще регистрация.
- Вопросы UI: какой кегль у подписей полей, как выглядит поле в фокусе и с ошибкой, куда падает взгляд первым, видно ли активную кнопку на мобильном.
Оба слоя нужны, но они не взаимозаменяемы. Аккуратно оформленная форма из двенадцати обязательных полей останется формой из двенадцати обязательных полей. И наоборот: короткий продуманный сценарий с нечитаемым контрастом и незаметной кнопкой тоже не сработает.
Что входит в UX-часть
UX — это работа с задачей пользователя и структурой. На проекте она обычно выглядит так.
- Разбор задачи и данных. Смотрим, зачем люди приходят на сайт и что уже происходит в аналитике: с каких страниц уходят, где обрываются формы, что ищут внутренним поиском.
- Сценарии. Описываем несколько типовых путей: «пришел с поиска на карточку услуги и хочет цену», «зашел из закладок повторить заказ», «пришел с рекламы и не знает компанию». У них разные требования к первому экрану.
- Структура и навигация. Какие разделы есть, как они называются словами клиентов, а не внутренним жаргоном, что попадает в главное меню, а что в подвал.
- Информационная структура страницы. Порядок блоков: что человек должен узнать первым, чем закрываются его возражения, где стоит призыв к действию.
- Прототип. Схематичные экраны без цвета и фотографий: прямоугольники, настоящие заголовки, настоящие подписи кнопок. На них видна логика, и на этом этапе правки стоят дешево.
- Проверка. Показываем прототип людям из целевой аудитории и просим выполнить задачу вслух. Пяти человек хватает, чтобы поймать основные затыки.
Что входит в UI-часть
UI начинается там, где структура утверждена, и отвечает за то, чтобы она читалась и работала на любом экране.
- Сетка и ритм. Модульная сетка, шаг отступов, ширина контейнера, поведение блоков на разных ширинах.
- Типографика. Пара шрифтов, шкала кеглей, межстрочный интервал, длина строки, иерархия заголовков.
- Цвет. Основной, акцентный, служебные цвета для ошибок и успеха, проверка контраста по WCAG (4.5:1 для основного текста).
- Состояния элементов. Кнопка в покое, при наведении, в фокусе с клавиатуры, нажатая, отключенная, в состоянии загрузки. Пропущенные состояния — самая частая недоделка макета.
- Компоненты. Поля, выпадающие списки, карточки, модальные окна собираются один раз в UI-кит и переиспользуются, иначе на десятой странице появится третий вариант кнопки.
- Микроанимация. Переходы, подтверждения действия, заглушки на время загрузки. Задача — объяснить, что произошло, а не украсить.
- Иконки и иллюстрации. Единый стиль, векторный формат, осмысленные подписи вместо иконки без текста.
Сравнение по существу
| Аспект | UX, пользовательский опыт | UI, пользовательский интерфейс |
|---|---|---|
| Основной вопрос | Что и в каком порядке делает человек | Как это выглядит и отзывается |
| Материал работы | Задачи, сценарии, структура, тексты, данные аналитики | Сетка, шрифты, цвет, состояния, компоненты |
| Артефакты | Карта разделов, сценарии, схематичный прототип, выводы тестирования | Макеты экранов, UI-кит, спецификация состояний, набор иконок |
| Когда делается | До отрисовки, вместе с разбором задачи | После того как структура утверждена |
| Как проверяется | Человек выполняет задачу и не задает вопросов «а где тут» | Экран читается на любом устройстве, элементы различимы, контраст в норме |
| Признак проблемы | Уходят с одного и того же шага, звонят с вопросом, ответ на который есть на странице | Не замечают кнопку, не понимают, что поле активно, жалуются на мелкий текст |
| Цена поздней правки | Высокая: меняется структура и часть верстки | Умеренная: чаще всего это правка стилей |
Как понять, где именно проблема
Когда заказчик говорит «сайт неудобный», мы сначала определяем слой, иначе легко потратить бюджет не туда. Несколько признаков из практики.
- Люди доходят до формы, начинают заполнять и бросают на конкретном поле — скорее UX: поле лишнее, непонятное или требует данных, которых у человека нет под рукой.
- Люди не доходят до формы вовсе, хотя блок стоит на видном месте — скорее UI: кнопка не читается как кнопка, или блок визуально сливается с фоном.
- Много звонков с вопросами, ответы на которые есть на сайте, — UX: информация есть, но не там, где ее ищут.
- Жалобы «на телефоне неудобно» — как правило, UI и верстка: мелкие зоны нажатия, перекрытые виджетом кнопки.
- Внутренний поиск используют вместо меню — UX: названия разделов не совпадают с языком аудитории.
Точнее всего это разбирается связкой количественных и качественных данных: аналитика показывает, где обрыв, а короткое наблюдение за пятью людьми объясняет причину.
Порядок работы на проекте
Мы держим последовательность, при которой дорогие решения принимаются раньше дешевых.
- Разбор задачи, аудитории и текущей аналитики.
- Структура сайта и сценарии.
- Прототипы ключевых страниц, согласование логики и текстов.
- Визуальная концепция на одной-двух страницах: шрифты, цвет, тон.
- Отрисовка остальных экранов на базе утвержденной концепции и UI-кита.
- Состояния элементов, мобильные версии экранов, спецификация для верстки.
- После запуска — замеры и точечные правки по данным.
Третий пункт часто предлагают пропустить ради экономии. По нашему опыту экономии не выходит: правка структуры на прототипе занимает часы, та же правка на сверстанном сайте задевает макеты, верстку и контент.
Что стоит подготовить заказчику
Качество UX-части сильно зависит от того, что мы получаем на входе. Полезно собрать заранее:
- доступ к системе аналитики и, если есть, к записям сессий;
- вопросы, которые чаще всего задают отделу продаж, — это готовый список того, чего не хватает на сайте;
- описание реальной воронки: что происходит после заявки, кто и когда перезванивает;
- ограничения: CMS, интеграции, обязательные блоки, требования бренда;
- примеры сайтов, которые нравятся и не нравятся, с объяснением почему.
Последний пункт часто дает больше, чем кажется: формулировка «у них сразу видно цену» — это требование к структуре, а не к оформлению.
Если нужна помощь
Мы начинаем с задач пользователя, а не с макета, и разделяем работу на два слоя явно: сначала структура и прототип, потом визуальный язык и состояния. Так интерфейс не приходится переделывать после запуска. Обсудить UX/UI-проектирование интерфейсов и разбор текущего сайта можно на первичной консультации.
Мы начинаем с задач пользователя, а не с макета: UX/UI-проектирование помогает не переделывать интерфейс после запуска.
