Можно ли указывать в презентации количество сделанных ошибок респондентами на юзабилити-тесте
Разговаривали с Наташей Спрогис (UX Research Director, Mail.ru) по поводу того, нужно ли считать и представлять данные на юзабилити-тестах о том, сколько человек сделало каких-то ошибок из всех респондентов, и как это именно показывать, чтобы на основе этого не принималось ошибочных решений.
Почему это важно:
- Юзабилити-тест — это качественное исследование, а не количественное, оно показывает наличие или отсутствие проблемы при работе пользователя с решением, но никак не вероятность нахождения такой проблемы пользователем.
- Ошибки, найденные пользователями на юзабилити-тестировании не отражают все возможные пользовательские ошибки. При хорошем рекрутинге, мы можем выявлять 80–90% проблем, но не 100%.
- Мы не можем точно сказать какие из найденных проблем более важные, так как нельзя 8–20 респондентов интерполировать на всех пользователей вообще (генеральную совокупность).
Наташа указала статью, в которой действительно считается эта метрика, и это делается с пониманием того, что ресурс разработчиков не безграничен, и нужно как-то приоритезировать задачи в бэклоге для разработчиков (uxpajournal.org/the-relationship-between-problem-frequency-and-problem-severity-in-usability-evaluations/)
В статье, вместе с количеством ответов идёт ещё и метрика критичности проблемы, которая, в свою очередь состоит из двух пунктов:
1. критичность для пользователей
2. критичность для бизнеса
Иногда в своей сути они могут совпадать, но иногда — нет. То, что будет критично для бизнеса не факт, что будет важно для пользователя. А может быть и вообще не нужно (например, согласие пользователя получать рекламную рассылку — явно важно для бизнеса, а для пользователя — это очередной спам)
Но как же узнать критичность проблем для бизнеса, как они будут найдены? По логике, сделать это невозможно, так как мы не можем предсказать какие проблемы возникнут у пользователей, мы только можем сделать тут предположение. Которое оправдается, либо нет.
Чтобы как-то определить критичность проблем до теста, мы можем:
а) указать критичность решения какой-то задачи или сценария (например, возможность купить товар в интернет-магазине)
б) отметить те экраны, любая ошибка на которых точно критична для продукта (например, форма оплаты товара)
в) обозначить критичность задачи через важность её правильного выполнения (например, человек правильно понял условия возврата товара)
Конечно, это всё нужно делать предварительно до проведения тестирования, чтобы на тесте была возможность узнать критичность проблемы для пользователя, который её встречает (например, по шкале от 1 до 5).
Как это можно делать: во время теста нужно будет записывать проблемы, с которыми сталкивается пользователь. И в конце теста показать пользователю все проблемы, чтобы он проставил свою оценку.
Понятное дело, это нужно делать, если критичность проблем у бизнеса и у пользователей может не совпадать. Если это про одно и то же, то данный этап можно опустить.
На тесте, в общем, считаем количество проблем в данном кластере, либо количество пользователей, которые нашли эту проблему. Получаем некую табличку, с выписанными проблемами и количеством респондентов, которые столкнулись / нашли эту проблему.
На графике координат отображаем пересечение:
1) критичность проблемы для бизнеса
2) количество респондентов, которые столкнулось с этой проблемой
Критичность проблемы для пользователя мы можем обозначить каким-то знаком, поставленным рядом с точкой пересечения двух координат.
Как вариант, можно ещё как-то обозначить разработчиками сложность решения данной проблемы, например, в примерных сроках на её решение, чтобы бизнес тоже это понимал.
Итого мы получаем график, на котором видно какие проблемы нужно поставить на первый план, какие на второй, а какие — задвинуть в край бэклога.
P.S.: Если вы делаете внешнее исследование, и заранее вам не сказали, какие проблемы критичны, а какие — нет, а заказчик достаточно далёк от мира исследований, то указывать, скорее не стоит. Если же вы это делаете так, как написано в этой статье, то указать можно. Хотя тоже лучше это вынести вне презентации, чтобы случайно никто не увидел эти цифры и не начал судить о критичности проблемы только на основании того, сколько людей с ней столкнулось на тесте.