Как собирать данные и анализировать юзабилити-тестирования
Заключительная часть серии статей от AIC о том, как анализировать ю-тесты
В прошлой статье мы писали, что на юзабилити-тестировании приоритетнее записывать действия респондента, а мнение и комментарии — по возможности. Вы можете вести записи во время тестирования и/или после по видеозаписи.
Выбирайте наиболее удобный и эффективный для вас формат сбора данных. Собирать их вы можете на стикерах, бумаге, в протокол или электронный документ.
Для записи на чистую бумагу запаситесь достаточным количеством листков и ручек, чтобы не пришлось сбегать с интервью. Помечайте вопрос, который вы задаете респонденту, затем записывайте его действия, ошибки и особо эмоциональные комментарии.
Другой вариант записи данных от руки: распечатайте сценарий вашего интервью на половину страницы, а данные записывайте на вторую половину. Старайтесь записывать данные в едином формате для всех респондентов, чтобы потом было просто соотнести их между собой и сделать выводы.
К примеру, вы можете разделить листок или документ на несколько частей в соответствии с шагами, который выполняет пользователь на сайте или в приложении. Напротив каждой такой части фиксируйте наблюдения за всеми респондентами. В итоге получите табличку, в которой будут уже рассортированные наблюдения, по которым легко будет делать выводы о каждом задании и шаге.
Первые два варианта подойдут тем, кто уверен в своем почерке и скорости письма. Альтернативой является запись в документ на компьютере. Для протокола лучше всего использовать табличку, в первом столбце которой будет сценарий интервью, а в других столбцах записи за респондентами.
Что записывать
Во время интервью записывайте пошагово действия и слова респондента. Не пытайтесь интерпретировать, давать оценку его действиям и словам. К примеру, если пользователь несколько раз пытался ввести свой пароль, есть соблазн написать: «Не понимает подсказку как создать пароль». Записывайте только факты: «Три раза пытался создать пароль, не получилось». Со словами так же — записывайте прямую речь, не делая выводов.
Что выделять в анализе
После тестов собирается достаточно много записей, особенно если у вас было больше 10 респондентов. Поэтому постарайтесь сначала выделить основные сложности, с которыми столкнулись участники исследования на каждом шагу. Следом найдите комментарии (пользовательскую оценку) респондентов по каждому этапу и в целом по отношению к продукту. Для каждого пункта таблицы анализируйте собранные данные и составляйте выводы.
К примеру, если несколько человек не смогли или не сразу придумали правильный пароль, то можно это выделить в проблему: «Пользователи не понимают, как составить пароль».
Если у заказчика были конкретные вопросы до исследования, найдите в данных ответы на них и отметьте, чтобы потом внести в отчет или презентацию. Данные нужно тщательно отобрать и интерпретировать их, исходя из контекста — ответ пользователя всегда зависит от его персональной ситуации, и при выводах нужно учитывать все детали.
К примеру, человек говорит, что не будет пользоваться авторизацией через соцсети. Причинами могут быть:
- боязнь утечки персональных данных;
- респондент не пользуется социальными сетями;
- привык использовать и получать сообщения только на почту.
При любом из этих ответов мы не можем однозначно ответить: убирать такую авторизацию, оставить или изменить ее. Нужно разбирать ситуацию каждого респондента, чтобы не сделать неверных выводов на основании его ответов. И затем, при необходимости — проверять это на большой аудитории продукта.
Итак, вы провели интервью и собрали все данные. Проведите их анализ и сделайте выводы. При анализе записанных интервью смотрите каждый шаг заданий по каждому респонденту и группируйте наблюдения по общим темам. Прочитав все наблюдения по одной теме, постарайтесь сделать общие выводы для всех респондентов.
Как оценить задания и проблемы интерфейса
Проставьте в таблице оценку успешности прохождения сценариев каждому респонденту в зависимости от его ошибок: от «не выполнено» до “выполнено успешно”. После этого оцените, какие из заданий или шагов тестирования оказались наиболее проблемными и сложными для прохождения — о них стоит сообщить команде и заказчику в первую очередь.
Также в процессе тестирования отмечайте: какими путями при прохождении сценариев респонденты пользуются чаще, какие элементы вызывают положительную оценку или упрощают прохождение заданий. Это пригодится при редизайне, для планирования элементов и принятия решений о выборе ключевых их них.
После того, как вы выделили темы и собрали проблемы, не забудьте оценить их по критичности прохождения сценария исходя из того, как они влияли на респондентов:
- Критические проблемы — из-за которых пользователь не может пройти сценарий,
- Серьезные проблемы — увеличивают время прохождения сценария,
- Минорные проблемы — вызывают вопросы у пользователей, но не влияют на прохождение сценариев.
Преобразовать данные в список инсайтов и проблем
Если в ходе тестирования респондент столкнулся с неинтерфейсными проблемами, их стоит вынести в раздел инсайтов. Инсайты — это знания, которые вы получили во время интервью или тестирования, но которые не относятся напрямую к интерфейсу. Здесь содержатся знания, которые могут быть полезны представителям бизнеса в целом и сделают отчет интересным не только команде продукта.
К примеру, респонденты отказываются оформлять заказ, потому что нет возможности оплатить заказ при получении. Стоит сообщить об этом команде и проверить с аналитиками, сколько пользователей уходит на этапе оплаты.
Выпишите полученные проблемы и инсайты исследования в отдельную табличку по каждому заданию и шагу — это содержание основной части вашего отчета. Такой список можно дополнить пояснениями, которые помогут другим членам команды понять, в чем конкретно состоит проблема и что происходило с пользователями при прохождении сценария.
Мы всегда делаем комплексные работы — с дизайном и A/B тестами. Поэтому важно понятно донести полученные результаты до команды, чтобы внести правильные изменения в интерфейс и протестировать их на большей выборке.
Для чего нужен отчет и когда без него можно обойтись
В создании отчета принимает участие специалист, проводящий исследования, ведущий UX-специалист с экспертными знания в отрасли, менеджер продукта и дизайнер (на случай, если нужна помощь в отрисовке макетов).
Отчет помогает членам команды и заинтересованным лицам узнать о недостатках продукта и точках роста. Также он помогает сравнить результативность продукта по прошествии нескольких итераций и отследить изменения.
В зависимости от целей исследования отчет также может включать в себя план развития продукта:
- перечень исправлений текущего продукта и введение нового функционала;
- список гипотез для A/B тестирований;
- предложение по глобальной перестройке продукта.
Если команда торопится с внедрением изменений в продукт или не нуждается в оформлении результатов — их можно презентовать команде, обсудить и передать в работу.
Для внешних заказчиков или руководства лучше составлять отчет или презентацию, в которых будет рассказано все об исследовании с самого начала. Текст отчета должен быть максимально простым, конкретным и поясняющим. Старайтесь писать его как будто для людей, которые никогда не слышали про юзабилити-тестирования, про детали продукта и его возможности. Для наглядности добавьте скриншоты.
Из каких разделов состоит отчет
Начните отчет с описания тестируемого продукта, целей тестирования и вопросов, которые были до тестирования. В начале отчета должно быть описание самого исследования: как и где оно проводилось, на каких сегментах ЦА.
Основная часть отчета состоит из описания инсайтов, проблем интерфейса и рекомендаций по их решению. Сделайте выводы:
- о том, какие задания были наиболее сложными;
- о тенденциях в интерфейсе, которые были основными причинами ошибок и проблем;
- о разных сегментах ЦА: были ли такие, которые справились хуже остальных, чем различается опыт групп.
Часть проблем может быть известны из данных аналитики или данных заказчика. В отчете эти проблемы следует раскрыть максимально, чтобы затем минимизировать уход пользователей.
К примеру, из данных аналитики мы знали, что анкета является узким местом на пути оформления покупки билетов. Поэтому в исследовании необходимо узнать, в чем причина проблемы.
Постарайтесь разобраться в каждом случае: почему проблема возникла, как сильно она нарушает сценарий, какие неверные или лишние действия совершают респонденты в процессе. Это поможет вам понять, какое решение позволит ликвидировать или снизить влияние проблемы.
В описании проблемы напишите, как она проявлялась во время тестирования (что делали респонденты), вставьте скриншот экрана, на котором есть эта проблема.
Опирайтесь на действия респондентов, а не на их слова, потому что часто это не совпадает. Например, респонденты не могут выполнить задание или выполняют его неправильно, но при этом говорят, что сайт удобный и понятный.
Старайтесь к каждой проблеме и инсайтам сформулировать рекомендацию. Это может быть текстовая рекомендация. Например, исправить верстку или оптимизировать скорость загрузки страницы. Либо это может быть макет элемента или целой страницы, или страница в дизайне. При этом визуальные рекомендации следует описывать: что сделали, что изменилось.
Приоритезация гипотез и рекомендаций
Если мы проводим юзабилити-тест с последующим A/B тестированием, на финальном этапе мы приоритезируем гипотезы, чтобы определиться с очередностью их запуска. Мы обсуждаем в команде с аналитиками все проблемы и оцениваем каждую гипотезу по нескольким критериям (обычно мы применяем PIE-фреймфорк):
- Потенциал — то, как много улучшений можно сделать на странице. Как правило, потенциал устанавливается, опираясь на экспертную оценку исследователей, мнение клиентов, данные веб-аналитики по поведению пользователей на странице и трафику.
- Важность — насколько ценен трафик на странице. Самые важные страницы - это страницы с самым дорогим и большим трафиком. Возможно, в результате тестирования мы найдем страницы со множеством ошибок юзабилити, но если они не имеют большого значения для бизнеса и не играют ключевой роли в достижении пользовательской цели, то приоритет по этой странице можно опустить.
- Легкость - насколько легко будет выполнить тест на странице (техническая реализация, организационные или политические барьеры).
После этого согласовываем список с заказчиком, поочередно выкатываем гипотезы на A/B тестирование и замеряем их эффективность.
Автор — Александра Вязовик, UX-исследователь в AIC