Хроники тестирования. Часть 2: Пользовательское тестирование
Добро пожаловать во вторую часть Хроник Тестирования — цикла статей, посвященных валидации идей или решений. Если вы здесь впервые, то, возможно, захотите начать сначала или перепрыгнуть к нужной вам теме.
- Пролог: Зачем нам тестировать?
- Часть 1: Тестирование идей
- Часть 2: Пользовательское тестирование ← Вы здесь
- Часть 3: Типы тестов
- Часть 4: Работа с аудиторией и анализ результатов
А теперь вернёмся к пользовательскому тестированию.
С идеями, кажется, мы разобрались. Если ваша идея прошла через мясорубку валидации и до сих пор жива — поздравляю. Вероятно, вы уже даже успели создать прототип. Тем не менее, перед тем как ваш продукт увидит свет, ему предстоит пройти ещё много испытаний.
Мы будем рассматривать ситуацию, когда наша идея уже приобрела форму, либо в виде прототипа, либо в виде работающего продукта. Итак, мы переходим от абстрактного (идей) к более конкретному, тому, что можно смело показывать пользователям. Методы и инструменты могут немного различаться, но основной нарратив останется неизменным.
Именно поэтому, так как в тестах пользователи будут играть основную роль, этот процесс называется пользовательским тестированием. Но в зависимости от целей и контекста, методы тестирования могут различаться. О конкретных типах тестов мы поговорим чуть позже, а пока давайте разберемся с общими принципами.
Как готовить тесты?
Как бы странно это ни звучало, но ещё три года назад большинство дизайнеров практически полностью игнорировали тестирование. В лучшем случае, они ограничивались партизанским тестированием, о котором мы поговорим позже. Хоть это и было лучше, чем ничего, эффективность решений для конечных пользователей оставалась загадкой. Однако сегодня рынок тестирования стал более взрослым и зрелым: появилось множество решений, способных поддержать это важное начинание за небольшие деньги, и теперь тестирование стало неотъемлемой частью процесса.
Но, как наверняка догадались, нельзя просто показывать пользователям яркие картинки и спрашивать: “Что вы думаете?” Хотя, технически можно так поступать, но результаты будут ненадежными. Пользователи — это эмоциональные существа, и их ответы могут зависеть от множества факторов, начиная от погоды за окном и заканчивая запахом вашего одеколона. Поэтому вместо слов следует оценивать факты, и даже не все факты, а только те, которые имеют значение.
Если у вас на примете уже есть кандидат на тест, то давайте вместе, шаг за шагом спланируем ваше тестирование. Как раз для этого я подготовил простой шаблончик. Копируйте его, открывайте и давайте начинать.
Определение цели и критериев успеха
Напоминаю, что мы обсуждаем пользовательское тестирование, что означает, что у нас уже есть решение, которое мы хотим оценить. Прежде чем приступать к рекрутингу участников, нам необходимо определить цель тестирования и критерии успеха.
Задайте себе вопрос: “Чего я хочу достичь через это тестирование?” и “Как я узнаю, что тестирование дало результаты?”. Ответ “я хочу получить отчет о тестировании” — пустой звук, так как в этом случае вы просто получите тестирование ради тестирования. Важно удостовериться, что цель соответствует ожиданиям стейкхолдеров, чтобы избежать ситуации, когда результаты тестирования окажутся бесполезными.
Давайте рассмотрим живой пример. Предположим, у вас есть идея сократить время процесса оформления заказа на вашем интернет-магазине, убрав этап подтверждения заказа. Ту, якобы бесполезную страницу, на которой отображается вся информация, которую пользователь ввел 3 секунды назад. Зачем ему повторно на них смотреть? Вы создали прототип и хотите провести тестирование этой идеи. В этом случае цель могла бы быть сформулирована следующим образом:
Цель тестирования: определить, обладает ли новый подход к оформлению заказа значительными преимуществами по сравнению с текущим и принять решение о его внедрении.
Критерии успеха. Новый процесс будет считаться успешным, если:
- Среднее время завершения сценария оформления заказа сократится более чем на 10% по сравнению с текущим процессом.
- Количество ошибок, совершаемых пользователями, уменьшится более чем на 15% по сравнению с текущим процессом.
- Уровень удовлетворенности пользователей (CSat) увеличится на 1 пункт.
В этом примере мы сначала определили, на какие вопросы мы сможем ответить при помощи тестирования, а затем разработали критерии для измерения успеха. Необязательно формулировать все детали на 100%, так как после получения дополнительных данных можно будет уточнить цели и критерии успеха. Это, можно сказать, широкие мазки.
Определение гипотез
Откровенно говоря, этот этап должен был быть уже проделан вами, ведь вы создавали решения на основе каких-то предположений, не так ли? Ведь вы не просто взяли и сгенерировали какую-то картинку, которую хотите показать пользователям? Надеюсь, что нет.
Но подождите секундочку, разве мы не говорили о гипотезах в самом начале? Да, такой я мамкин Тарантино. Но если вы помните, то основу нашего тестирования составляли, скорее, продуктовые гипотезы — предположения о том, как изменится состояние продукта в ответ на наши действия. И какие-то из этих продуктовых гипотез, несомненно, похожи на цель нашего тестирования. Но в нашей подготовке мы должны погрузиться глубже.
Вам нужно декомпозировать ваше предположение на множество более конкретных элементов, сосредоточившись на ментальной модели пользователя. Лично я стараюсь посмотреть на решение с точки зрения пользователя и предвидеть, что для меня могло бы быть непонятным, где во взаимодействии могут возникнуть пробелы, какие термины могут вызвать у меня интеллектуальный ступор и так далее. Все эти предположения аккуратно включаются в список гипотез для проверки, дополняя “главные”.
После того, как предположения сформулированы, не помешает также прописать для каждого из них KPI (ключевые показатели эффективности), на которые мы будем смотреть во время тестов, чтобы подтверждать или опровергать их.
Выделение целевой аудитории
Как и с выделением гипотез, определение вашей целевой аудитории может предшествовать любому тестированию, и я не могу недооценить этот важный этап подготовки. Вместе с важностью понимания, что и как вы тестируете, также критически уделить внимание, на кого вы будете ориентироваться в ходе ваших экспериментов. От определения целевой аудитории во многом зависит итоговый результат исследования, так как неправильный выбор аудитории может сильно исказить факты. Например, если вы разрабатываете приложение для финансовых брокеров и тестируете его на своих друзьях-дизайнерах, то вы можете получить низкие оценки удовлетворенности с комментариями типа “недостаточно свободного места” или “неудачный шрифт”, которые на самом деле не имеют значения для целевой аудитории — брокеров.
Прошу прощения за некоторую строгость, но я уже не раз сталкивался с ситуациями, когда люди не учитывали важность фразы «Вы не ваши пользователи» и не видели разницы в выборе аудитории для тестирования.
Лично я предпочитаю работать с аудиторией через создание персон и пытаюсь понять их мотивы, цели и задачи (и, если возможно, их ментальную модель), а затем соотношу их с нашими гипотезами. Например, если у меня есть гипотеза о том, что удаление страницы подтверждения ускорит процесс оформления заказа, я должен понять, насколько пользователь ценит скорость и готов ли он принимать риск возможной ошибки ради этой скорости. Если у меня есть сомнения даже на этом этапе, то тестирование может не иметь смысла и стоит вернуться в лабораторию для проведения дополнительных исследований.
Учитывая вашу целевую аудиторию, вы обеспечиваете более точное тестирование и защищаете себя от ошибок еще на этапе создания теста, а также от неправильной интерпретации результатов. В конечном итоге, это поможет вам избежать ситуации, когда вы ускорили процесс, но сломали все остальное. Хотя, конечно, можно будет поправить поломанное и предоставить клиенту еще один счет, не так ли?
Создание роадмапа тестирования
Когда вы полностью осознаете цель тестирования и необходимые критерии для определения его успешности, приходит время обратить внимание на гипотезы и KPI. Важно размышлять о том, как можно получить данные, подтверждающие или, лучше всего, опровергающие гипотезу. Дело в том, что данные могут быть собраны разными способами, но не всегда результаты будут надежными и достоверными.
Иногда, для достижения высокой достоверности, одного метода тестирования недостаточно. Качественные методы тестирования могут помочь обогатить список гипотез и отследить появление проблем, но они не всегда подходят для аппроксимации результатов на всю целевую группу. Для подтверждения актуальности проблемы часто используют количественные методы тестирования, где гипотезы подкрепляются данными.
Например, если пользователь жалуется, что новый дизайн не вмещается на его экран, и предлагает уменьшить размер, не стоит сразу же помещать задачу в бэклог на основе одного мнения. Это может быть локальной проблемой. Мы можем превратить это в гипотезу для следующего этапа и задать себе вопрос: «Как это проверить?». Для начала, можно обратиться к аналитике и посмотреть на распределение аудитории по устройствам. Однако эти данные не скажут нам, действительно ли люди считают дизайн слишком большим. Чтобы проверить это, необходимо запустить еще один этап тестирования с записью сессий и попросить пользователей выполнить простое задание, а затем узнать, что бы они хотели улучшить, что было неудобно. Если никто не упомянет масштаб, то, возможно, это не считается серьезной проблемой. Вместо того, чтобы напрямую спрашивать о размере, можно изучить записи сессий тестирования, чтобы понять, как пользователи видят интерфейс. Вероятно, ваш 27-дюймовый монитор немного отличается от 10-летнего ноутбука пользователя с масштабом 150%.
Таким образом, для каждой гипотезы у вас должен быть соотнесен метод или ряд методов для ее проверки. Из моего опыта могу сказать, что можно начать распутывать клубок как с начала, так и с конца, задавая себе вопросы «Какие данные мне нужны, чтобы получить ответ?» и «Как я могу наилучшим образом их собрать?».
Описание пользовательских сценариев
Когда предварительный план обретает целостность, всё ещё рано начинать поиск пользователей. Мы только определили потоки данных, которые помогут проверить гипотезы, поэтому сейчас пора подумать о пользователях, о том, как они будут проходить тесты, какие вопросы им задавать и как они будут перемещаться от одного вопроса к другому. Важно избегать ошибок, которые могут исказить результаты исследования, так как даже одно неверное слово может серьезно повлиять на восприятие и испортить данные, что, в свою очередь, повлияет на выводы.
О конкретных формулировках и приемах мы обсудим чуть позже, когда перейдем к конкретным типам тестирования. Сейчас я хочу обратить ваше внимание на историю, которую будет рассказывать тест. Это не шутка.
Тестирование не должно напоминать допрос или процесс регистрации на государственные услуги. По моему мнению, оно должно быть похоже на беседу, которая естественно развивается. Важно помнить, что во время тестирования пользователи будут узнавать о вашем продукте и формировать свое представление о нем. Поэтому каждый вопрос и этап теста должны иметь свое место в этой беседе. Например, вы не можете спросить пользователя, сколько он готов заплатить за ваш продукт до того, как он увидит его. Но вы также не можете просто показать продукт пользователю, потому что вы не знаете, актуальна ли ему проблема, которую вы решаете.
Следовательно, вам нужно четко определить последовательность вопросов и предусмотреть возможность пропуска некоторых частей теста, если у пользователя нет необходимых знаний. В противном случае мы можем получить искаженные данные и неправильно их интерпретировать.
После того, как сформируете ваш сценарий, мысленно пройдитесь по нему с точки зрения пользователя. Всё ли кажется логичным? Если нет — вы знаете, что делать (исправить).
Теперь, когда роадмэп и сценарий у нас готовы, давайте побольше узнаем о каждом типе тестов, чтобы заполировать наш план до блеска.
Какие бывают типы тестов?
Если не вдаваться в детали, то все тесты можно условно разделить на множество разных категорий, но чаще всего используется следующая классификация:
- Очные / Удалённые,
- Модерируемые / Немодерируемые,
- Качественные / Количественные,
- Исследовательские / Сравнительные.
Следует понимать, что любой метод тестирования можно подогнать под определённый тип. Например, карточную сортировку можно провести как очно, нарезав бумажки, так и удалённо, используя передовые технологии 23-го века. Интервью могут предоставить как качественные данные, которые при должном уровне упорства и достаточном финансировании могут стать количественными (как это случается у исследователей, получивших гранты университетов).
Данная типология существует отдельно от основных методов тестирования и, скорее, служит их обвесом, подстраиваясь под конкретный контекст использования. Давайте рассмотрим каждую из этих пар.
Очные и удалённые тесты: Я уже почти забыл то время, когда мы проводили личные встречи с пользователями, пытаясь раскопать их истинные мотивы и эмоции. Были времена. Сейчас же ты можешь проснуться в 8:59, убрать слюну и, уже через минуту, общаться с респондентом на другом конце земного шара. Безусловно, удалённое общение сделало тестирование более эффективным, ведь теперь не нужно тратить много времени на организацию встреч. Однако удалённый формат имеет и ряд недостатков. Например, не всё можно протестировать удалённо — если речь идёт о физических устройствах, то вряд ли вы будете отправлять банковский терминал респонденту по почте (хотя такие случаи бывали). Кроме того, удалённое тестирование ограничивает вас в восприятии человеческой мимики, языка жестов и интонаций.
Модерируемые и немодерируемые тесты: Как можно догадаться из названия, модерируемые тесты сопровождаются участием человека-исследователя, который может либо молчать, либо активно взаимодействовать с респондентом, задавая уточняющие вопросы или мотивируя его. Немодерируемые тесты не предполагают вашего присутствия, и пользователи проходят их самостоятельно. Это не означает, что модерируемые тесты всегда проводятся очно, а немодерируемые — удалённо. Например, интервью по Zoom — это пример удалённого модерируемого теста. А проведение респондентом сценария в лаборатории без вашего участия — это пример очного и немодерируемого теста.
Качественные и количественные тесты: Следует отметить, что данная типология применяется не к самим тестам, а к получаемым результатам. Границы между ними иногда размываются, поскольку качественные данные могут быть преобразованы в количественные (и наоборот). Начнём с качественных методов. Они направлены на изучение индивидуальных особенностей поведения, выявление ментальных моделей и понимание того, как люди мыслят и чувствуют. Количественные методы, в свою очередь, призваны подтверждать или опровергать гипотезы и выявлять закономерности на основе больших объёмов данных. К качественным методам можно отнести обзорные пользовательские тесты, о которых упоминалось ранее, опросы с открытыми вопросами и другие подобные методы. К количественным методам относятся удалённые немодерируемые тесты, закрытые опросы и т.д.
Исследовательские и сравнительные тесты: Отличия между ними связаны с целями испытания. Если целью теста является глубокое исследование текущей реализации взаимодействия, выявление всех проблем, с которыми сталкивается пользователь без какого-либо предварительного решения, то это исследовательское тестирование. Если же уже существует решение, и тестирование направлено на сравнение его эффективности со старым решением, то это сравнительное тестирование. Обычно сравнительные тесты проводятся для подтверждения правильности выбора пути или выявления значительного улучшения метрик. Исследовательские тесты включают в себя разнообразные исследовательские сессии, где пользователю предоставляется задание, и анализируется, как он его решает в текущих условиях, то есть не тестируется конкретное решение, а текущая реализация продукта, с целью нахождения возможных улучшений. К сравнительным тестам можно отнести A/B/n-тестирование, где производится сравнение эффективности нового решения по отношению к предыдущему.
Представленная классификация, как и любая другая, которая могла бы быть придумана, имеет условный характер и применяется в основном для лучшего понимания контекста. Она служит надстройкой над методами тестирования и помогает определить, где и какой метод следует использовать. Я специально не включил некоторые другие классификации, такие как разделение по тестируемой функциональности (тестирование на проде или изолированных прототипах) и по уровню доступа (открытые и закрытые), так как они применимы в ограниченном числе случаев. Мы вернёмся к этой теме, рассматривая каждый тип тестирования более подробно. Буквально через несколько секунд.
Немного больше по теме
Также напомню, что у меня есть канал в телеграм, где я ненавязчиво делюсь новостями, статьями и своими мыслями к ним.
