Когда у команды появляется прототип нового продукта, функции или интерфейса, довольно быстро возникает вопрос: как его проверять? Провести несколько интервью и посмотреть, как пользователи проходят сценарий, или собрать большую выборку и получить количественные результаты? На практике я регулярно сталкиваюсь с этой развилкой, когда консультирую клиентов Тестографа по методологии исследований.
На первый взгляд кажется, что нужно просто выбрать более надёжный метод. Но интервью по прототипу и количественное тестирование нельзя напрямую сравнивать по принципу «этот способ лучше, а этот хуже». Они дают разные типы данных и, соответственно, помогают принимать разные решения.
Представим распространённую ситуацию. Команда подготовила интерактивный прототип нового личного кабинета. Нужно понять, смогут ли пользователи самостоятельно найти нужную функцию и выполнить целевое действие. Во время интервью можно наблюдать за человеком, задавать уточняющие вопросы и выяснить, почему он остановился на определённом экране или неправильно понял название раздела. Но пять или десять таких интервью не позволят уверенно сказать, насколько распространена обнаруженная проблема среди всей аудитории.
Можно пойти другим путём и провести количественное исследование на большой выборке. Оно покажет, например, какая доля участников успешно проходит сценарий или какой из двух вариантов интерфейса получает более высокие оценки. Однако цифра сама по себе далеко не всегда объясняет причину. Мы можем увидеть, что значительная часть пользователей не справилась с заданием, но так и не понять, что именно им помешало.
Именно поэтому перед выбором метода я обычно предлагаю сформулировать не вопрос «как нам протестировать прототип?», а другой: что именно мы хотим узнать и какое решение собираемся принять на основании результатов? После этого выбор между интервью и количественным тестированием становится значительно проще.
В этой статье разберём оба подхода с позиции практического исследования продукта: посмотрим, какие задачи лучше решать с помощью интервью, когда необходимы количественные данные и где проходят ограничения каждого метода. Отдельно разберём ситуации, в которых качественный и количественный этапы стоит объединить в одно исследование.
Материал будет полезен продакт-менеджерам, UX-исследователям, дизайнерам и маркетологам, а также командам, которым нужно проверить продуктовую гипотезу до того, как вкладывать ресурсы в полноценную разработку. Наша задача — не выбрать универсального победителя, а понять, какой метод даст достаточно данных именно для того решения, которое предстоит принять команде.
Интервью по прототипу особенно полезно в тот момент, когда команде недостаточно знать, справился пользователь с задачей или нет. Нам важно увидеть сам процесс: куда человек смотрит, что пытается сделать первым, какие элементы воспринимает неправильно и в какой момент его представление об интерфейсе расходится с логикой, заложенной командой.
Обычно участнику предлагают выполнить несколько реалистичных сценариев. Например: найти определённую функцию, оформить заказ, изменить настройки или разобраться с новым разделом личного кабинета. Исследователь наблюдает за действиями и задаёт уточняющие вопросы. При этом хорошее интервью — это не демонстрация прототипа с последующим вопросом «Вам всё понятно?».
Такой вопрос вообще даёт мало полезной информации. Человек может ответить утвердительно из вежливости или потому, что после объяснения исследователя интерфейс действительно кажется очевидным. Гораздо интереснее увидеть, сможет ли он самостоятельно понять, что делать.
В своей работе я стараюсь разделять наблюдаемое поведение и объяснения участника. Допустим, человек несколько секунд ищет кнопку продолжения, открывает другой раздел, возвращается назад и только затем замечает нужный элемент. После этого он может сказать: «В принципе всё понятно». Если записать только его итоговую оценку, проблема исчезнет из результатов. Если анализировать поведение, мы увидим затруднение, которое стоит изучить подробнее.
Интервью хорошо отвечает на вопросы такого типа: почему пользователь выбрал именно этот путь? Что он ожидал увидеть после нажатия? Как понял название функции? Почему проигнорировал элемент, который дизайнер считал заметным? Какая информация потребовалась ему для принятия решения?
Есть и ещё одно важное преимущество. Качественное исследование позволяет обнаруживать проблемы, которые команда заранее не включила в гипотезы. Мы можем прийти проверять понятность навигации, а выяснить, что пользователи вообще иначе воспринимают назначение продукта. В количественном исследовании подобные открытия получить сложнее: если определённого вопроса или варианта ответа нет в анкете, соответствующий сигнал легко пропустить.
Поэтому интервью особенно ценно на ранних стадиях, когда неопределённость ещё велика. Черновой прототип вовсе не обязательно доводить до визуального совершенства. Иногда выгоднее показать пользователям раннюю версию, обнаружить фундаментальную проблему в сценарии и изменить решение до того, как команда потратит время на детальную проработку интерфейса.
Но у метода есть принципиальное ограничение. Повторяемость наблюдения ещё не означает его распространённость во всей аудитории. Если четверо из восьми участников не нашли нужную функцию, нельзя автоматически заключить, что с ней столкнутся 50% будущих пользователей. Качественная выборка слишком мала для такого вывода, а способ подбора участников обычно не рассчитан на получение статистической оценки.
По результатам интервью корректнее сказать: «Мы обнаружили проблему и понимаем, при каких обстоятельствах она возникает». Если же команде необходимо узнать, насколько эта проблема распространена и различается ли её частота между сегментами аудитории, появляется задача для количественного этапа.
В этом и заключается основная ценность интервью по прототипу: оно помогает не столько измерить интерфейс, сколько разобраться в поведении человека и найти причины, которые затем можно превратить в конкретные гипотезы для дальнейшей проверки.
Если интервью помогает обнаружить проблему и разобраться в её причинах, количественное тестирование нужно в тех случаях, когда команде требуется понять масштаб явления. Здесь исследовательский вопрос меняется. Нас интересует уже не только «почему пользователь затрудняется?», но и «как часто это происходит?», «какой вариант работает лучше?» или «различаются ли результаты между группами пользователей?».
Предположим, после серии интервью мы заметили, что участники неоднозначно воспринимают название новой функции. На качественном этапе этого достаточно, чтобы зафиксировать проблему и сформулировать гипотезу. Но если перед командой стоит выбор между двумя вариантами названия, нескольких интервью может оказаться недостаточно. Тогда гипотезу можно перевести в измеряемую форму и проверить на большей выборке.
Количественное тестирование прототипа при этом не обязательно сводится к вопросу «Оцените удобство интерфейса от 1 до 10». Гораздо полезнее сочетать субъективные оценки с показателями поведения. В зависимости от задачи можно измерять долю успешно выполненных заданий, количество ошибок, время прохождения сценария, выбор определённого варианта или оценку понятности отдельных элементов.
Например, участникам предлагают найти в прототипе историю платежей. Из 200 человек 154 выполняют задание без ошибки. Мы получаем показатель успешности сценария — 77%. Это уже принципиально другой тип результата, чем наблюдение «несколько участников во время интервью долго искали историю платежей».
Но здесь появляется важная методологическая оговорка: число само по себе ещё ничего не гарантирует. Даже выборка из тысячи человек не спасёт исследование, если в неё попали не те респонденты или само задание сформулировано так, что подсказывает правильное действие.
Допустим, мы тестируем интерфейс сервиса для бухгалтеров, но большую часть выборки составляют люди, которые никогда не работали с бухгалтерскими продуктами. Формально участников много, однако переносить полученные результаты на реальную аудиторию продукта будет рискованно. Поэтому при подготовке количественного исследования я рекомендую начинать не с вопроса «сколько ответов нам собрать?», а с определения целевой аудитории и критериев отбора.
Не менее важна конструкция самого исследования. Если необходимо сравнить два прототипа, желательно организовать тест так, чтобы результат не зависел от порядка демонстрации вариантов, разных инструкций или других посторонних факторов. Если мы хотим сравнивать сегменты, нужно заранее понимать, по каким признакам будем их выделять и достаточно ли наблюдений окажется в каждой группе.
Для подобных задач можно использовать Тестограф: проводить онлайн-исследования, задавать скрининговые вопросы для отбора респондентов, собирать оценки после прохождения сценария и анализировать ответы разных групп аудитории. Особенно полезен количественный формат, когда исследование нужно провести удалённо и получить данные от значительно большего числа участников, чем возможно при индивидуальных интервью.
При этом я бы не противопоставлял «большую выборку» и «глубокое понимание». Количественный этап становится действительно полезным тогда, когда мы заранее понимаем, что именно измеряем и зачем нам понадобится полученная цифра.
Хорошая исследовательская логика выглядит примерно так: сначала формулируется гипотеза, затем определяется показатель, который позволит её проверить, после этого подбирается аудитория и только затем проектируется анкета или тест. Если поменять этот порядок и начать сразу с вопросов, легко получить красивый массив данных, который не поможет принять продуктовое решение.
Поэтому количественное тестирование стоит выбирать не потому, что «200 респондентов надёжнее десяти». Его преимущество в другом: оно позволяет проверить распространённость обнаруженных закономерностей, сравнить варианты по заранее заданным критериям и оценить различия между сегментами. А насколько убедительными будут эти выводы, зависит уже от качества исследовательского дизайна.
Разницу между интервью по прототипу и количественным тестированием проще всего увидеть через два исследовательских вопроса. Первый — почему возникает определённое поведение? Второй — насколько часто оно встречается? На практике команде нередко нужны ответы на оба, но получить их одинаково хорошо одним методом сложно.
Представим, что мы тестируем прототип мобильного приложения. Пользователю нужно изменить способ оплаты. Во время восьми интервью пять участников сначала открывают раздел «Настройки», хотя нужная функция находится внутри профиля. Это сильный исследовательский сигнал: ожидания пользователей могут расходиться с архитектурой интерфейса.
Во время интервью мы можем разобраться, почему возникло такое ожидание. Спросить участника, где он рассчитывал найти функцию, что для него означает раздел «Настройки», какие элементы интерфейса подсказали ему этот путь. Иногда выясняется, что проблема не в конкретной кнопке, а в самой логике группировки функций.
Но здесь важно остановиться до появления соблазнительного вывода: «5 из 8 ошиблись, значит проблема затрагивает примерно 62% пользователей». Для качественного исследования такая интерпретация некорректна. Участники интервью обычно не образуют выборку, по которой можно надёжно оценивать долю проблемы в целевой аудитории.
После интервью у нас есть другая ценность: мы знаем, какую проблему стоит проверять дальше.
Теперь можно сформулировать количественную гипотезу. Например: пользователи чаще ищут управление способом оплаты в «Настройках», чем в профиле. Эту гипотезу уже можно проверить на большей и подходящим образом сформированной выборке. Если исследовательский дизайн позволяет, мы получим оценку распространённости такого поведения и сможем сравнить результаты отдельных сегментов.
Работает и обратная логика. Допустим, количественный тест показывает, что только 58% участников успешно проходят один из ключевых сценариев. Это важная цифра, особенно если для остальных сценариев успешность заметно выше. Но сама по себе она не отвечает на главный продуктовый вопрос: что именно мешает оставшимся пользователям?
Причин может быть несколько. Они не замечают элемент управления, неправильно понимают термин, ожидают другой последовательности действий или выбирают альтернативный путь, которого нет в прототипе. Один показатель успешности не позволяет автоматически выбрать правильное объяснение.
Именно здесь количественные исследования иногда создают ложное ощущение определённости. Мы получили точное число и поэтому воспринимаем вывод как точный. Но точность измерения и полнота объяснения — разные вещи.
В исследованиях, которые мы обсуждаем с клиентами Тестографа, я советую заранее разделять поисковые и проверочные задачи. Если команда пока не знает, какие именно барьеры существуют, полезнее сначала исследовать поведение и сформировать гипотезы. Если предполагаемые проблемы уже известны и требуется понять их масштаб или сравнить решения, появляется основание для количественного теста.
Это разделение помогает избежать попытки заставить один метод выполнять чужую работу. Интервью не стоит превращать в мини-опрос с подсчётом процентов на нескольких участниках. А количественную анкету — перегружать вопросами в надежде, что респонденты сами подробно объяснят все причины своего поведения.
Вместо конкуренции методов получается последовательность: интервью помогает понять, что происходит и почему, а количественное тестирование — проверить, насколько обнаруженная закономерность существенна для более широкой аудитории. Именно это различие стоит держать в голове, когда команда выбирает способ проверки прототипа.
Выбор метода во многом зависит от того, насколько далеко команда продвинулась от идеи к готовому продукту. Чем меньше мы знаем о будущем пользовательском поведении, тем выше ценность качественного исследования. По мере накопления гипотез и появления конкретных вариантов для сравнения возрастает польза количественного тестирования.
На стадии концепции обычно нет смысла стремиться к большой выборке. Если команда только определяет структуру продукта, основные сценарии или способ представления новой функции, важнее обнаружить неожиданные интерпретации и барьеры. Несколько хорошо проведённых интервью могут показать, что пользователи вообще иначе представляют себе решение задачи.
Причём для такого исследования не нужен визуально законченный интерфейс. Иногда достаточно кликабельного прототипа с базовыми экранами. Чем раньше обнаружено принципиальное расхождение между логикой команды и ожиданиями пользователей, тем дешевле его исправить.
Когда появляется полноценный интерактивный прототип, исследовательские вопросы становятся конкретнее. На этом этапе я бы проверял основные пользовательские сценарии: понимает ли человек, с чего начать, может ли найти нужную функцию, правильно ли интерпретирует результат действия. Интервью по-прежнему полезно, потому что позволяет наблюдать не только финальный результат, но и путь пользователя.
Следующая ситуация — у команды уже есть несколько обоснованных решений. Например, после интервью дизайнеры разработали два варианта структуры экрана. Теперь вопрос заключается не столько в поиске неизвестных проблем, сколько в сравнении альтернатив. Здесь количественный подход становится значительно полезнее.
Можно предложить варианты разным группам респондентов и сравнить заранее выбранные показатели. В зависимости от задачи это может быть успешность выполнения сценария, оценка понятности, выбор предпочтительного решения или другой показатель, напрямую связанный с исследовательской гипотезой.
Ближе к разработке или запуску цена отдельных решений возрастает. Если изменение затрагивает ключевой пользовательский сценарий, имеет смысл проверить выводы на более широкой аудитории. Для сбора структурированной обратной связи и проведения таких исследований можно использовать онлайн-опросы Тестографа.
При этом стадия проекта — не единственный критерий. Я обычно предлагаю команде учитывать ещё четыре фактора: какое решение нужно принять, насколько дорого будет ошибиться, насколько хорошо изучена проблема и есть ли уже конкретная гипотеза для проверки.
Если мы почти ничего не знаем о причинах поведения, увеличение выборки не обязательно приблизит нас к ответу. Если причины уже изучены и нужно оценить масштаб проблемы, дополнительные интервью могут, наоборот, начать приносить всё меньше новой информации.
Поэтому выбор метода можно представить как движение от неопределённости к проверке. Сначала мы исследуем пространство проблемы, затем формулируем более точные гипотезы и после этого измеряем то, что действительно важно для решения.
На практике граница между этапами не всегда будет идеальной. Иногда количественный тест обнаруживает неожиданную аномалию и приходится возвращаться к интервью. Иногда нескольких качественных сессий достаточно, чтобы отказаться от явно неработающего решения без дополнительного исследования. Методология здесь должна помогать продуктовой команде принимать решения, а не превращаться в обязательную последовательность процедур.
Оба метода могут дать убедительные на вид результаты и при этом привести команду к неправильному решению. Причина обычно не в самом интервью или количественном подходе, а в том, как было спроектировано исследование и насколько далеко мы заходим в интерпретации полученных данных.
Для интервью одна из самых частых ошибок — превращать наблюдения на небольшой выборке в статистику. Формулировка «шесть из десяти участников не нашли кнопку» допустима как описание проведённых сессий. Но утверждение «60% пользователей не найдут кнопку» — уже вывод о более широкой аудитории, для которого десяти качественно отобранных участников недостаточно.
Есть и другая проблема: влияние исследователя. Иногда достаточно небольшой подсказки, чтобы изменить поведение участника. Вопрос «Вы заметили кнопку в верхнем углу?» одновременно сообщает человеку, что там есть кнопка и что она заслуживает внимания. После этого мы уже не наблюдаем естественное взаимодействие с прототипом.
Поэтому при интервью я стараюсь сначала фиксировать самостоятельные действия пользователя и только затем переходить к уточняющим вопросам. Вместо «Почему вы не нажали эту кнопку?» полезнее спросить: «Что бы вы сделали дальше?» Так мы уменьшаем вероятность того, что сама формулировка вопроса объяснит участнику интерфейс.
У количественного тестирования свои источники ложной уверенности. Самый заметный из них — размер выборки. Несколько сотен ответов выглядят убедительно, однако большое количество наблюдений не исправляет систематическую ошибку. Если исследование новой функции банковского приложения прошло преимущественно среди людей, которые не относятся к её целевой аудитории, дополнительная тысяча ответов не решит проблему отбора.
Не менее опасно измерять удобный показатель вместо действительно важного. Например, после работы с прототипом участников спрашивают: «Насколько удобным показался интерфейс?» Средняя оценка составляет 8,4 из 10, и команда делает вывод, что решение работает хорошо. Но если задача продукта состоит в том, чтобы пользователь без помощи оформил заявку, гораздо важнее проверить успешность этого сценария. Высокая субъективная оценка не гарантирует, что человек смог выполнить нужное действие.
Отдельно стоит учитывать рационализацию. Пользователи не всегда могут точно восстановить причины собственных действий. Человек может сначала долго искать функцию, случайно обнаружить её, а затем уверенно объяснить, что расположение показалось ему логичным. Поэтому ответы респондента полезно сопоставлять с тем, что он действительно делал.
При проектировании исследований в Тестографе мы также рекомендуем внимательно относиться к формулировкам вопросов. Даже при большой выборке наводящий или двусмысленный вопрос способен систематически сместить результаты. Хорошая анкета не компенсирует ошибки прототипа, но и хороший прототип невозможно корректно оценить с помощью плохо составленной анкеты.
Есть простой принцип, который помогает избежать многих подобных ситуаций: уровень уверенности в выводе не должен быть выше возможностей метода. Интервью позволяет уверенно говорить о найденных паттернах и возможных причинах поведения, но осторожнее — об их распространённости. Количественное исследование позволяет измерять показатели и сравнивать группы, однако не всегда объясняет механизм, который стоит за полученной разницей.
Поэтому до начала тестирования полезно сформулировать не только гипотезу, но и будущий вывод. Например: «Если мы получим результат X, какое решение примем?» Такой вопрос быстро показывает, действительно ли выбранный метод способен предоставить данные, необходимые команде. И зачастую именно на этом этапе становится понятно, что вместо выбора одного подхода понадобится комбинация двух.
На практике интервью и количественное тестирование часто полезнее рассматривать не как альтернативы, а как последовательные этапы одного исследования. Качественный этап уменьшает неопределённость и помогает сформулировать гипотезы, а количественный — проверить, насколько найденные закономерности характерны для более широкой аудитории.
Предположим, команда тестирует новый сценарий регистрации. На интервью несколько участников останавливаются на шаге, где нужно выбрать тип аккаунта. Наблюдая за ними и задавая уточняющие вопросы, мы выясняем возможную причину: названия вариантов понятны разработчикам продукта, но пользователи не видят между ними существенной разницы.
После этого у нас появляется конкретная гипотеза. Команда меняет формулировки и создаёт второй вариант экрана. Теперь можно переходить к количественной проверке: показать решения разным группам респондентов и сравнить, насколько успешно они выбирают подходящий тип аккаунта, сколько времени тратят на решение или насколько уверены в своём выборе.
Такой подход обычно эффективнее попытки сразу составить большую анкету. На качественном этапе пользователи могут обнаружить проблему, которую команда вообще не планировала измерять. После этого количественное исследование становится более сфокусированным: мы проверяем уже не десятки предположений, а несколько содержательных гипотез.
В упрощённом виде процесс выглядит так: гипотеза → интервью по прототипу → обнаружение барьеров → формулировка проверяемых предположений → количественное тестирование → продуктовое решение.
Однако это не обязательный порядок. Иногда команда уже располагает количественными данными. Например, аналитика показывает необычно высокий процент отказов на конкретном этапе, а проведённый опрос подтверждает низкую оценку этого сценария. Тогда разумнее двигаться в обратную сторону: взять обнаруженный количественный сигнал и провести интервью, чтобы разобраться в его причинах.
Особое внимание я бы уделил переходу от интервью к анкете. Нельзя просто взять высказывания нескольких участников и превратить их в готовые варианты ответов. Сначала нужно отделить единичные комментарии от повторяющихся наблюдений, сформулировать гипотезы и определить, какой показатель действительно подтвердит или опровергнет каждую из них.
Для количественного этапа удобно использовать конструктор опросов Тестографа. В одном исследовании можно собрать необходимые характеристики респондентов, задать вопросы после взаимодействия с прототипом и затем анализировать результаты с учётом нужных сегментов. Это особенно полезно, когда предполагается, что разные группы аудитории могут воспринимать один и тот же сценарий по-разному.
При этом объединять методы стоит не ради самого «смешанного исследования». Дополнительный этап должен уменьшать неопределённость, которая действительно влияет на решение. Если после нескольких интервью очевидно, что критический сценарий не работает и прототип всё равно отправится на переработку, количественно подтверждать масштаб проблемы прямо сейчас может быть избыточно.
И наоборот, если команда собирается выбрать один из двух вариантов и вложить значительные ресурсы в его разработку, количественная проверка может оказаться оправданной. Чем выше цена ошибочного решения, тем важнее понимать не только причины пользовательского поведения, но и его распространённость.
Поэтому комбинированный подход ценен не количеством методов, а связью между ними. Каждый следующий этап должен отвечать на вопрос, который остался открытым после предыдущего. Тогда исследование превращается из набора интервью и анкет в последовательный процесс принятия решений на основе данных.
Комбинация качественного и количественного подходов выглядит убедительно, но на практике ресурсы команды почти всегда ограничены. Исследование нужно провести за неделю, доступ к респондентам затруднён, бюджет рассчитан только на один этап или решение необходимо принять до следующего цикла разработки. В такой ситуации я бы не пытался определить «самый надёжный» метод. Полезнее выбрать тот, который снимает главную неопределённость.
Если команда ещё плохо понимает проблему, чаще имеет смысл начать с интервью. Например, есть новый сценарий оформления заказа, но неизвестно, какие его части вызывают затруднения. Запускать большой количественный тест в такой ситуации рискованно: мы можем очень точно измерить показатели, но не получить ответа, что именно необходимо изменить.
Интервью особенно оправдано, когда прототип ранний, команда допускает серьёзные изменения в структуре и хочет найти неожиданные проблемы. Здесь несколько содержательных наблюдений способны повлиять на решение сильнее, чем средняя оценка интерфейса от нескольких сотен респондентов.
Другая ситуация — проблема уже достаточно хорошо изучена. Допустим, после предыдущих исследований команда знает, что пользователи плохо понимают название определённого раздела. Дизайнеры подготовили два новых варианта, и теперь необходимо решить, какой из них использовать. Повторные интервью могут дать дополнительный контекст, но основная неопределённость уже другая: какой вариант показывает лучший результат на целевой аудитории? Здесь логичнее направить ресурсы на количественную проверку.
Я использую простой ориентир. Если исследовательский вопрос начинается с «почему», «как пользователь понимает», «чего он ожидает» или «что ему мешает», сначала стоит рассмотреть интервью. Если вопрос звучит как «какая доля», «какой вариант лучше», «насколько отличается» или «есть ли различия между сегментами», вероятнее всего, понадобятся количественные данные.
При ограниченном бюджете особенно важно не пытаться компенсировать слабую постановку задачи количеством участников. Иногда команда стремится собрать как можно больше ответов, потому что большая выборка выглядит убедительнее при презентации результатов. Но 500 ответов на неправильно сформулированный вопрос не обязательно полезнее восьми интервью, которые помогли обнаружить фундаментальную ошибку в пользовательском сценарии.
Работает и обратное правило. Не стоит продолжать интервью только потому, что этот формат привычнее команде. Если после нескольких исследований причины проблемы уже понятны, а спор идёт о том, насколько она распространена или какой вариант решения эффективнее, новые разговоры с пользователями могут лишь повторять уже известные наблюдения.
При выборе метода я советую сформулировать предложение: «После исследования мы хотим решить, нужно ли нам…» — и закончить его конкретным действием. Например, менять структуру навигации, выбирать один из двух экранов, переименовывать функцию или отправлять прототип в разработку. Затем нужно спросить: каких данных не хватает, чтобы принять именно это решение?
Такой подход полезнее универсального правила вроде «сначала всегда проводим пять интервью» или «для серьёзных решений обязательно нужно сто ответов». Метод исследования должен следовать за задачей, а не наоборот.
Если ресурсов действительно хватает только на один этап, я бы сформулировал выбор максимально просто: при высокой неопределённости исследуем причины, при сформулированной гипотезе, которую необходимо измерить, — проверяем её количественно. Это не исключает ошибок, но значительно снижает риск потратить ограниченный исследовательский ресурс на данные, которые в итоге не изменят решение команды.
Универсального победителя в этом сравнении нет. Интервью по прототипу и количественное тестирование работают с разными типами неопределённости, поэтому выбирать между ними только по размеру выборки, стоимости или привычкам команды не стоит.
Интервью особенно полезно, когда нужно разобраться в поведении пользователя. Оно позволяет увидеть неожиданный сценарий, обнаружить непонятный элемент, проверить ожидания человека и найти возможную причину затруднения. На ранних этапах работы с прототипом такая информация часто ценнее точного процента.
Количественное тестирование становится сильнее, когда проблема уже сформулирована и её нужно измерить. С его помощью можно оценить распространённость определённого поведения, сравнить варианты решения, проверить различия между сегментами и получить данные для выбора между конкретными альтернативами. Для организации такого исследования можно использовать Тестограф, особенно если необходимо собрать структурированные ответы от широкой аудитории и затем проанализировать результаты.
Но наиболее полезные исследования, которые я вижу в работе с продуктовыми командами, часто строятся не вокруг выбора «интервью или количественный тест», а вокруг последовательного уменьшения неопределённости. Сначала команда выясняет, что происходит и почему, затем определяет, насколько это распространено, и только после этого принимает решение.
Не каждому проекту обязательно нужны оба этапа. Иногда нескольких интервью достаточно, чтобы обнаружить критическую ошибку и отправить прототип на переработку. В другой ситуации причины поведения уже известны и дополнительное качественное исследование практически ничего не изменит — тогда разумнее сразу проверить гипотезу количественно.
Поэтому перед запуском исследования я рекомендую задать один вопрос: какое решение мы примем после получения результатов? Если для решения необходимо понять причины поведения — выбирайте интервью. Если необходимо измерить эффект, распространённость проблемы или сравнить варианты — количественное тестирование. Если нужны и причины, и уверенность в масштабе обнаруженного эффекта, методы стоит объединить.
В конечном счёте качество исследования определяется не тем, насколько сложную методологию выбрала команда и сколько респондентов удалось привлечь. Важнее, чтобы полученные данные действительно уменьшали неопределённость и помогали принять конкретное продуктовое решение. Именно с этого, а не с выбора исследовательского инструмента, я бы начинал работу с любым новым прототипом.