Хроники тестирования. Часть 4: Работа с аудиторией и анализ результатов
Добро пожаловать в четвёртую и заключительную часть Хроник Тестирования — цикла статей, посвященных валидации идей или решений. Если вы здесь впервые, то, возможно, захотите начать сначала или перепрыгнуть к нужной вам теме.
- Пролог: Зачем нам тестировать?
- Часть 1: Тестирование идей
- Часть 2: Пользовательское тестирование
- Часть 3: Типы тестов
- Часть 4: Работа с аудиторией и анализ результатов ← Вы здесь
А теперь вернёмся к нашей аудитории.
Итак, давайте проведём предварительные результаты и сверим часы:
- Сформированный список гипотез — есть.
- Описанный роадмап тестирования — есть.
- Расписанные сценарии для пользователей — есть.
Кажется, всё готово, но нет. Прежде всего, наш тест нужно… протестировать. Вы не ослышались. Чтобы хорошо протестировать взаимодействие, нужно сначала протестировать сами тесты. А чтобы не путаться в этой рекурсии, придумали специальный термин — пилотное (или пилотажное) тестирование. Оно ничем не отличается от обычного тестирования, за исключением того, что вы проверяете не гипотезы, а формулировки и последовательность заданий. Пилотное тестирование предназначено для того, чтобы избежать путаницы в этой рекурсивной задаче.
Для этой цели вам могут подойти не только представители целевой аудитории, но и все, кто способны читать или слушать. Если ваши тесты не предназначены для узкой аудитории экспертов, то их можно проверить всеми.
Подходит и партизанское исследование, о котором мы говорили ранее. Пригласите коллег, родственников и даже тех, кто может быть не слишком опытен в данной области, но способен воспользоваться компьютером. Напоминаю, что базовые компьютерные навыки обязательны. Важно получить разнообразные мнения и отзывы.
Как только вы проведете несколько сессий на пилотной группе, с большой вероятностью вам захочется внести изменения в тесты: переформулировать, переставить, пересобрать. Не сдерживайтесь и делайте это.
Однако вскоре после проведения пилота и исправления сценариев вы столкнетесь с другой проблемой: сколько людей задействовать и как их найти? Эти вопросы зависят от того, какие данные вы хотите собрать: качественные или количественные.
Давайте начнем с качественного тестирования, так как оно, на первый взгляд, более простое в организации. Наиболее краткий ответ на вопрос о количестве респондентов для качественных тестов — 5–7 человек. Но вы, наверное, хотите узнать, как пришли к этой цифре, верно? Нет? Ну, допустим, я всё равно расскажу вам об этом уточнении. Если упростить, то такое количество людей позволит выявить 80% проблем, с которыми столкнутся 80% пользователей.
Конечно же, при помощи качественных тестов вы не сможете обнаружить все возможные проблемы — уж слишком много времени на это уйдет. Да и такой задачи перед нами не стоит: нам достаточно будет улучшить взаимодействие для большинства наших пользователей. Тем не менее, всё по-прежнему зависит от конкретного сетапа, ведь если вы проверяете какой-то очень маленький флоу, то и 7 человек будет более чем достаточно, чтобы выявить все проблемные места, и в то же время, если ваш тест включает в себя 30 разных сценариев, то 7 человек явно будет недостаточно.
Есть одна “лакмусовая бумажка”, которую я использую, чтобы понять, когда тест пора завершить — когда получаемые инсайты начинают повторяться. Как только вы перестаете получать новую информацию, смысла продолжать становится всё меньше.
Для количественных исследований числа будут совершенно другими. Здесь мы уже не можем отталкиваться от субъективных стимулов, чтобы определить, когда завершать наше безобразие. Здесь на сцену выходит статистическая достоверность. Если простыми словами, то статистическая достоверность достигается, когда вероятность получения данных, отличных от гипотезы, крайне мала. То есть крайне маловероятно, что результат будет сильно отличаться от имеющихся данных.
Опытный читатель может сомневаться в том, что такое “крайне мала”. Но здесь, к сожалению, нельзя дать точное числовое значение, так как величину отклонения определяют сами исследователи. Обычно они стараются поддерживать достоверность на уровне 80–85 процентов, так как дальнейшее увеличение требует значительных ресурсов.
Давайте рассмотрим пример. Допустим, вы хотите протестировать новое приложение для дэз-металистов, которое будет измерять частоту трясения волос. В этом случае важно определить вашу генеральную совокупность, то есть количество всех волосатых дэз-металистов, потенциально готовых использовать наше приложение. Если у вас уже есть база пользователей, она может выступать генеральной совокупностью, но лучше добавить к ней незанятую долю рынка для большей точности и обширности данных.
Вам также нужно определиться с однородностью ваших пользователей, насколько каждый отдельный металюга отличается от другого. В ретейле, например, однородность (или по-другому гомогенность) может быть низкой, а вот в специализированных сервисах, типа Wolfram, она довольно высока. Конечно, если вы не занимаетесь научными исследования и не хотите писать о своём тестировании статью в научный журнал, то гомогенность можно оставить за скобками и сделать предположение о том, что разница не внесёт существенных отклонений в результаты.
Но если «одинаковостью» людей можно поступиться, то вот на следующий параметр точно нужно обратить внимание. Репрезентативность — параметр, говорящий о том, можно ли будет обобщать результаты исследования на всю генеральную совокупность. Если проще, то соответствует ли наша пользовательская выборка всем параметрам генеральной совокупности. Вернёмся к металюгам. Допустим всего нашим приложением пользуется 10 000 любителей потрясти хаером. 10% из них солисты, 15% басисты, 25% гитаристы и 50% барабанщики. Если этот фактор оказывает существенное влияние на взаимодействие, то его нужно учитывать при подборе группы. Так вам тоже нужно набрать 10% солистов, 15% басистов, 25% гитаристов и 50% барабанщиков или близкие к этим значения. Иначе вы увеличиваете риски раскатать результаты на всю выборку и очень сильно обжечься. В тоже самое время, если 75% из любителей металла брюнеты, а 25% блондины, то это скорее всего никак не повлияет на репрезентативность, так что этим фактором можно пренебречь.
Ну и наконец, мы подходим к ответу на вопрос «Сколько респондентов взвешивать?» У меня ответа нет, но если вы уже определились с генеральной совокупностью, статистической достоверностью (её ещё называют Надёжностью), а также с уровнем погрешности, с которым готовы мириться, вы можете рассчитать объёмы самостоятельно.
Ну а теперь — забудьте всё, о чём я писал выше, ибо на практике такое тестирование явно невозможно поставить на рельсы, из-за того, что мы генерируем идеи и делаем прототипы слишком быстро, чтобы проводить тестирование на 350 респондентах (если только это не опросы). Чаще всего для целей тестирования все эти вычисления упрощают и сводят всё к формуле “Чем больше, тем лучше”. Тем не менее, ещё со времён написания моей магистерской диссертации, в моей голове засело число 60 респондентов, после которого можно говорить о прослеживаемой динамике. Однако сейчас я замечаю, что чаще всплывает размер в 30 человек. Главное, не допускать ошибку слишком маленькой выборки, когда мы принимаемся считать проценты от 7 человек.
Итак, дорогой мой читатель, если ты всё ещё со мной после всех предыдущих манипуляций, то я тебя поздравляю. Ты на финишной прямой. Нам осталось только разобраться с вопросом, где брать респондентов.
Если честно, всё, о чём мы говорили выше, не представляет большой проблемы, ведь анализ решения, создание гипотез, написание скриптов, создание теста, а также анализ результатов зависит только от вас. При должном уровне упорства и желания эти навыки можно очень быстро получить. Но вот поиск респондентов для немодерируемого тестирования — совсем другое дело. Можно даже сказать, что для нормальной работы вам нужно провести предварительную подготовку.
Если у вас уже есть продукт и пользователи, вы можете обратиться к ним за помощью. Всего лишь нужно собрать контакты желающих помочь с использованием специализированного инструмента или рассылки с опросником. Таким образом, вы лучше узнаете свою аудиторию и сможете легче подобрать выборку для теста.
Также вы можете обратиться за помощью к специализированным рекрутинговым агентствам или локальным менеджерам. Главное предоставить чёткий портрет пользователя, чтобы избежать работы с Валерой из подворотни.
Эпилог: Пост-тестирование
Наконец-то, наше путешествие в тестляндию подходит к концу. В финале я бы хотел дать вам несколько советов о том, что делать, когда всё веселье закончилось, и нужно обрабатывать данные и делать выводы.
Чего не стоит делать, как только вы получили свой набор данных, так это делать из него выводы. Соблазн сразу броситься в вычисление средних значений и медиан слишком велик, но поддавшись ему, вы можете получить выводы, абсолютно противоположные реальности.
Сперва данные нужно почистить, избавившись от нерелевантных результатов. Вот список того, на что стоит обратить внимание:
- Нулевые результаты, то есть нужно выпилить людей, которые даже не стартанули тест.
- Дубликаты (если есть такая возможность), устраните людей, которые выполнили тест несколько раз. Если дублирование есть только на части теста, то её и следует удалить, отдав предпочтение первому прохождению.
- Флуктуации, то есть абсолютно точно неверные результаты, например, когда у пользователя заняло 3 часа прохождение 2-минутного теста. Такие случаи требуют отдельного изучения, но для анализа теста не подходят.
- Мракобесие, можно отнести и к флуктуациям, но я предпочитаю выделять в отдельную группу результаты пользователей, целью которых была не прохождение теста, а баловство, прокликивание или тестовый прогон.
После того, как данные почищены, может оказаться, что теперь они не соответствуют минимальному размеру выборки или репрезентативности. Потому, я советую иметь некоторый запас респондентов, которыми можно будет добрать недостающий процент, или подумать об этом заранее и продолжать тестирование, пока данных не будет «с горочкой».
Ну теперь все данные дочищены, вымыты и блестят как лисий хвост. Пора вернуться в самое начало пути и посмотреть, какие гипотезы мы подтвердили, какие опровергли, а для каких получили смешанные результаты. Для этого мы как раз и описывали для них все эти KPI, которые сейчас и нужно вычислить (если этого ещё не сделали тест-тулы) и посмотреть, насколько они отличаются от гипотетических. Если отклонение достаточно сильное, то гипотезу нельзя считать полностью подтверждённой, и нужно внести в неё коррективы.
Если ваша гипотеза подтвердилась, я вас поздравляю, но и если гипотеза опровергнута мои поздравления остаются в силе. Расстраиваться нет причин, ведь вы получили новую информацию, которую сможете использовать в дальнейшем развитии продукта.
И вроде бы как всё, правда. Данные обработаны, гипотезы отработаны — финито. Но прежде, чем превращать выводы в действия, возможно, вы бы хотели ознакомиться с некоторыми особенностями нашего мозга, как, например, влияние статуса Кво или кривая обучения, которая даст вам понимание, как могут развиваться события в долгосрочной перспективе.
Например, если пользователи хотят делать работу, как и делали, то они с неохотой встретят новшества на тестировании, но со временем они не смогут представить без него жизнь. И в то же время, что-то новое может вызвать восторг во время тестов, только потому, что это новое, но после страсти улягутся и экстаз сменится плато.
И на этом наше путешествие заканчивается. Само собой, этот гайд не может охватить все аспекты тестирования, так что здесь я надеюсь на вашу помощь. Если у вас есть предложения по улучшению, вы нашли неточности, или просто хотите поделиться своим опытом — оставьте комментарий, и мы обязательно внесем нужные изменения.
Большое вам спасибо за внимание, ведь его потребовалось немало, чтобы дойти до конца. И тем не менее, я надеюсь, что эта работа помогла вам лучше разобраться в вопросе и вывести ваше тестирование на новый уровень.
Также напомню, что у меня есть канал в телеграм, где я ненавязчиво делюсь новостями, статьями и своими мыслями к ним.
