Хроники тестирования. Часть 3: Типы тестов
Добро пожаловать в третью часть Хроник Тестирования — цикла статей, посвященных валидации идей или решений. Если вы здесь впервые, то, возможно, захотите начать сначала или перепрыгнуть к нужной вам теме.
- Пролог: Зачем нам тестировать?
- Часть 1: Тестирование идей
- Часть 2: Пользовательское тестирование
- Часть 3: Типы тестов ← Вы здесь
- Часть 4: Работа с аудиторией и анализ результатов
А теперь вернёмся к типам тестов.
Сейчас мы с вами познакомимся с доступными методами тестирования или освежим ваши знания о них. Для лучшего восприятия каждого метода я предоставлю небольшой обзор. Сначала расскажу, зачем нужен данный метод, затем углублюсь в его особенности подготовки и проведение и опишу, какие результаты можно ожидать, и в конце расскажу о возможных сложностях, с которыми вы можете столкнуться.
Обратите внимание, что в начале я говорю о том, зачем нужен метод, но это только самый распространенный случай его использования. На самом деле, как я уже упоминал, эти метки условны и рекомендательны. Ничто не мешает вам искать альтернативные способы применения, так что не стесняйтесь экспериментировать.
Для лучшего понимания, что из себя представляет тест, я создал для вас живые примеры с использованием нашего продукта Display. Он пока абсолютно бесплатный я буду очень рад, если вы дадите любую обратную связь. Мы всё слушаем и делаем :)
Опросы и фоллоу-апы
Ничёси, первый метод и тот не по теме. Опросы — это скорее методы качественного и количественного исследования, но без них сложно себе представить любое тестирование.
Зачем нужны
Даже если вы проводите тестирование юзабилити, которое предполагает четкое следование сценарию, после его завершения всегда хочется задать вопрос вроде «Ну, как вам?». Эти вопросы называются “follow-up questions” или, по-русски, “последующие”. Они могут обогатить ваши данные и позволить взглянуть на результаты с другой стороны. Например, тест юзабилити может быть пройден без ошибок, но оценка взаимодействия осталась низкой. Это означает, что пользователи смогли завершить сценарий, но поставили низкие оценки всему процессу целиком. Таким образом, проблема кроется в другой спице зонтика UX.
Как проходит
В принципе, здесь нет ничего сложного. Вы задаете вопрос, и человек отвечает. Главное — правильно сформулировать этот вопрос. Как я уже неоднократно упоминал, вам сначала нужно понять, какую гипотезу вы проверяете и какие данные вам для этого нужны. Если у вас есть возможность сформулировать вопрос напрямую — здорово, но часто бывает полезно разбить проверку гипотезы на несколько вопросов, чтобы лучше понять причины ответов.
Давайте рассмотрим наш случай с удалением страницы подтверждения заказа в интернет-магазине. После сценарного теста вы хотите проверить, насколько пользователи довольны.
Не стоит просто спрашивать: «Ну как вам, стало лучше?» — это слишком общий вопрос. Вместо этого вы можете попросить участника оценить взаимодействие на пятибалльной шкале и объяснить свой выбор. Затем вы можете уточнить, что можно было бы улучшить, чтобы получить более высокую оценку.
Кроме того, вам может потребоваться дополнительные вопросы для сортировки участников по разным корзиночкам, чтобы впоследствии было легче выявить связь между параметрами. Например, вы можете узнать роль участника и затем сравнивать группы между собой.
После того, как вы сформулируете вопросы, нужно озаботиться выбором правильного способа на них ответить. Для открытых вопросов дело труда не составит: пользователь всё равно должен будет что-то написать. Для этого можно использовать стандартные контролы инпута или текст-эрии в зависимости от ожидаемого ввода. Но вот с остальными типами нужно подумать получше.
Если вы хотите, чтобы пользователи выбирали из предложенных вариантов, уделите немного времени их продумыванию. Их не должно быть слишком много, чтобы не нарушать принцип Барри Шварца, но и не слишком мало, чтобы учесть разнообразие мнений. Также обратите внимание на диапазон ответов — согласовывайте его с реальностью, исключая невозможные или маловероятные варианты, и предоставляя поле “Другое”. Если речь идет о NPS или CSat (хотя они ограничены в применении в тестировании), выберите подходящую шкалу: числа, звезды или эмодзи, а также определитесь с количеством вариантов для выбора. Все это зависит от того, как вы планируете обрабатывать полученные данные.
Я не буду углубляться в эту тему слишком глубоко, чтобы не превратить этот текст в статью о проведении опросов. Тем не менее, я надеюсь, что эти советы окажутся полезными для вас.
Советы
- Будь то модерируемый диалог или удаленный опрос, нельзя просто взять и спросить у пользователей об их будущем отношении, а-ля «Вы бы купили такой продукт?»Пользователи склонны моделировать свой опыт и, как и все люди, делают это не слишком хорошо. Вместо этого, интересуйтесь фактическим прошлым опытом.
- Сформулируйте вопрос максимально понятно, без использования одному Господу известных терминов и сленга.
- Избегайте отрицаний, если говорите о дороговизне, то не говорите «недешёвый», скажите «дорогой».
⚡️ Попробовать в действии:
Карточная сортировка (Card sorting)
Зачем нужен
Оригинально, данный метод используется для подтверждения гипотез, связанных с информационной архитектурой. Однако он также хорошо зарекомендовал себя и в других областях, таких как приоритизация свойств.
Как проходит
В качестве базиса, данный тест использует строго заданный набор сущностей. Чаще всего это названия разделов сервиса или другие элементы информационной архитектуры, их называют карточками.
Суть метода заключается в том, что мы предоставляем респонденту этот набор и просим рассортировать карточки по коробочкам-категориям. Иногда “коробочки” строго заданы, и пользователь может просто раскладывать карточки по ним. А иногда респонденты могут создавать категории сами в зависимости от собственной ментальной модели организации и подписывать их «маркером».
Вариант с фиксированными категориями будет полезен, когда мы не можем менять устоявшуюся иерархию или хотим использовать тест для приоритизации. В таком случае, карточками могут выступать как свойства продукта, так и потребности пользователя, которые мы хотим удовлетворить. В таком случае, они распределяются по четырем бакетам (на примере свойств продукта):
- Must — жизненно необходимое свойство, без которого продукт теряет смысл,
- Should — конкурентные преимущества, которые имеют значительный вес,
- Could — было бы здорово заиметь такое свойство, но не сказать, что без него не обойтись,
- Wouldn’t — этого делать точно не стоит.
Выход
На выходе мы получаем качественную модель одного респондента о том, как, по его мнению, правильнее сгруппировать предложенные элементы. Тем не менее, на общем уровне теста, при достаточно большой выборке, данные могут быть аппроксимированы и приобрести количественный характер.
Советы
- Если карточек слишком много, не пытайтесь впихнуть их все в один тест. Возможно, вам стоит ограничить количество карточек на респондента, чтобы сохранить его мозг в целостности. А результаты собирать из множества кусочков.
- По умолчанию, я бы советовал оставлять для пользователей возможность создавать свои категории, так как иначе вы подталкиваете респондента к ожидаемому ответу.
- Если решили использовать карточную сортировку для приоритезации, то давайте чёткое определение категориям, иначе вы оставляете для респондента простор для воображения.
Древовидный тест (Tree testing)
Зачем нужен
Брат-близнец карточной сортировки, его также называют обратной карточной сортировкой. Он служит точно такой же цели — проверке пригодности созданной вами информационной архитектуры.
Как проходит
Всё точно наоборот, как в случае карточной сортировки. Теперь пользователю на вход подается готовая многоуровневая структура, и его задачей является отыскать нужный пункт. Никакой сортировки не происходит, только поиск и выбор нужного пункта.
Выход
В результате теста мы получим качественное представление о том, работает ли наша информационная архитектура или нет. Об этом будут свидетельствовать низкое время поиска и количество мискликов или неверных раскрытых категорий.
Советы
- Однозначно объясните респонденту, что будет происходить во время теста, и чего вы от него ожидаете, иначе человек может по ошибке начать открывать всё подряд.
- Не нужно прятать искомые пункты слишком глубоко, иначе вы экспоненциально наращиваете сложность теста.
Тест предпочтения (Preference test)
Зачем нужен
Этот тест является одним из самых простых и помогает выявить, какой из предложенных вариантов предпочитают респонденты. Он подходит для сравнения практически всего, кроме, разве что динамических вещей, таких как взаимодействие.
Как проходит
Тут тоже мало что можно сказать: пользователю предоставляются варианты для выбора, и он делает свой выбор. Обычно после теста следуют уточняющие вопросы, направленные на разъяснение причин выбора или оценку степени различий.
Выход
На выходе мы получаем пропорцию распределения пользователей по предпочтениям. А что делать с этой пропорцией, мы обсудим дальше.
Советы
- Сам по себе данный тест не слишком информативен, то есть несёт количественную меру предпочтений, но не даёт понимания, почему она такой получилась.
- Не стоит предлагать на выбор больше 4 вариантов, так как иначе внимание респондентов рассеется, как и их распределение.
- Изучите инструмент, в котором хотите проводить подобное тестирование и обязательно проверьте, как пользователь будет сравнивать и выбирать, так как это может оказать значительное влияние на результат.
⚡️ Попробовать в действии:
Пятисекундный тест (5-sec test)
Зачем нужен
Этот тип теста применяется для оценки распределения внимания пользователей, например, насколько четко структурирован макет или какие элементы имеют больший вес. Аналогично тесту предпочтений, этот тип теста не имеет сам по себе большого смысла и оценивается в связке с последующими вопросами.
Как проводить
Как можно догадаться из названия, в течение 5 секунд респондент изучает предложенное изображение, после чего тест завершается, и можно начинать задавать ему вопросы. Если это был макет страницы, можно спрашивать, какой элемент первым бросился ему в глаза, что он запомнил, или задавать более конкретные вопросы о расположении элементов. Здесь важен не столько сам результат теста, а и уточнения, которые следуют после него.
Выход
Ничего. Вся информация собирается последующими вопросами.
Советы
- Не обманывайтесь скрытой простотой, такой тест может очень быстро вскрыть проблемы дерьмовой визуальной иерархии или неверного первого впечатления. Так что не ставьте на этом тесте крест.
⚡️ Попробовать в действии:
First click test
Зачем нужен
Для определения ясности восприятия пользователем органов управления или визуальной иерархии.
Как проводить
По сути, это пяти-секундный тест на стероидах: временного ограничения здесь нет, вместо этого респонденту предоставляется задание — найти определенную информацию или выполнить определенное действие, и сделать соответствующий клик. Всего один клик. Поэтому этот тест так и называется.
Задания при этом формулируются так, чтобы исключить возможность случайного клика, то есть сразу предупреждать о том, что у респондента будет всего один клик.
Выход
На выходе, чаще всего вы получите тепловую карту распределения кликов и сможете даже посчитать пропорцию ожидаемого восприятия ко всем пользователям.
Советы
- Для мобильных устройств проверьте, чтобы платформа правильно считывала тапы и скролы, иначе получите искажённую картину.
⚡️ Попробовать в действии:
Alpha & Beta tests
Зачем нужен
Чтобы проверить соответствие конечного продукта ожиданиям пользователей, выявить баги и недоработки, а также сформировать базу лояльной аудитории, дабы официальный релиз прошёл проще.
Как проходит
Альфа и Бета тесты не самые распространённые среди описанных мною тестов из-за того, что для их корректной отработки продукт должен быть почти завершён. Кстати говоря, это не полноценные методы, а скорее фазы одно и того же метода. Суть его заключается в том, что мы запускаем определённую группу пользователей за закрытый периметр (закрытый сервер), чтобы они могли ознакомиться с ранней версией продукта, дать фидбэк и протестировать функционал.
Отличие Alpha от Beta состоит в том, что первые более багованные и располагаются на внутреннем сервере и тестируются за счёт внутренних команд (разработчиков, БА, сейлзов). А в Бете предлагают поучаствовать реальным пользователям.
Выход
После альфы или беты вы получите кучу обратной связи от пользователей, обнаружите кучку поменьше багов. При этом, их можно использовать во время составления, так называемой ролл-аут стратегии, то есть сценария выхода в продакшен. Дело в том, что если вы ограничите пользовательский сегмент и сможете грамотно отработать всю обратную связь, то вы обзаведётесь армией апологетов, которые бесплатно будут продвигать ваш продукт и создавать нужный вам ажиотаж.
Советы
- Позаботьтесь о правильном подборе испытуемой группы. Позаботьтесь о разнообразии группы, чтобы покрыть как можно больше сценариев.
- Используйте регрессивное тестирование, чтобы убедиться, что вы не поломаете ничего во время исправления прошлых ошибок.
Мультивариантные тесты (A/B/n)
Зачем нужен
Для сравнения эффективности двух и более вариантов дизайн-решений одной и той же задачи. Он также известен как Split-testing.
Как проводить
Кратко говоря, для проведения такого теста необходимо подготовить несколько вариантов дизайна, будь то в прототипе или на продакшене. Затем случайным образом распределить пользователей между этими двумя вариантами и оценить, какое из решений показывает наилучший результат. Но чтобы все прошло без ошибок, нужно учесть несколько ключевых моментов.
Во-первых, необходимо определиться с тем, какая «линейка» будет использоваться для сравнения. Не всегда возможно получить абсолютную победу одного из вариантов, так как у каждого из них могут быть свои сильные и слабые стороны. Поэтому важно спрогнозировать ожидаемые изменения и приоритизировать метрики, чтобы не впасть в ступор при объявлении победителя.
Во-вторых, вам нужно определиться, что вы будете тестировать. Тоже очевидно? А вот и нет. Представьте, что перед вами стоит задача: “Определить, что лучше использовать для презентации товаров, чтобы увеличить конверсию: лист или карточки”. Для получения однозначных результатов, вам следует использовать один и тот же набор данных и контекст. Иначе вы не сможете сказать с полной уверенностью, что именно повлияло на ваши метрики. Если вы тестируете вид, то тестируйте вид, и не добавляйте новых гипотез, иначе вы просто не сможете выявить корреляции.
В-третьих, вам нужно убедиться в равномерности распределения и достаточной диверсификации пользователей, то есть сделать распределение не совсем случайным (если у вас есть возможность влиять на него). Это необходимо, чтобы снизить риски, связанные с неравномерным распределением нерелевантных пользователей в одной из групп, что может исказить результаты.
Когда данный метод используется на продакшене, для варианта-кандидата выделяют часть основного трафика и сравнивают результаты с текущей версией. Такой подход имеет ряд недостатков, таких как кривая обучения или эффект новизны. Пользователи могут отвергать новый подход в пользу существующего или, наоборот, быть в восторге от чего-то нового, только потому, что это “новое”. Например, в экспериментах с конвейером, когда условия труда рабочих менялись в лучшую или худшую сторону, они воспринимали любые изменения как положительные. Так что, если вы хотите делать всё чётко, вам следует выделять отдельные потоки для каждого варианта и предусмотреть контрольную группу, в которой ничего не будет меняться.
Выход
После А / Б / n тестирования мы получим количественные данные о взаимодействии каждой из групп пользователей. Конечно, мы также можем дополнить тест последующими вопросами и попытаться сравнить ответы между ними, но такой подход подходит только для контролируемой среды.
Советы
- Прежде чем тестировать что-то, подумайте о том, как вы будете выбирать победителя.
- Концентрируйтесь на одной переменной за раз.
- Сравнение должно вестись в одинаковой, естественной среде, чтобы минимизировать влияние.
- Не предоставляйте пользователя доступ сразу к нескольким вариантам, это может сбить пользователя с толку и внести персональную оценку в результаты.
- Для того, чтобы сделать правильные выводы, выборка вариантов должна быть достаточно большой, чтобы говорить о статистической достоверности (о ней, далее).
Партизанское тестирование (Guerilla testing)
Зачем нужен
Чтобы максимально быстро, грубо, но эффективно тестировать свои идеи без привлечения бюджета и значительных усилий. Также известно, как Партизанское тестирование.
Как проводить
Тут существует множество вариаций, начиная с насильственного опроса коллег, сидящих рядом, и заканчивая практически полноценным пользовательским тестированием. Давайте рассмотрим более серьёзный вариант.
Сначала вам нужно определиться с областью тестирования, где вам нужна помощь. Как мы уже знаем, просто спросить “Ну как тебе?” не слишком эффективно. Лучше всего выразить все ваши мысли и вопросы в виде гипотез и составить из них сценарий тестирования, как мы уже говорили выше. Даже если это кажется пустой тратой времени, сессия станет более структурированной. Помните, что вам не следует выходить за 15–20 минут, иначе вы просто утомите вашего визави, поэтому оставьте только необходимое.
После написания сценария, или даже протокола, мы можем перейти к поиску респондентов. Тут кроется основное отличие партизанских методов от полноценного пользовательского тестирования, потому что респонденты не всегда являются вашими конечными пользователями. Тестируйте с теми, кого найдете. Работаем, как говорится, с тем, что есть.
Вы можете возразить: но как же так, ведь мы получим ненадежные данные! Да, но они будут ненадежными только для частей взаимодействия, которые требуют специальных знаний. А если мы хотим проверить общие паттерны восприятия, то они не слишком отличаются от человека к человеку, ведь мы все так или иначе люди.
Тем не менее, не стоит тестировать на таких же экспертах, как вы. С опытом, некоторые сложные вещи уже кажутся нам обыденными, и мы склонны полагать, что это происходит у всех. Но это не так. Мы с вами находимся на острие домена, мы, можно сказать, 10% людей, обладающих сакральными знаниями о проектировании, в то время как 90% населения испытывают трудности при работе с электронной почтой. Поэтому для большей наглядности лучше отойти подальше от дизайн-отдела.
Итак, как только на горизонте появится подходящий кандидат, вам нужно получить его согласие и провести сессию максимально непринужденно. О том, как сделать это правильно, мы поговорим в следующем тесте. Но замечу, что скорее всего все не пойдет по плану, поэтому вам нужно сохранять гибкость и адаптироваться под то, как проходит тест. Только не нарушайте личные границы и не будьте слишком назойливыми. Вполне нормально, если вы сможете проверить не все, что хотели.
В завершение, никто не ожидает от вас каких-то отчетов, так что все инсайты, которые вы получите, останутся в вашей голове. Конечно, было бы здорово задокументировать все инсайты, чтобы в будущем не изобретать лишнего, но никто не требует этого.
Выход
После партизанского тестирования вы получите сырые качественные данные, которые точно не обладают научной достоверностью, но могут уберечь вас от ошибок на раннем этапе.
Советы
- Даже для коленочного тестирования попробуйте сформулировать область, в которой вам нужны, а лучше написать сценарии.
- Тестируйте только общие паттерны, специальные знания оставьте для полноценного исследования.
- Не тестируйте на дизайнерах, они слишком много знают.
- Во время тестов делайте пометки, чтобы освежить в памяти факты, а не придумывать свою историю.
Тестирование юзабилити (Usability tests)
Зачем нужен
Проверяет только возможность пользователя завершить свой сценарий, без его качественной оценки. Многие путают User testing и Usability testing, думая, что это одно и то же. Однако терминология говорит, что Usability тестирование проверяет только один аспект взаимодействия — фактическую возможность завершения сценария, в то время как User тесты рассматривают взаимодействие с разных сторон.
Как проводить
Читая дальше, помните, что речь пойдёт о тестировании Usability. Исходя из того факта, что тестирование проверяет только возможность выполнения определённых действий, нужно начать с составления алгоритма этих действий. Открывайте ваши JTBD или персоны и выбирайте те цели и задачи, которые пользователь должен решить при помощи спроектированного вами интерфейса. Если нужно, и они кажутся вам слишком большими, разбейте флоу достижения целей на кусочки-сценарии. Только смотрите, чтобы их не получилось слишком много: 4–5 оптимальное число для теста.
Начинайте распутывать клубок сценария, описывая каждое действие, которое пользователю нужно совершить. Да, звучит немного дико, совсем не так, как мы привыкли, как это так, как для дурачков что ли? Да, именно так. Давайте вашу руку и попробуем вместе на примере.
Цель: Совершить заказ в интернет магазине.
Действия:
- Перейти в каталог товаров
- Перейти в раздел «Убийственные колонки»
- Найти колонки «Marshall Kilburn II»
- Добавить колонки в корзину
- Перейти в корзину заказа
- Заполнить форму и нажать «Купить»
Шаги могут быть ещё более детализированными в зависимости от вашей степени безумия.
После написания такого… скрипта, вы можете уделить время вашему вступительному слову, где вы будете приветствовать респондента, успокаивать, вести небольшой разговор. Помните, что если вы тестируете прототип, важно объяснить пользователю, что некоторые части взаимодействия могут не работать или работать некорректно.
Также хорошим тоном будет заверить человека в том, что мы тестируем не его, а наш интерфейс, и здесь нет правильных или неправильных ответов. Респондент может очень помочь, указав нам на места интерфейса, которые вызывают сомнения, вызывают раздражение или просто непонятны. Это очень важно.
В далекие 201Х-е, когда люди ещё не уходили в интернет, такие тесты часто проводились очно и зачастую под руководством модератора. В классическом варианте модератор сидел рядом с пользователем, сохраняя спокойное лицо, наблюдая за пользовательскими трудностями в поиске кнопки “Добавить в корзину”. Он ставил крестик напротив пункта в сценарии, когда мучения респондента заканчивались. Это означало, что тест провалился, и необходимо пересмотреть этот шаг в потоке. Как вы понимаете, сейчас редко кто следует каноничному сценарию, так как он жесткий и затратный. Зачастую предпочтительнее провести тестирование пользователями.
Выход
После прохождения этого «старичка» вы получите качественное представление о возможности пользователя завершить сценарий, и определите на каком этапе возникают проблемы.
Советы
- Из-за своей негибкости, тест может показаться устаревшим и ненужным, однако дайте ему шанс. Я думаю, что ещё остались случаи, когда он сможет быть полезен. Например, когда взаимодействие настолько сложное, что вы хотите протестировать его в несколько этапов.
Пользовательский тест и тест юзабилити я поместил в один тест в следующем разделе, чтобы лучше ощутить разницу.
Пользовательское тестирование (User testing)
Зачем нужен
Апогей человеческой мысли. Шутка, конечно, но на данный момент — это самый распространенный и качественный метод тестирования пользовательского взаимодействия. Нужен он для получения полной картины: от восприятия цветов, до причин возникновения проблем юзабилити, уходящих корнями в детство респондента.
Как проводить
Данное тестирование очень похоже на Usability testing, только вы не ограничиваете пользователя строгим набором действий, а даёте ему некоторую свободу в достижении цели. И тем не менее, сценарии придется все равно написать.
Как всегда, здесь нужно начинать с гипотез. Составив их список (и, надеюсь, он у вас всегда под рукой), нужно отсортировать их по времени возникновения, чтобы не переключаться по разным темам и не говорить смущенно: “А помните, там, где вы…”. У каждой гипотезы должно быть свое место.
После получения четкого представления о том, где, когда и что нужно узнать, можно сгруппировать гипотезы по логическим структурам и для каждой из них назначить метод проверки по уже знакомой нам схеме. Где-то нам нужно просто наблюдать за поведением, где-то задавать уточняющие вопросы, а порой даже бездействие пользователя может быть достаточным. Но чаще всего мы просто попросим пользователя что-то сделать. При этом не нужно расписывать каждый шаг, как при Usability тестировании. Достаточно коротко и ясно сформулировать, что вы хотите от пользователя.
Лично я предпочитаю объединять все задания в одну историю, где каждый следующий шаг дополняет предыдущий. Добавив к этому вводный контекст, мы получим эффект почти полного погружения, а не простого допроса. Сторителлинг подходит как для модерируемого, так и для немодерируемого тестирования. Единственное, что вам не удастся провести в таком случае, это сессия мыслей вслух. Хотя, если постараться, то все возможно.
Мысли вслух — это метод проведения пользовательского теста, при котором респондент практически никогда не должен замолкать, снабжая каждое свое действие подробным комментарием о том, что он думает в данный момент, чего ожидает и как рассуждает, решая задачу. Этот поток сознания — настоящая кладезь бесценных знаний о ментальной модели пользователя. Однако поддерживать такой режим может быть настоящей задачей.
В интернетах сегодня каждый хочет высказаться о том, что думает. Но на юзер-тестах, по какой-то причине, люди предпочитают молчать. Чтобы преодолеть этот барьер неловкости, можно предпринять следующие шаги:
- Перед сессией объясните правила игры. Расскажите, что вам нужна помощь респондента в улучшении вашего продукта, для чего вы попросите его выполнить несколько заданий, попутно отвечая на уточняющие вопросы. Уверьте человека, что тут проверяется не его интеллектуальные способности, а ваше решение, и что любой инпут будет невероятно полезен.
- Объясните, что хотите, чтобы человек рассуждал вслух, озвучивая свои мысли, пусть это может быть слегка непривычно. Покажите, что именно вы хотите получить на своём примере. Сами порассуждайте вслух, используя первую попавшуюся страницу в интернете. Так люди раскрепощаются и не боятся показаться глупыми, а задно, ваш пример даёт им примерные границы, до какой степени стоит оголять своё безумие.
- Начните с выполнения первого задания, и первое время напоминайте пользователю думать вслух прямыми вопросами «О чём вы сейчас думаете?» или «Что вы ищите на странице?» или «Какие эмоции у вас вызвало это действие?».
- Не нужно подталкивать респондента к нужным вам выводам, хоть это бывает и очень сложно. Главное здесь не думать за пользователя, как бы вам того не хотелось, а дождаться его мыслей. Уже после вы можете повторить, что он сказал, уточняя «Всё так?», чтобы избежать двойного трактования.
Во время немодерируемого тестирования, конечно, у вас не получится задавать вопросы по ходу выполнения задания, но кое-что вы сможете спросить уже после. И даже при таких ограничениях вы полностью исключите собственное влияние и влияние среды, ведь человек будет проходить тест в привычной ему обстановке.
Модификация RITE. Обычно, вы хотите назначить тесты поплотнее друг к другу, чтобы не растягивать сопли и получить ответы как можно скорее. Такой подход плотных испытаний даст вам чистые данные за короткий срок, однако, если вашей главной целью является не красивый научно-достоверный отчёт, а адаптация решения под нужды пользователя, то у меня для вас подгон.
До него, в принципе, можно было бы и логикой дойти, но раз за нас уже кто-то подумал и дал этому название, то почему не использовать его. Представьте, что после первого теста вам стало кристально ясно, что некоторые части флоу поломаны настолько, что и к бабке не ходи, другие респонденты тоже споткнуться об эти ошибки. Зачем вам проводить ещё сессии тестов, если вы можете исправить ваш прототип, и проверить уже новую версию? Звучит логично. Конечно, не всё, о чём говорят пользователи стоит сразу же исправлять. Прежде, чем пороть горячку лучше бы посмотреть на популярность найденной проблемы, занеся её в список ваших гипотез и адаптируя скрипт. А кто сказал, что его нельзя менять?
При этом вы потеряете достоверность для всей выборки, ведь вы будете показывать респондентам разные решения, так что не получится потом свести всё в таблицу с процентиками. Зато вы сможете исправить ваше решение быстрее и за меньшие деньги, а заодно сэкономите время людей.
А когда заканчивать этот цикл? Допустим, после исправления, ещё два респондента прошли тест на отлично, а третий споткнулся на чём-то другом. Тогда счётчик сбрасывается и вам нужно начинать снова, пока не набьёте комбо из 5 успешных завершений… или пока не закончится бюджет.
Выход
В зависимости от выбранной методологии проведения теста (а мы говорили, что почти все типы тестов могут превращаться из модерируемых в немодерируемые и обратно), мы можем получить как качественные данные о субъективном восприятии с анализом корневых причин, так и количественные данные, говорящие о популярности проблем и снижении рисков аппроксимации (когда мы обобщаем полученные выводы на всю выборку).
Советы
Я уже довольно много чего рассказал во время описания теста, но в завершении ещё пара заключительных мыслей:
- Не делайте сверх-маленькие тесты на один клик, лучше заменить этот костыль специализированным 1st click test.
- По мере прохождения теста подбадривайте респондента, чтобы он не устал раньше времени. Благодарите по завершению, ведь даже если ваше решение разнесли в щепки, пользователь в этом не виноват, а наоборот, помог вам стать лучше.
- Не нужно задавать уточняющие вопросы про прошествию времени — каждому вопросу своё время, иначе вы получите искажения.
⚡️ Попробовать в действии:
Также напомню, что у меня есть канал в телеграм, где я ненавязчиво делюсь новостями, статьями и своими мыслями к ним.
