UX и UI звучат похоже, часто пишутся через дробь и в вакансиях идут одной строкой. В небольших командах обе роли действительно закрывает один человек, и в этом нет ничего плохого. Плохо другое: когда роли не разделены даже мысленно, часть работы не делает никто, и обнаруживается это на этапе вёрстки или, хуже, после запуска. Ниже разбираем, чем задачи отличаются по сути, что теряется при совмещении и какой минимум должен быть в любом проекте независимо от размера команды.
Разделение задач
Проще всего запомнить так: UX отвечает на вопрос «как это работает», UI — «как это выглядит». Первый работает со структурой и сценариями, второй с оформлением и компонентами.
| UX: как это работает | UI: как это выглядит |
|---|---|
| Сценарии пользователей и их задачи | Типографика, цвет, контраст |
| Структура разделов и навигация | Сетка, отступы, ритм |
| Каркасы экранов без оформления | Компоненты и их состояния |
| Логика форм, подсказок и ошибок | Иконки, иллюстрации, изображения |
| Приоритеты содержимого на экране | Единство оформления по всему продукту |
| Крайние случаи и пустые состояния | Отзывчивость к размеру экрана |
| Проверка на живых людях | Передача макетов в разработку |
Границы условные, и в реальной работе они всё время пересекаются: размер кнопки — вопрос и оформления, и удобства нажатия на телефоне. Но принципиальная разница есть — UX-решения принимаются до того, как выбраны цвета, и на них ничего в оформлении не влияет.
Что происходит, когда роль одна
Обычно перевешивает оформление. Оно нагляднее, его легче показать и обсудить, по нему заказчик даёт быструю обратную связь. В результате появляются красивые макеты нескольких основных экранов, а сценарии остаются непродуманными.
Проявляется это позже и стоит дороже. При вёрстке выясняется, что не нарисованы состояния кнопок, нет вида списка без результатов, не описано, что происходит при ошибке загрузки, отсутствует половина мобильных версий. Разработчик достраивает эти случаи сам, как получится, и продукт становится неровным: одна часть продумана, другая собрана на ходу.
Второй типичный симптом — макеты нарисованы на идеальных данных. Названия короткие, описания одинаковой длины, у всех товаров есть фотографии. На реальном содержимом вёрстка расползается.
Минимум для любого проекта
Независимо от того, один человек делает работу или трое, эти пункты должны быть закрыты.
- Описанные сценарии основных задач. Хотя бы три-четыре: как человек находит нужное, как оформляет заявку, как возвращается к незавершённому.
- Каркасы ключевых экранов до оформления. Черновая структура, по которой видно, что где стоит и почему.
- Состояния элементов. Обычное, при наведении, нажатое, отключённое, с фокусом, с ошибкой, во время загрузки.
- Крайние случаи. Пустой список, ошибка, очень длинное название, отсутствующее изображение, медленный интернет.
- Мобильные версии всех страниц, а не только главной и одной внутренней.
- Текст в интерфейсе. Подписи кнопок, сообщения об ошибках, пустые состояния пишутся вместе с макетом, а не подставляются потом.
- Проверка на живых людях хотя бы на пяти сценариях. Пять человек находят большую часть проблем — это давно проверенное наблюдение.
Как принимать макеты
Самая частая ошибка заказчика — оценивать макет по принципу «нравится или нет». Вкус в этом разговоре наименее полезный инструмент: макет должен решать задачу, а не нравиться. Вопросы, которые стоит задавать вместо этого:
- Понятно ли за пять секунд, куда я попал и чем занимается компания?
- Видно ли главное действие на экране без прокрутки?
- Что произойдёт, если название товара или услуги окажется втрое длиннее?
- Как выглядит этот блок, если данных нет вообще?
- Что увидит человек, если форма отправлена с ошибкой?
- Как это выглядит на телефоне, включая таблицы и длинные списки?
- Читается ли текст при обычной яркости экрана, хватает ли контраста?
Все эти вопросы относятся к UX, и именно их чаще всего пропускают на приёмке, потому что обсуждать цвет кнопки проще.
Что даёт прототип
Прототип — это работающая схема будущего интерфейса без оформления. Его смысл в том, что ошибки в структуре обнаруживаются до того, как нарисованы макеты и написан код. Переставить блоки в прототипе — часы работы, переделать свёрстанный раздел — недели.
На прототипе проверяются главные вещи: понятна ли навигация, находится ли нужное, доходит ли человек до заявки, не теряется ли на середине формы. Проверка занимает несколько коротких сессий с людьми, похожими на вашу аудиторию, и почти всегда меняет часть решений.
Кого нанимать
Для сайта услуг или корпоративного сайта обычно достаточно одного универсального дизайнера — при условии, что у него есть дисциплина в структуре и он не начинает работу с подбора цветов. Признак такого специалиста — он задаёт вопросы о бизнесе и аудитории раньше, чем показывает первую картинку.
Для сервиса с личным кабинетом, ролями и сложной логикой разделение ролей окупается. Там цена непродуманного сценария измеряется в нагрузке на поддержку, в ошибках операторов и в отказах пользователей, и один человек физически не удержит одновременно логику десятков экранов и единство оформления.
Отдельно стоит сказать про дизайн-систему. Как только экранов становится больше двадцати, набор компонентов с описанными правилами экономит больше времени, чем стоит его создание, — и это работа на стыке обеих ролей.
Как это устроено у нас
Мы начинаем со сценариев и каркасов, проверяем структуру до отрисовки и только потом переходим к оформлению и компонентам. Это дешевле переделок и предсказуемее для сроков. Посмотрите, как устроено проектирование пользовательских интерфейсов, и напишите нам — обсудим задачу и покажем, из чего складывается работа.
Проверить гипотезы дешевле на прототипе: UX/UI-проектирование экономит недели разработки.
