11 января 2019

Как собирать данные и анализировать юзабилити-тестирования

Заключительная часть нашей серии статей о том, как анализировать ю-тесты

В прошлой статье мы писали, что на юзабилити-тестировании приоритетнее записывать действия респондента, а мнение и комментарии — по возможности. Вы можете вести записи во время тестирования и/или после по видеозаписи.

Выбирайте наиболее удобный и эффективный для вас формат сбора данных. Собирать их вы можете на стикерах, бумаге, в протокол или электронный документ.

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

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

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

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

Что записывать

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

Что выделять в анализе

После тестов собирается достаточно много записей, особенно если у вас было больше 10 респондентов. Поэтому постарайтесь сначала выделить основные сложности, с которыми столкнулись участники исследования на каждом шагу. Следом найдите комментарии (пользовательскую оценку) респондентов по каждому этапу и в целом по отношению к продукту. Для каждого пункта таблицы анализируйте собранные данные и составляйте выводы.

К примеру, если несколько человек не смогли или не сразу придумали правильный пароль, то можно это выделить в проблему: «Пользователи не понимают, как составить пароль».

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

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

  • боязнь утечки персональных данных;
  • респондент не пользуется социальными сетями;
  • привык использовать и получать сообщения только на почту.

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

Как сопоставить данные

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

Как оценить задания и проблемы интерфейса

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

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

После того, как вы выделили темы и собрали проблемы, не забудьте оценить их по критичности прохождения сценария исходя из того, как они влияли на респондентов:

  • Критические проблемы — из-за которых пользователь не может пройти сценарий,
  • Серьезные проблемы  — увеличивают время прохождения сценария,
  • Минорные проблемы — вызывают вопросы у пользователей, но не влияют на прохождение сценариев.

Преобразовать данные в список инсайтов и проблем

Если в ходе тестирования респондент столкнулся с неинтерфейсными проблемами, их стоит вынести в раздел инсайтов. Инсайты — это знания, которые вы получили во время интервью или тестирования, но которые не относятся напрямую к интерфейсу. Здесь содержатся знания, которые могут быть полезны представителям бизнеса в целом и сделают отчет интересным не только команде продукта.

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

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

Мы всегда делаем комплексные работы — с дизайном и A/B тестами. Поэтому важно понятно донести полученные результаты до команды, чтобы внести правильные изменения в интерфейс и протестировать их на большей выборке.

Для чего нужен отчет и когда без него можно обойтись

В создании отчета принимает участие специалист, проводящий исследования, ведущий UX-специалист с экспертными знания в отрасли, менеджер продукта и дизайнер (на случай, если нужна помощь в отрисовке макетов).

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

В зависимости от целей исследования отчет также может включать в себя план развития продукта:

  • перечень исправлений текущего продукта и введение нового функционала;
  • список гипотез для A/B тестирований;
  • предложение по глобальной перестройке продукта.

Если команда торопится с внедрением изменений в продукт или не нуждается в оформлении результатов — их можно презентовать команде, обсудить и передать в работу.

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

Из каких разделов состоит отчет

Начните отчет с описания тестируемого продукта, целей тестирования и вопросов, которые были до тестирования. В начале отчета должно быть описание самого исследования: как и где оно проводилось, на каких сегментах ЦА.

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

  • о том, какие задания были наиболее сложными;
  • о тенденциях в интерфейсе, которые были основными причинами ошибок и проблем;
  • о разных сегментах ЦА: были ли такие, которые справились хуже остальных, чем различается опыт групп.

Часть проблем может быть известны из данных аналитики или данных заказчика. В отчете эти проблемы следует раскрыть максимально, чтобы затем минимизировать уход пользователей.

К примеру, из данных аналитики мы знали, что анкета является узким местом на пути оформления покупки билетов. Поэтому в исследовании необходимо узнать, в чем причина проблемы.

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

В описании проблемы напишите, как она проявлялась во время тестирования (что делали респонденты), вставьте скриншот экрана, на котором есть эта проблема.

Опирайтесь на действия респондентов, а не на их слова, потому что часто это не совпадает. Например, респонденты не могут выполнить задание или выполняют его неправильно, но при этом говорят, что сайт удобный и понятный.

Старайтесь к каждой проблеме и инсайтам сформулировать рекомендацию. Это может быть текстовая рекомендация. Например, исправить верстку или оптимизировать скорость загрузки страницы. Либо это может быть макет элемента или целой страницы, или страница в дизайне. При этом визуальные рекомендации следует описывать: что сделали, что изменилось.

Приоритезация гипотез и рекомендаций

Если мы проводим юзабилити-тест с последующим A/B тестированием, на финальном этапе мы приоритезируем гипотезы, чтобы определиться с очередностью их запуска. Мы обсуждаем в команде с аналитиками все проблемы и оцениваем каждую гипотезу по нескольким критериям (обычно мы применяем  PIE-фреймфорк):

  • Потенциал — то, как много улучшений можно сделать на странице. Как правило, потенциал устанавливается, опираясь на экспертную оценку исследователей, мнение клиентов, данные веб-аналитики по поведению пользователей на странице и трафику.
  • Важность — насколько ценен трафик на странице. Самые важные страницы — это страницы с самым дорогим и большим трафиком. Возможно, в результате тестирования мы найдем страницы со множеством ошибок юзабилити, но если они не имеют большого значения для бизнеса и не играют ключевой роли в достижении пользовательской цели, то приоритет по этой странице можно опустить.
  • Легкость — насколько легко будет выполнить тест на странице (техническая реализация, организационные или политические барьеры)

После этого согласовываем список с заказчиком, поочередно выкатываем гипотезы на A/B тестирование и замеряем их эффективность.

Читайте предыдущие части о ю-тестах:

Кому и зачем нужны юзабилити-тестирования

Как писать сценарии юзабилити-тестирования

Как искать и отбирать респондентов для юзабилити-тестирования

Как проводить юзабилити-тестирования

 

Подписывайтесь на наши соцсети: Вконтакте, Facebook, Telegram

Дальше — большe

Идеи, которые нас вдохновляют, видео-интервью и переводы исследований, которые были нам полезны в процессе работы.

11 сентября 2018

Клиентский воркшоп: как выяснить реальные потребности бизнеса на старте проекта

9 ноября 2018

Почему стоит проводить презентации проектов лично

22 октября 2019

Новый сайт банка «Возрождение»

aic

26 января 2017

Невероятная новость об искусственном интеллекте Google, которую вы, возможно, пропустили

30 октября 2019

Поп-апы: 10 плохих трендов и их альтернативы

aic

20 октября 2016

Карточки — сильнейший тренд веб-дизайна в 2016 году