При тестировании прототипов команда часто начинает с интервью — и это логично. Разговор с пользователем помогает увидеть, где он сомневается, что понимает не так, почему выбирает один путь вместо другого и какие ожидания приносит с собой в интерфейс. Для ранних этапов разработки такой формат особенно полезен: несколько содержательных сессий могут быстро показать проблемы, которые команда сама не замечала.
Но у интервью есть ограничение, с которым я регулярно сталкиваюсь в работе с исследованиями. Обнаружить проблему — ещё не значит понять её масштаб. Если трое из восьми участников не смогли найти нужный раздел, это важный сигнал, но из него нельзя автоматически сделать вывод, что с тем же затруднением столкнётся примерно треть аудитории. Возможно, проблема характерна только для конкретного сегмента. Возможно, на результат повлияла формулировка задания. А возможно, перед нами действительно системный барьер, который затронет значительную часть пользователей.
Именно в этот момент возникает задача количественного тестирования прототипа. Оно позволяет перейти от наблюдений за отдельными участниками к сопоставимым данным: какая доля пользователей завершила сценарий, на каком шаге чаще происходят ошибки, сколько времени занимает задача, какой из вариантов интерфейса показывает лучший результат.
Эта статья будет полезна UX-исследователям, продуктовым менеджерам, дизайнерам и командам, которым недостаточно знать, что «пользователи испытывают трудности», — им нужно понять, насколько проблема распространена и достаточно ли она значима для продуктового решения.
При этом количественное тестирование не заменяет интервью. У этих методов разные сильные стороны. Интервью помогает разобраться в причинах поведения, а количественный подход — оценить его частоту и сравнить результаты между группами или версиями прототипа. На практике наиболее полезный вопрос звучит не «какой метод лучше вообще», а «какой метод даст более надёжный ответ на текущий исследовательский вопрос».
Дальше разберём, в каких ситуациях количественное тестирование прототипа оказывается информативнее серии интервью, какие показатели имеет смысл собирать и где команды чаще всего получают убедительные на вид, но методологически слабые результаты.
Количественное тестирование прототипа начинается не с количества участников, а с исследовательского вопроса. Если мы хотим выяснить, понимает ли пользователь назначение новой функции и почему выбирает определённый элемент интерфейса, нам нужны наблюдение и разговор. Если же вопрос звучит как «какая доля пользователей сможет самостоятельно завершить сценарий?» или «какой из двух вариантов формы приводит к меньшему числу ошибок?», появляется задача для количественного метода.
На практике я бы определил количественное тестирование прототипа как исследование, в котором участники выполняют одинаковые или сопоставимые задания, а их результаты фиксируются через заранее определённые показатели. Это позволяет анализировать не отдельные истории пользователей, а закономерности в выборке.
Например, команда проектирует новый сценарий оформления заявки. Во время интервью исследователь может попросить участника пройти прототип и параллельно рассказывать, что он думает. Мы узнаем, почему поле вызывает сомнения, какое название кнопки кажется непонятным и чего пользователь ожидает увидеть на следующем экране. Это богатые данные, но они преимущественно отвечают на вопрос «почему?».
Количественный тест строится иначе. Участнику можно дать конкретную задачу и затем зафиксировать несколько результатов:
Так мы получаем данные, которые можно одинаково интерпретировать для всей выборки. Если тестируются два варианта прототипа, появляется возможность сравнить их по одним и тем же критериям.
Не каждую цифру можно считать количественным исследованием
Одна из методологических ошибок, которую я встречаю в проектах, — превращение нескольких UX-интервью в «количественный» результат. Например: «пять из семи участников предпочли вариант B, поэтому его выбирают 71% пользователей».
Математически расчёт правильный, но исследовательский вывод значительно слабее, чем выглядит. Участники качественного исследования обычно подбираются для изучения разных моделей поведения и поиска проблем, а не для точной оценки их распространённости. Процент в таком случае создаёт ощущение точности, которой дизайн исследования не обеспечивает.
Поэтому для количественного тестирования мы заранее определяем, что именно будем измерять, на какой аудитории и какое различие будет иметь практическое значение. Только после этого стоит проектировать задания и собирать ответы.
Когда прототип уже можно тестировать количественно
Необязательно ждать готового продукта. Количественный подход можно применять и к интерактивному прототипу, если он достаточно реалистично воспроизводит тот сценарий, который мы хотим проверить.
Здесь важна не визуальная завершённость макета, а функциональная достаточность. Если пользователь должен выбрать тариф, прототип должен позволять пройти этот выбор без искусственных подсказок. Если проверяется поиск определённой настройки, навигация должна вести себя достаточно близко к предполагаемому продукту.
Чем больше ограничений прототипа напрямую влияет на выполнение задания, тем сложнее интерпретировать метрики. Мы рискуем измерить не понятность будущего интерфейса, а особенности самого макета.
Поэтому на ранней стадии, когда команда ещё пытается понять потребности, ожидания и возможные модели поведения, я чаще рекомендую начинать с интервью и модерируемых тестов. Когда сценарий уже сформирован и вопрос смещается от «что здесь происходит?» к «насколько хорошо это работает для нашей аудитории?», количественное тестирование становится значительно полезнее.
Именно эта граница важна при выборе метода: интервью помогает открыть проблему, а количественное исследование — проверить её масштаб и получить основание для сравнения.
Количественное тестирование становится особенно полезным в тот момент, когда команда уже знает, что именно хочет проверить. Если после нескольких интервью выяснилось, что пользователи путаются между двумя способами оформления заказа, следующий исследовательский вопрос может быть не «почему они путаются?», а «какой вариант интерфейса позволяет большему числу пользователей выполнить задачу без ошибки?».
Это принципиальная разница. Интервью хорошо работает в ситуации неопределённости: исследователь может задавать дополнительные вопросы, менять направление разговора и разбираться в неожиданном поведении участника. Количественный тест, напротив, требует заранее зафиксированной процедуры. Зато результаты разных участников становится проще сопоставлять.
В своей работе я обычно выделяю несколько ситуаций, когда переход к количественному формату оправдан:
Представим, что в ходе интервью мы заметили: пользователи не сразу находят кнопку изменения способа доставки. После пяти или семи сессий мы можем достаточно хорошо разобраться, почему это происходит. Например, название раздела не соответствует ожиданиям пользователей или сама кнопка визуально воспринимается как второстепенная.
Дальше дизайнер предлагает новую версию. Ещё несколько интервью помогут услышать реакцию на изменение, но если задача состоит именно в сравнении двух решений, полезнее создать стандартизированный тест. Одной группе показываем исходный вариант, другой — изменённый, задаём одинаковую задачу и сравниваем заранее выбранные показатели.
Здесь важно не превращать исследование в голосование за дизайн. Вопрос «Какой вариант вам больше нравится?» измеряет предпочтение, но почти ничего не говорит об эффективности интерфейса. Пользователь может предпочесть визуально привлекательный экран и одновременно чаще ошибаться при выполнении задачи.
Поэтому сильнее работает проверка через действие. Например, участника просят изменить адрес доставки, найти определённую функцию или выбрать подходящий тариф. После выполнения задания можно добавить несколько вопросов о сложности, понятности или уверенности в сделанном выборе. Для сбора таких стандартизированных ответов удобно использовать онлайн-опросы Тестографа, связывая взаимодействие с прототипом с последующими вопросами исследования.
Когда нужно понять масштаб проблемы
Другой распространённый сценарий возникает после качественного исследования. Допустим, в интервью несколько участников решили, что кнопка «Продолжить» сразу завершит покупку, хотя на самом деле после неё открывается ещё один этап.
Это наблюдение заслуживает внимания, но само по себе не отвечает на продуктовый вопрос: насколько проблема существенна?
Если ошибочное ожидание встречается у небольшой специфической группы, команда может принять одно решение. Если то же самое происходит у значительной части целевой аудитории, приоритет изменения будет другим. Количественный тест позволяет перейти от факта существования проблемы к оценке её распространённости — при условии, что выборка и процедура исследования позволяют делать такой вывод.
Когда необходимо выбрать между версиями
Количественный подход особенно хорошо работает там, где есть альтернативы и заранее определён критерий успеха. Например, команда выбирает между двумя структурами меню. Вместо обсуждения того, какая из них «интуитивнее», можно определить конкретные задачи и посмотреть, в каком варианте пользователи чаще находят нужные разделы.
Но сравнивать версии имеет смысл только тогда, когда мы понимаем, что считаем улучшением. Более короткое время выполнения не всегда означает лучший интерфейс. Пользователь мог быстро нажать неправильную кнопку. Высокий процент завершения тоже требует контекста: возможно, участники справились, но были не уверены в результате.
Поэтому перед запуском я рекомендую сформулировать решение, которое команда собирается принять после получения данных. Например: «Если вариант B повысит успешность выполнения основного сценария и при этом не увеличит число критических ошибок, мы передадим его в разработку».
Такая формулировка дисциплинирует исследование. Становится понятнее, кого приглашать, какие задания давать и какие показатели действительно нужны.
В результате количественный тест оказывается сильнее дополнительной серии интервью не потому, что в нём больше респондентов или больше цифр. Его преимущество появляется тогда, когда исследовательский вопрос уже достаточно конкретен и команде требуется измерить различия, оценить масштаб или выбрать между альтернативами. Если причины поведения ещё неизвестны, переходить к цифрам, как правило, рано.
Одна из ошибок при количественном тестировании — собирать все показатели, которые технически доступны. В результате исследователь получает время выполнения, проценты завершения, оценки по шкалам, количество кликов и ещё десяток параметров, но не понимает, какой из них должен повлиять на продуктовое решение.
Я предпочитаю идти в обратном направлении: сначала определить критерий успешного взаимодействия, а уже затем выбирать метрики. Если мы проверяем новый сценарий регистрации, главным показателем может быть доля участников, самостоятельно дошедших до конца. Если сравниваем навигацию — способность найти нужный раздел. Если исследуем сложную форму — количество ошибок на определённых этапах.
Успешность выполнения задачи
Task success, или успешность выполнения задания, — одна из наиболее понятных метрик для тестирования прототипов. Для каждого участника фиксируется результат: справился он с задачей или нет.
Однако критерий успеха нужно определить до начала исследования. Представим задание: «Измените адрес доставки для уже оформленного заказа». Один пользователь сразу находит нужную функцию. Второй несколько раз переходит между разделами, но в итоге тоже справляется. Третий выбирает изменение платёжного адреса и уверен, что выполнил задачу.
Если все три случая просто записать как «завершение сценария», показатель окажется малоинформативным. Поэтому иногда полезнее разделять результат на успешное выполнение, выполнение с существенными затруднениями и неуспешное выполнение.
Время выполнения
Время хорошо дополняет показатель успешности, особенно при сравнении двух вариантов одного сценария. Но использовать его как самостоятельный критерий качества рискованно.
Быстрее не всегда значит лучше. Человек может за несколько секунд выбрать неправильный пункт, тогда как другой пользователь внимательно изучит интерфейс и успешно выполнит задачу немного позже.
Кроме того, время особенно чувствительно к особенностям прототипа. Задержки, непривычные интерактивные области или отсутствие ожидаемой функции способны увеличить продолжительность задания, хотя в готовом продукте такой проблемы не будет.
Поэтому я обычно интерпретирую время вместе с успешностью, а не вместо неё.
Ошибки и проблемные шаги
Средняя успешность может скрывать конкретное место, где ломается сценарий. Допустим, 78% участников дошли до конца. Само по себе это число ещё не объясняет, что происходило с оставшимися 22%.
Полезно дополнительно смотреть, где пользователи выбирали неправильное действие, возвращались назад или прекращали выполнение задания. Тогда количественное тестирование начинает показывать не только итоговый результат, но и структуру проблемы.
Здесь особенно важно заранее определить, какие действия считать ошибкой. Иначе исследователь рискует классифицировать поведение уже после получения результатов и невольно подстраивать критерии под данные.
Субъективная сложность и уверенность
Поведенческие показатели стоит дополнять восприятием самого пользователя. После задания можно спросить, насколько легко или сложно было его выполнить либо насколько участник уверен, что получил нужный результат.
Такие вопросы удобно включать непосредственно в исследовательскую анкету. В Тестографе можно собрать ответы участников после прохождения сценария и затем сопоставить субъективные оценки с другими результатами исследования.
Это сочетание иногда обнаруживает особенно интересные случаи. Например, участник успешно завершает задачу, но оценивает её как очень сложную. Формально интерфейс работает, однако взаимодействие требует слишком больших усилий. Возможна и обратная ситуация: пользователь уверен, что всё сделал правильно, хотя фактически выбрал неверный путь. Для UX-исследования такой результат может быть даже важнее обычной ошибки, потому что человек не замечает возникшей проблемы.
Почему одной метрики недостаточно
Я бы не рекомендовал искать универсальный «UX-показатель», который позволит однозначно определить качество прототипа. Обычно полезнее небольшая связка метрик, соответствующая конкретной гипотезе.
Например, при сравнении двух вариантов оформления заказа мы можем одновременно оценить долю успешных выполнений, количество критических ошибок и субъективную сложность. Если новый вариант показывает более высокий task success, меньше ошибок и сопоставимую либо меньшую сложность, аргументация в его пользу становится существенно сильнее.
Если же показатели расходятся — например, пользователи выполняют сценарий быстрее, но чаще ошибаются, — исследование не провалилось. Напротив, оно показало компромисс, который нельзя увидеть по одной цифре.
Поэтому хороший набор метрик — не самый большой, а тот, в котором каждый показатель отвечает на конкретный вопрос. До запуска исследования команда должна понимать не только что она измеряет, но и какой результат действительно изменит её решение о прототипе.
Можно провести тест на сотне участников и получить менее надёжный вывод, чем в исследовании с гораздо меньшей выборкой. Причина проста: количество ответов не исправляет ошибки в подборе респондентов или постановке задания. Если мы тестируем прототип не на той аудитории либо сами подсказываем участникам правильный путь, увеличение выборки лишь делает ошибочный результат убедительнее.
Поэтому при подготовке количественного тестирования я отдельно проверяю три элемента: кто будет проходить тест, насколько реалистично сформулирован сценарий и одинаковые ли условия получают участники.
Выборка должна соответствовать исследовательскому вопросу
Представим, что команда тестирует новый интерфейс личного кабинета для корпоративных клиентов. Набрать большое количество любых пользователей проще, чем найти людей, которые действительно работают с подобными продуктами. Но результаты такой удобной выборки могут плохо переноситься на целевую аудиторию.
Состав участников особенно важен, когда успешность сценария зависит от опыта. Новый пользователь и специалист, ежедневно работающий с аналогичными системами, могут совершенно по-разному воспринимать терминологию, структуру меню и количество информации на экране.
Поэтому перед набором респондентов стоит определить критерии включения в исследование: опыт использования продукта или категории, роль, частоту выполнения соответствующей задачи и другие характеристики, непосредственно связанные с проверяемой гипотезой.
При этом размер выборки нельзя выбирать по принципу «чем больше, тем лучше». Он зависит от того, насколько точную оценку мы хотим получить, какие группы собираемся сравнивать и насколько крупное различие между вариантами имеет для команды практический смысл.
Сценарий не должен объяснять интерфейс вместо интерфейса
Вторая проблема — слишком подробное задание. Например, команда хочет проверить, смогут ли пользователи самостоятельно найти настройку уведомлений, но формулирует сценарий так: «Откройте настройки профиля, перейдите в раздел уведомлений и отключите письма о новых предложениях».
Мы уже рассказали человеку маршрут. В результате исследование проверяет способность следовать инструкции, а не способность найти функцию.
Более подходящая формулировка может выглядеть так: «Представьте, что вы больше не хотите получать письма о новых предложениях. Измените необходимые настройки». Здесь задана цель, но способ её достижения участник должен определить самостоятельно.
Это небольшое различие в формулировке способно заметно повлиять на итоговые показатели.
Одинаковые условия важнее дополнительных объяснений
В модерируемом интервью исследователь может заметить замешательство и уточнить, что имелось в виду. В количественном тесте такая помощь создаёт проблему: часть участников получает дополнительную информацию, а часть — нет.
Поэтому инструкции, порядок заданий и критерии успешности желательно стандартизировать заранее. Если человеку необходима дополнительная информация для выполнения сценария, лучше встроить её в условия теста одинаково для всех.
То же относится к вопросам после взаимодействия с прототипом. Их можно собрать через онлайн-опрос в Тестографе, заранее задав единую последовательность и формулировки для участников. Это особенно удобно, когда исследование проходит без модератора и необходимо сохранить одинаковую процедуру для всей выборки.
Есть ещё один практический нюанс: вопросы после задания не должны раскрывать участнику цель следующих заданий. Если сначала спросить: «Насколько заметной была кнопка сохранения?», а затем попросить человека найти способ сохранить изменения, первый вопрос фактически становится подсказкой.
Поэтому порядок исследования нужно проектировать так же внимательно, как сами вопросы.
В количественном UX-тестировании качество данных определяется не числом заполненных анкет. Сильный дизайн исследования начинается с соответствующей аудитории, нейтрального сценария и одинаковых условий прохождения. Если эти три элемента нарушены, последующий статистический анализ уже не сможет полностью компенсировать методологическую ошибку.
Хороший количественный тест можно спроектировать ещё до того, как готова анкета. Я обычно начинаю не с формулировки вопросов, а с решения, которое команда собирается принять по итогам исследования. Такой подход быстро показывает, какие данные действительно нужны, а какие собираются «на всякий случай».
Допустим, продуктовая команда говорит: «Нам нужно проверить удобство нового оформления заказа». Для исследования это слишком широкая задача. Что именно означает «удобство»? Пользователь должен быстрее оформить заказ, реже ошибаться, лучше понимать итоговую стоимость или чаще доходить до завершения сценария?
Поэтому первым шагом я превращаю общую задачу в проверяемую гипотезу. Например: «В новой версии пользователи успешнее выбирают способ доставки и реже возвращаются на предыдущий экран».
Теперь появляется возможность определить наблюдаемые показатели: долю успешного выполнения задания, количество возвратов и субъективную оценку сложности.
От гипотезы к заданию
Следующий этап — создание реалистичной пользовательской ситуации. Участнику не нужно знать исследовательскую гипотезу. Ему нужна понятная цель.
Вместо инструкции «Выберите доставку в пункт выдачи и нажмите кнопку “Продолжить”» лучше дать контекст: «Вы оформляете заказ и хотите забрать его самостоятельно из удобного пункта выдачи. Оформите подходящий вариант доставки».
Во втором случае прототип должен сам объяснить человеку, куда двигаться. Именно это мы и хотим проверить.
После задания фиксируется результат, а затем можно задать несколько вопросов. Например, попросить оценить сложность выполнения или уверенность в том, что доставка оформлена правильно. Если участник не справился, полезно выяснить, что именно помешало ему продолжить.
При этом открытый вопрос после задания не превращает исследование в качественное интервью. Он скорее добавляет контекст к количественному результату. Ответы помогают сформулировать возможные объяснения, но их не стоит автоматически воспринимать как точное измерение причин поведения.
Анкета должна повторять логику исследования
Когда гипотеза, сценарий и показатели определены, структура анкеты становится значительно понятнее. В ней могут последовательно появляться скрининговые вопросы, инструкция, ссылка на прототип или задание, вопросы после выполнения и необходимые характеристики участника.
Такую последовательность можно организовать с помощью Тестографа, используя онлайн-анкету как часть исследовательского сценария. Особенно важно заранее проверить весь путь глазами респондента: от первого экрана до отправки ответов.
Я рекомендую провести небольшой пилотный запуск до основного сбора данных. Даже несколько прохождений помогают обнаружить ситуации, которые сложно заметить при подготовке анкеты: двусмысленное задание, неработающую ссылку, слишком очевидную подсказку или вопрос, который участники понимают иначе, чем исследователь.
Заранее определяем критерий решения
Последний этап часто пропускают, хотя именно он защищает команду от удобной интерпретации результатов после исследования.
До запуска стоит зафиксировать, какой результат будет аргументом в пользу изменения прототипа. Например, недостаточно сказать: «Выберем вариант с лучшими показателями». Нужно определить, какой показатель основной и какое различие имеет практический смысл.
Это особенно важно, если метрик несколько. Новый вариант может повысить успешность выполнения задачи, но увеличить время прохождения. Или сократить время, одновременно увеличив число критических ошибок. Без заранее сформулированного приоритета команда легко выберет ту цифру, которая подтверждает уже существующее мнение.
В итоге логика количественного теста должна оставаться простой: исследовательский вопрос → гипотеза → пользовательское задание → измеряемые показатели → критерий решения. Анкета появляется только после этой цепочки. Тогда каждый вопрос в ней выполняет понятную функцию, а результаты действительно помогают принять решение о прототипе, а не просто добавляют ещё один набор цифр в исследовательский отчёт.
После завершения количественного теста появляется соблазн найти одну понятную цифру и вынести её в итог исследования: «82% пользователей справились с заданием» или «новый вариант оказался на 14% лучше». Такие формулировки удобны для презентации результатов, но без контекста могут создавать гораздо больше уверенности, чем позволяют данные.
Когда я анализирую результаты подобных исследований, первый вопрос — не «какой процент получился?», а «что именно стоит за этим процентом?». Кто участвовал в тестировании, какое задание выполняли респонденты, что считалось успешным выполнением и насколько условия соответствовали реальному использованию продукта?
Представим, что 72% участников успешно нашли функцию отмены подписки. Хороший это результат или плохой? Без дополнительной информации ответить нельзя. Если в старой версии с задачей справлялись 45%, изменение выглядит перспективным. Если команда ожидала практически безошибочного прохождения критически важного сценария, 72% могут, наоборот, указывать на серьёзную проблему.
Поэтому абсолютный показатель полезно рассматривать вместе с контекстом и заранее установленным критерием решения.
Сравниваем не проценты, а сопоставимые условия
При сравнении двух прототипов важно убедиться, что различие действительно связано с интерфейсом. Если вариант A тестировали преимущественно новые пользователи, а вариант B — люди с большим опытом работы с продуктом, разница в успешности может объясняться составом групп.
По той же причине условия задания должны быть одинаковыми. Незаметное изменение формулировки иногда влияет на результат сильнее, чем изменение самого интерфейса.
Отдельного внимания требует статистическая неопределённость. Если в одной небольшой группе успешность составила 70%, а в другой — 76%, нельзя автоматически заключать, что второй дизайн лучше. Наблюдаемое различие может возникнуть из-за случайных колебаний выборки.
Здесь я рекомендую разделять два вопроса: есть ли основания считать различие устойчивым и достаточно ли оно велико, чтобы иметь продуктовое значение. Даже статистически заметное улучшение не обязательно оправдывает дорогостоящую переработку интерфейса. И наоборот, изменение в несколько процентных пунктов может быть критически важным для массового сценария с большим количеством пользователей.
Сегментация помогает увидеть скрытые проблемы
Средние значения иногда маскируют различия между группами. Допустим, общая успешность сценария составляет 84%. На первый взгляд результат выглядит достаточно высоким. Но после разделения участников оказывается, что среди опытных пользователей показатель достигает 95%, а среди новых значительно ниже.
Такой результат меняет интерпретацию. Возможно, интерфейс понятен после знакомства с продуктом, но плохо поддерживает первое использование.
Сегментацию, однако, тоже важно планировать осмысленно. Если после исследования разделить небольшую выборку на десятки групп по возрасту, опыту, устройствам и другим характеристикам, практически неизбежно найдутся необычные различия. Не каждое из них будет устойчивой закономерностью.
Поэтому основные сегменты лучше определить заранее, исходя из исследовательской гипотезы.
Поведение и ответы пользователя могут расходиться
Особенно полезно сопоставлять фактическое выполнение задания с субъективными оценками. Пользователь может успешно завершить сценарий, но назвать его сложным. Другой участник, наоборот, совершает ошибку и остаётся полностью уверен, что всё сделал правильно.
Если смотреть только на ответы анкеты, второй интерфейс может получить высокую оценку понятности. Если анализировать только факт завершения, мы не увидим, насколько неуверенно действовала первая группа.
Поэтому результаты количественного тестирования полезно анализировать в связке. В Тестографе можно работать с собранными ответами и анализировать результаты исследования, сопоставляя оценки разных вопросов и характеристики респондентов.
Главное — не превращать статистику в доказательство того решения, которое команда хотела принять заранее. Цифры уменьшают неопределённость, но не отменяют необходимости интерпретации.
Хороший итог количественного теста звучит не как «вариант B победил», а точнее: при заданных условиях и на исследованной аудитории вариант B показал лучший результат по выбранным критериям. Такая формулировка менее эффектна, зато гораздо честнее описывает то, что действительно удалось узнать.
После разговора о преимуществах количественного тестирования легко прийти к выводу, что достаточно увеличить выборку, определить метрики — и интервью становятся необязательными. На практике это работает иначе. Количественный метод особенно силён там, где мы уже знаем, что измерять. Если сама проблема ещё не определена, цифры могут лишь точно измерить не то, что действительно важно пользователю.
Представим ранний прототип нового сервиса. Команда ещё не уверена, соответствует ли предложенный сценарий привычной модели поведения аудитории. В этой ситуации показатель успешного выполнения задания мало что объяснит. Допустим, только половина участников справилась. Причиной может быть непонятная навигация, непривычная терминология, неверная последовательность действий или даже то, что сама задача не соответствует реальным потребностям пользователей.
Интервью и модерируемое UX-тестирование позволяют исследователю заметить эти различия. Можно увидеть момент затруднения, уточнить ожидания участника и разобраться, почему он выбрал определённый путь.
Сначала понять, затем измерить
В проектах я часто использую качественный и количественный подходы не как альтернативы, а как последовательные этапы одного исследования.
На первом этапе несколько интервью помогают обнаружить модели поведения и потенциальные барьеры. После этого команда изменяет прототип и формулирует конкретные гипотезы. На втором этапе эти гипотезы уже можно проверять количественно на более широкой выборке.
Например, в интервью выяснилось, что пользователи не понимают разницу между двумя вариантами тарифа. Исследователь разбирается, какие формулировки вызывают затруднения и какую информацию люди ожидают увидеть при выборе. Команда создаёт новую версию экрана.
Теперь возникает измеримый вопрос: увеличилась ли доля пользователей, которые выбирают подходящий вариант и правильно понимают его условия? Здесь количественный тест становится логичным продолжением интервью.
Возможен и обратный порядок. Количественное исследование показывает неожиданный результат — например, определённый сегмент значительно чаще остальных прекращает сценарий на одном шаге. Следующим исследованием можно провести интервью с представителями именно этой группы и разобраться в причинах.
Необязательно выбирать только один метод
Выбор метода я предлагаю начинать с характера неопределённости. Если команда не понимает причины поведения, нужны методы, позволяющие исследовать эти причины. Если причины уже достаточно изучены, но неизвестен масштаб проблемы, появляется задача количественной проверки.
На практике особенно полезны три последовательности:
Для количественного этапа можно использовать Тестограф, собирая стандартизированные ответы после взаимодействия с прототипом и сохраняя одинаковую структуру исследования для всех участников.
Главное преимущество смешанного подхода не в том, что команда получает «больше данных». Она получает данные разного типа, которые отвечают на разные вопросы.
Интервью может показать, почему пользователь не замечает функцию. Количественный тест — как часто это происходит. Следующее интервью — объяснить неожиданную разницу между сегментами. Новый количественный тест — проверить, помогло ли изменение интерфейса.
Поэтому противопоставление «интервью или количественное тестирование» не всегда полезно. Гораздо продуктивнее определить, какой тип неопределённости существует сейчас. Метод стоит выбирать не по привычке команды и не по желанию получить убедительный процент в отчёте, а по вопросу, на который предстоит ответить.
Перед запуском исследования я предлагаю сформулировать один вопрос: нам сейчас нужно понять причины поведения или измерить уже известное явление? Ответ часто позволяет выбрать метод быстрее, чем обсуждение преимуществ интервью и количественного тестирования в целом.
Если команда ещё не понимает, почему пользователи ошибаются, чего ожидают от интерфейса и какие элементы сценария вызывают затруднения, полезнее начать с интервью или модерируемого UX-теста. На этом этапе важны наблюдения, объяснения и возможность задать дополнительный вопрос.
Если проблема уже описана и необходимо выяснить, насколько часто она возникает, количественный тест становится более подходящим инструментом. То же относится к ситуациям, когда нужно сравнить две версии прототипа, оценить успешность выполнения задачи или проверить, изменился ли конкретный показатель после переработки интерфейса.
При этом сама по себе большая выборка не делает исследование сильным. До сбора данных необходимо определить целевую аудиторию, сформулировать нейтральное задание, выбрать метрики и решить, какой результат будет иметь практическое значение. Иначе команда рискует получить точные проценты без надёжного ответа на продуктовый вопрос.
Для количественного этапа исследования можно использовать Тестограф: например, организовать анкету вокруг сценария взаимодействия с прототипом, собрать оценки после выполнения заданий и затем проанализировать ответы участников.
В своей работе я рассматриваю интервью и количественное тестирование как два инструмента с разными задачами. Интервью помогает понять механизм проблемы. Количественное исследование позволяет проверить её масштаб и сравнить альтернативы. Нередко наиболее надёжный результат появляется именно при последовательном использовании обоих подходов.
Поэтому перед следующим тестированием прототипа полезно отказаться от вопроса «сколько интервью нам провести?» и сначала определить, какого знания не хватает для принятия решения. Если нужно узнать «почему?» — исследуйте глубже. Если «как часто?», «насколько успешно?» или «какой вариант показывает лучший результат?» — переходите к количественной проверке.