11 января 2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

4 июня 2018

Быстрые UX-исследования в Google

aic

19 сентября 2017

Комплексная дизайн-система

28 января 2019

Когда нужно бросить Sketch и стать дизайн-менеджером

2 февраля 2016

Редизайн и увеличение продаж сайта телеком-провайдера Onlime

26 февраля 2018

Юзабилити для дизайнеров, фреймворк P-A-C-T

aic

11 августа 2015

«Счастливый пользователь — это, конечно, круто, но к счастью должна прилагаться взаимная выгода»