Как UX-исследования избавляют от дорогих ошибок в продуктах

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

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

Когда речь идет о сложных сервисах, команде нужно понимать, какой сценарий будет интуитивно понятным для клиентов. Участников исследования погружают в контекст и предлагают решить задачу. Далее нужно пронаблюдать за его действиями – логика пользователей может сильно отличаться от представлений разработчиков, и это нормально. Нужно выяснить, почему человек действует так или иначе, что его мотивирует, а что мешает.

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

Важно понимать, что в UX-тестированиях не бывает «плохих» или неправильных ответов. С определенной точки зрения, можно сказать, что чем хуже человек справляется с тестом, тем лучше для нас – значит, мы выявляем максимум проблем, с которыми реальные пользователи уже не столкнутся. Но это вовсе не означает, что мы даем респондентам неработающие прототипы.

Итог UX-исследования – карта взаимодействия пользователя с продуктом (Customer Journey Map). Она объединяет в себе все впечатления клиента от продукта, его пожелания на каждом шаге сценария. Оформляется примерно так – слева описание целевого пользователя, далее собраны полезные данные о клиентском опыте по каждому этапу его «путешествия»:

На ранних стадиях разработки лучше всего использовать качественные исследования, которые отвечают на вопросы «как» и «почему». Как пользователь идет по сценарию? Почему он открывает именно эту шторку, чтобы найти нужную информацию? Как ему будет удобно добраться до настроек? Почему другой вариант окажется неудобным? Технологии качественных исследований бывают разные: глубинные интервью, фокус-группы, и т.д. Для наших целей больше всего подходит метод модерируемого юзабилити-тестирования:

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

Модератор в любой может задать респонденту вопрос, уточнить что-то, пообщаться после проведения теста. Чем больше правильных и своевременных вопросов будет задано, тем более эффективными и ценными будут результаты теста. Юзабилити-тесты можно проводить и без участия модератора, но – тогда результаты будут менее глубокими.Метод позволяет быстро получить первую обратную связь от потенциальных или реальных клиентов. А если продукт уже работает, понять, что можно улучшить.Теперь о том, как строится такое исследование.

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

• Успешность выполнения задания. Пользователь справился с заданием практически без проблем – 100%; столкнулся с проблемами, но в итоге справился – 50%; – не справился с заданием – 0%.
• Субъективная оценка простоты шага. Сам пользователь выставляет оценку от 1 до 5 баллов и дает аргументацию. Именно здесь, как правило, мы получаем самую ценную информацию – респонденты указывают нам на самые удачные UX-решения и делятся впечатлениями о том, что было удобно, а что – не очень.
• Частота возникновения проблем. Составляется по итогам тестирования – мы считаем, какие возникли сложности и как часто возникают.

В подборе респондентов значение имеют пол, возраст, город проживания, достаток, опыт работы с ИТ-сервисами, используемое устройство. Разумеется, для чистоты эксперимента мы не привлекаем людей из команды разработки и сферы ИТ. И стараемся максимально попадать в целевую аудиторию – тестировать премиальные сервисы на студентах бессмысленно.Интересно, что для качественного исследования достаточно 5-8 респондентов. UX-эксперты выяснили, что если увеличивать число участников, то выявляемые трудности начинают повторяться, так что новой информации исследователь уже не получит. Зато в количественных исследованиях счет респондентов должен идти на десятки, а то и сотни.

Мы не просто даем респондентам прототип приложения, а создаем некую картинку, чтобы они почувствовали себя на месте будущих пользователей. Например: «Ты выдвигаешься на работу, садишься в свою машину. Тебе нужно воспользоваться дорожным сервисом, который ты вчера себе скачал. Твои действия?»Контекст влияет на опыт взаимодействия с продуктом. Важно, чтобы созданный контекст был максимально близок к реальным историям клиентов, т.к. в зависимости от ситуации, сценарии использования могут отличаться.

Сценарий исследования для всех участников одинаковый. Модератор дает вводные о том, как будет проходить тест, рассказывает о продукте, погружает в контекст.В сценарий входят задания, которые нужно выполнить респонденту, и вопросы для модератора, которые он должен задать на каждом шаге. Очень важно, чтобы формулировки не направляли пользователя к тем или иным функциям напрямую – нужно, чтобы он сам искал техническое решение для своей задачи.То есть мы не говорим респонденту: «Вам нужно отключить услугу в настройках. Как вы будете это делать?». Вместо этого задание звучит примерно так: «Вы поэкспериментировали с услугой и поняли, что сейчас она для вас не актуальна. Ваши действия?» Тогда пользователь должен сам понять, что это нужно сделать в настройках, самостоятельно зайти туда и найти нужную опцию. Если у него не получится это сделать, это сигнал для дизайнеров.

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

• Удалось ли подтвердить или опровергнуть гипотезы? Группируем ответы по гипотезам, удостоверяемся, что мы собрали достаточно информации по каждому пункту.
• Какие участки сценария оказались для пользователей самыми удобными, а где было больше проблем? Опять же, сейчас мы не задумываемся о том, почему это произошло и что с этим делать – только факты.
• О каких трудностях они говорили по ходу теста? Готовим список всех моментов, которые были непонятными, неочевидных шагов и тупиков. Плюс субъективные оценки простоты с аргументацией и прочими комментариями.

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

С этой информацией перед глазами мы получаем комплексную информацию о том, как обстоят дела в сценарии. И можем формировать предложения по улучшению. Теперь мы понимаем, какие у продукта проблемы, можем их приоритизировать.Более того, мы можем оценить, окупится ли на данном этапе доработка сложного сценария или от него можно отказаться. Еще один пример из нашего опыта – по итогам UX-исследования принципиально нового продукта выяснилось, что пользователи не могут разобраться с одним из двух базовых режимов работы. Мы предложили заказчику исключить этот режим из MVP, чтобы сосредоточиться сейчас на одном сценарии, а второй доработать на следующем этапе проекта.

Чтобы протестировать UX нового продукта, команде нужна следующая информация:

• Описание продукта. Что именно мы будем тестировать?
• Цели исследования. На что повлияют его результаты? Какие решения будет принимать команда с полученной информацией?
• Сценарий. Какие шаги проходит пользователь на пути к своей цели? Один продукт может включать любое количество сценариев.
• Гипотезы и вопросы. Какие сомнения у команды есть? Что хочется прояснить в сценариях? Какие есть предположения о проблемных местах в интерфейсе? Какие важные вопросы сейчас без ответа?
• Кто пользователи. Какие пользователи интересны в контексте этого исследования (роль, особенности организации, отрасль, активность в сервисе)? Какие задачи они решают в сервисе? Есть ли лояльные пользователи и их контакты?
• Сроки. К какому сроку важно получить информацию, иначе будет поздно?

Ответить на все эти вопросы продуктовой команде не составит труда. А дальше дело техники UX-экспертов – они подберут нужные методы, сформируют группу респондентов, проведут исследование и помогут правильно интерпретировать результаты.