Интерфейс цифрового продукта — это не только его «лицо», но и способ взаимодействия и передачи информации пользователю.
Если UX работает, то у пользователя и продукта нет проблем: все необходимые задачи и действия выполняются, вся информация без труда находится.
А вот когда UX не работает, открывается вереница сложностей: пользователи не понимают, где найти нужную информацию, куда и зачем ведут кнопки и баннеры, и в итоге в принципе отказываются от подобных продуктов.
Как избежать подобной участи? Как сделать UX приятным и функциональным для пользователей?
У нас в Red Collar есть ответ — UX-аудит. Рассказываем, что это такое, из каких этапов состоит и, главное, как и какие проблемы он решает.
UX-аудит — это способ выяснить и решить, почему какие-либо решения в приложении, на сайте или в любом другом цифровом продукте не работают на уровне интерфейса: пользователи не могут найти нужные кнопки или разделы, выполнить необходимое действие и в принципе не понимают, как работает продукт. Это все приводит к отказу пользоваться таким приложением или сайтом, что в результате может негативно сказаться на эффективности бизнеса в целом.
Для того, чтобы это все эти проблемы определить и решить, нужно провести UX-аудит.
Конечно, в идеальном мире такие вопросы решаются еще на уровне разработки продукта. Но иногда бывают неудачные релизы или продукты запускаются с небольшими недочетами. Именно для таких историй UX-аудит может стать спасением.
Готовим сценарий UX-аудита
Начинаем с изучения.
Исследуем продукт, конкурентов, метрики, выявляем целевую аудиторию со слов клиента, сравниваем с показателями метрик, составляем портрет классического представителя одной из ЦА. Выявляем, зачем и как он пользуется продуктом, идем по все возможным путям выполнения действий пользователями, выявляем сложности представителей ЦА. Все это фиксируем, приоритезируем, даем рекомендации для дальнейшей работы по порядку приоритезации. В идеале — валидируем с помощью юзабилити-тестирования.
Завершаем все прототипом, чтобы показать, как именно будут выглядеть изменения.
Представим, что нам предстоит UX-аудит мобильного приложения банка. Наша задача — понять, почему пользователи не могут оформить новую карту и найти информацию о категориях кэшбэка. Давайте посмотрим, какой сценарий может получиться в ходе подобного аудита.
Экспертная оценка
Экспертная оценка — это способ посмотреть на продукт глазами пользователя: мы собираем всю необходимую информацию и с помощью гипотез предполагаем, что не так с точки зрения пользователя.
Собираем информацию
Перед нами банковское мобильное приложение, и мы должны понять, почему пользователи не могут выполнить привычные действия: оформить карту и найти информацию о кэшбэке.
Для начала интервьюируем клиента: выясняем цели и задачи проекта, целевую аудиторию, существующие проблемы и каких результатов хотелось бы достигнуть.
Тут всегда важно скорректировать ожидания: UX-аудит не решит глобальных проблем бизнеса, его главная цель — сделать продукт удобным в первую очередь для пользователей, что в итоге повлияет на лояльность и желание пользоваться подобным продуктом в целом.
Переходим к анализу: изучаем конкурентов, смотрим на то, как реализована механика, почему она работает (если работает). Смотрим статистику: работаем с данными Яндекс.Метрики, Google Analytics или другими инструментами. Если есть, анализируем предыдущие результаты аудитов.
Далее рассматриваем дизайн-ошибки: смотрим на согласованность всех элементов, изучаем имеющуюся UI-систему, брендбук. Определяем проблемы интерфейса, опираясь на принципы человеческого восприятия и соответствие эвристикам Якоба Нильсена.
Формируем гипотезы
Опираемся на собранную информацию, сами проходим проблемные сценарии (оформление карты, поиск информации) и составляем список гипотез с приоритетами: высоким, средним и низким.
К примеру, гипотеза с высокой критичностью в случае банковского приложения может звучать так: пользователь не может оформить карту, потому что нужный экран или кнопка отсутствует.
Средней критичности: пользователь может оформить карту, но делать это нужно через несколько кликов и итераций, что снижает мотивацию дойти до конца из-за затянутости сценария.
Низкой критичности: пользователь может оформить карту, но нужный экран или кнопка не на самом удобном месте, что тоже может снижать процент людей, которые захотят оформить карту.
Экспертная оценка — это субъективная история, потому что все гипотезы и приоритеты делаются в отрыве от реального пользовательского опыта. Все гипотезы и проблемы, которые мы сформировали, в идеале нужно сверять с ожиданиями и потребностями целевой аудитории. Если этого не сделать, то можно ошибиться не только с приоритизацией, но и в принципе с тем, что действительно не устраивает пользователей.
Результат этого этапа — документ, где мы перечисляем все гипотезы с приоритетами.
Но в идеале все гипотезы нужно проверить с помощью разных видов тестирования пользователей.
Юзабилити-тестирование: валидируем гипотезы, узнаем настоящие боли пользователей
Юзабилити-тестирование — это модерируемое или немодерируемое тестирование представителей целевой аудитории. То есть, это наш шанс понять и оценить, верно ли мы приоритизировали наши гипотезы и верно ли вообще определили главные боли пользователей.
Модерируемое тестирование — это серия живых глубинных интервью, которую проводит UX-аналитик, немодерируемое — это разные виды опросов, в том числе визуальные, где пользователи проходят различные сценарии и дают развернутые ответы.
Вернемся к банковскому мобильному приложению. Юзабилити-тестирование может решить как проблемы со взаимодействием — оформление карты, выдача кредитов; так и коммуникационного — поиск информации о кэшбэке и любых других ответов на интересующие вопросы. Главное — подобрать метод, который лучше всего поможет раскрыть суть проблемы.
Интервью: узнаем, что не устраивает пользователей
Берем наши гипотезы и формулируем из них вопросы, на которые пользователи смогут дать развернутые ответы: почему они не могут оформить карту, что их останавливает, как они видят процесс оформления и чего им не хватает в плане информации.
Все ответы фиксируем. Так мы выявим глубинные проблемы целевой аудитории, потребности, особенности поведения, контекст использования продукта. И проверим, насколько верными были наши гипотезы.
Карточная сортировка: меняем структуру на более понятную пользователю
Карточная сортировка отвечает на вопросы коммуникационного характера: почему пользователи не могут найти найти интересующую информацию, почему не понятен текущий контент и как сделать его более «говорящим» для пользователей.
Кроме того, этот метод помогает разработать новую структуру сайта или понять насколько пользователям понятна существующая, проработать меню и навигацию.
В случае с банковским мобильным приложением такой метод поможет решить проблемы с поиском информации о кэшбэке и всех других сложностях, которые могут касаться поиска ответов на конкретные вопросы.
Процесс следующий: записываем на карточках названия объектов, респонденты самостоятельно их сортируют, исходя из своих представлений о структуре объектов и связях между ними.
Для вопросов о кэшбэке это может выглядеть так: записываем названия разделов приложения на карточках (все операции, мои карты, платежи и т.д.) и отдельно даем карточку с кэшбэком. Смотрим, куда пользователи ее поместят, как расположат другие разделы и как вообще по мнению пользователей будет выглядеть понятная структура.
Есть три варианта этого метода: открытый, закрытый и обратный.
В «открытом» участники теста сами придумывают названия для групп объектов.
В «закрытом» всем группам уже даны названия, цель — определить, к какой из предложенных категорий относятся объекты.
При «обратной» сортировке проверяем логичность текущей структуры: участникам предлагают найти подходящую карточку, перемещаясь по разделам.
В итоге пользователи помогают определить работоспособность текущей структуры, выявить проблемные места и найти варианты исправления.
First-click: делаем навигацию более интуитивной
Этот метод решает проблемы и продуктового, и коммуникационного характера и точечно выявляет простые проблемы, проверяет как действия, так и контент: например, дает понять, куда будут нажимать пользователи, как пользоваться навигацией, какие блоки информативны, какие — нет.
Мобильному банковскому приложению first-click может помочь скорректировать навигацию, контент и предназначение каких-то конкретных кнопок, баннеров и прочих элементов.
При таком методе мы быстро опрашиваем пользователей: куда бы они нажали, чтобы оформить новую карту? Где находится главное меню? Где может располагаться информация о кэшбэке? И так далее.
Такой метод позволяет быстро подтвердить неинтуитивные элементы в интерфейсе и дать рекомендации по их исправлению на основе реального пользовательского опыта.
При прохождении теста фиксируем различные юзабилити-метрики: время, успешность выполнения, удовлетворенность — это поможет проанализировать, какие именно элементы дизайна и интерфейса не работают.
В итоге мы получим список актуальных проблем и гипотез, которые мы провалидировали с реальной целевой аудиторией. Далее мы их можем использовать для создания демо, но сначала посмотрим на другие способы валидации наших гипотез.
Готовим демо
Итак, у нас есть проверенные гипотезы и мы уже знаем конкретные проблемы интерфейса и причины, по которым пользователи не могут оформить карту, найти информацию о кэшбэке и так далее.
Все это переводим в рекомендации в формате демо: берем текущий дизайн продукта и без подключения к бэку создаем обновленную версию проблемного участка — страницы или экрана.
В обновленной версии показываем, как можно исправить интерфейс, чтобы пользователи могли успешно проходить необходимые сценарии.
Так мы, во-первых, наглядно показываем разницу между текущим дизайном и обновленным. Во-вторых, такое демо можно вновь показать пользователям и дополнительно провалидировать все внесенные правки.
UX-аудит — результаты
Что же имеем в итоге? В идеале, если мы прошли через все стадии, включая валидацию с пользователями, у нас есть список проблем и способы их решения. Результат исправления таких проблем — работающий интерфейс и счастливые пользователи.
Иными словами, будут выполнены те задачи, которые изначально ставились перед продуктом: например, успешное оформление новых карт, подключение категорий кэшбэка и так далее.
