Не начинайте с дизайна: как UX-исследования помогают создать интерфейс, которым будут пользоваться

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

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

Сначала — разобраться в проблеме

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

UX-исследование помогает отделить такие предположения от фактов. Вместо вопроса «какой экран нам нужно переделать?» команда сначала выясняет: что человек пытается сделать, как он решает эту задачу сейчас и что ему мешает.

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

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

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

Исследуем не аудиторию, а опыт

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

Рассмотрим пример на сервисе маркировки рекламы SmartErid. Здесь мало поговорить просто с любым маркетологом. Гораздо полезнееб удет человек, который недавно самостоятельно передавал данные на маркировку, работал с ОРД и сталкивался с ошибками или ручной проверкой.

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

От наблюдения — к решению

Одна из главных ошибок UX — сразу переводить наблюдение в конкретный элемент интерфейса. Например:

• Наблюдение: пользователь несколько раз проверяет данные.

• Интерпретация: он не уверен, что всё сделал правильно.

• Потребность: получить подтверждение корректности процесса.

• Решение: система сама проверяет данные и понятно сообщает о результате.

Такой подход позволяет не просто копировать привычки пользователя, а понять причину его поведения.

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

Сначала сценарий, потом экраны

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

Для каждого шага полезно задать четыре вопроса:

• что пользователь видит;

• что он понимает;

• что он должен сделать;

• как система реагирует на его действие.

Особенно это важно для ошибок. Сообщение «Произошла ошибка» практически ничего не объясняет. Пользователь должен понимать, что произошло, почему и что делать дальше. Например: «Файл превышает допустимый размер. Загрузите изображение объёмом не более 10 МБ». То же касается состояний загрузки, пустых страниц, сохранения, успешного завершения и ошибок внешних сервисов. Они тоже являются частью интерфейса, даже если не попадают в первый дизайн-макет.

Прототип позволяет ошибаться дёшево

После User Flow можно переходить к wireframe — схематичному прототипу интерфейса. На этом этапе не нужно тратить время на цвета, шрифты и декоративные элементы. Главная задача — проверить структуру: понятна ли последовательность действий, достаточно ли информации на каждом шаге, не заставляем ли мы пользователя делать лишнюю работу. Это позволяет обнаружить проблемы до разработки.

Логика здесь простая: исследование, User Flow, wireframe, прототип, тестирование, дизайн и разработка. Чем раньше обнаружена ошибка, тем дешевле её исправить.

Прототип тоже нужно тестировать

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

Если пользователь долго ищет кнопку, ошибается, возвращается назад или неправильно понимает сообщение — это не повод обвинять его в невнимательности. Это сигнал, что интерфейс недостаточно хорошо объясняет, что делать. Таким образом тестируется не пользователь, а решение, которое вы ему предлагаете.

UX — это не этап, а цикл

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

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