Когда клиент спрашивает меня, сколько человек нужно привлечь к тестированию прототипа, первое желание — назвать конкретную цифру. Например, 5, 10 или 20 респондентов. Это удобно для планирования бюджета и сроков, но с точки зрения методологии такой ответ почти всегда будет неполным. Для одного исследования пяти участников действительно может оказаться достаточно, а для другого даже 50 человек не позволят сделать надежный вывод.
Причина в том, что размер выборки при тестировании прототипа зависит прежде всего от того, какое решение мы собираемся принять на основании полученных данных. Если команда хочет найти основные препятствия в пользовательском сценарии, ей нужна одна выборка. Если необходимо сравнить две версии прототипа и понять, какая из них показывает лучшие результаты, требования к количеству респондентов будут уже другими. А если мы хотим получить количественный показатель и распространить выводы на большую аудиторию, подход к выборке меняется еще сильнее.
В работе с исследованиями я регулярно сталкиваюсь с попыткой перенести правила массовых опросов на UX-тестирование. Например, команда рассчитывает статистически репрезентативную выборку, хотя на текущем этапе ей нужно всего лишь обнаружить проблемы в сценарии оформления заказа. Бывает и обратная ситуация: продукт сравнивает две версии интерфейса на нескольких участниках и пытается интерпретировать небольшую разницу в результатах как доказательство превосходства одного варианта.
Важно разделять эти задачи. Тестирование прототипа — не всегда массовый опрос. Во многих случаях его цель состоит не в том, чтобы узнать, какой процент всей целевой аудитории столкнется с конкретной проблемой, а в том, чтобы обнаружить саму проблему, понять ее причины и проверить, мешает ли она пользователю выполнить задачу. Здесь ценность каждого участника определяется не только количеством собранных ответов, но и тем, какую информацию дает наблюдение за его действиями.
Поэтому вопрос «сколько нужно респондентов?» я обычно предлагаю переформулировать: «Сколько наблюдений нам необходимо, чтобы принять конкретное решение с приемлемым уровнем уверенности?» Такая постановка сразу заставляет определить цель тестирования, аудиторию, количество пользовательских сценариев и способ анализа результатов.
Например, если тестируется один достаточно простой сценарий для однородной аудитории, небольшая группа участников может быстро выявить повторяющиеся затруднения. Но если тем же продуктом пользуются сотрудники с разными ролями, новые и опытные клиенты или пользователи с принципиально разными задачами, объединять их в одну выборку опасно. Формально участников может быть много, но внутри каждого важного сегмента данных окажется недостаточно.
Есть и еще одно различие, которое стоит учитывать заранее. В качественном тестировании нас прежде всего интересуют паттерны поведения и причины проблем: где человек остановился, что понял неправильно, почему выбрал определенный элемент интерфейса. В количественном исследовании мы уже задаем вопросы вроде «какая доля пользователей успешно завершает сценарий?» или «есть ли измеримая разница между двумя вариантами?». Во втором случае небольшая выборка значительно сильнее ограничивает выводы.
В этой статье я разберу, как выбирать количество респондентов для разных видов тестирования прототипов, почему известное правило о пяти пользователях нельзя считать универсальным и в каких ситуациях выборку стоит увеличивать. Отдельно рассмотрим сегментацию аудитории, сравнительное тестирование и количественные задачи.
Цель — не вывести еще одно магическое число, а дать рабочую схему, по которой продуктовая команда, UX-исследователь или маркетолог сможет определить разумный размер выборки именно для своей задачи — без лишних расходов на респондентов и без уверенных выводов там, где данных для них пока недостаточно.
Количество респондентов имеет смысл определять только после того, как сформулирована цель тестирования. На практике именно здесь возникает значительная часть ошибок: команда сначала решает, что привлечет, например, 10 человек, а затем пытается уместить в эту выборку сразу несколько задач — проверить навигацию, оценить новый дизайн, сравнить две концепции и узнать отношение пользователей к продукту.
Я рекомендую двигаться в обратном порядке: сначала определить, что мы хотим узнать и какое решение примем после исследования, и только затем рассчитывать количество участников.
Поиск проблем в пользовательском сценарии
Одна из самых распространенных задач тестирования прототипа — проверить, сможет ли человек выполнить определенное действие. Например, зарегистрироваться, найти нужный тариф, оформить заказ, изменить параметры услуги или отправить заявку.
В таком исследовании нас интересует не столько процент успешных пользователей, сколько сами препятствия. Мы наблюдаем, где участник останавливается, какой элемент не замечает, как интерпретирует подписи и в какой момент начинает действовать не так, как предполагала продуктовая команда.
Для подобных задач обычно используется относительно небольшая выборка. Если первые участники сталкиваются с одной и той же проблемой, исследователь достаточно быстро получает сигнал, что соответствующий участок интерфейса требует внимания.
При этом я бы не советовал оценивать проблему только по частоте ее появления. Представим, что один из восьми участников не смог завершить оплату из-за непонятного элемента интерфейса. Формально это всего один случай. Но если такой сценарий критичен для бизнеса, единичного наблюдения уже достаточно, чтобы как минимум проверить проблему дополнительно.
Проверка понятности интерфейса
Другая задача — выяснить, насколько пользователю понятны отдельные элементы прототипа. Например:
Здесь также часто эффективна небольшая выборка, особенно если аудитория достаточно однородна. Однако количество участников приходится увеличивать, когда один и тот же интерфейс рассчитан на пользователей с разным уровнем опыта.
Например, термин, совершенно очевидный для специалиста, может оказаться непонятным новому клиенту. Если протестировать прототип только на опытных пользователях, исследование покажет, что проблемы нет. Фактически же мы проверили интерфейс только для одного сегмента.
Поэтому считать нужно не просто общее количество респондентов, а количество участников в каждой группе, различия между которыми потенциально влияют на результат.
Проверка продуктовой гипотезы
Формулировка «проверить гипотезу» требует особой осторожности. Под ней могут скрываться совершенно разные исследования.
Допустим, команда предполагает:
Такую гипотезу можно исследовать качественно: дать участникам соответствующую задачу, наблюдать за их действиями и выяснять причины поведения.
Но гипотеза может звучать иначе:
Это уже количественное утверждение. Чтобы оценить изменение доли и тем более сделать вывод о преимуществе одной версии, нескольких участников обычно недостаточно. Здесь потребуется более крупная выборка и заранее определенный способ сравнения результатов.
Разница принципиальная. В первом случае мы ищем объяснение поведения, во втором — пытаемся измерить эффект.
Сравнение двух вариантов прототипа
Еще одна ситуация, в которой легко недооценить необходимое количество респондентов, — сравнительное тестирование.
Предположим, есть варианты A и B. В первом пять из семи участников успешно выполнили задачу, а во втором — шесть из семи. На первый взгляд версия B выглядит лучше. Но выборка слишком мала, чтобы разница в одного человека сама по себе служила надежным доказательством.
Сравнительный тест нужно проектировать исходя из того, что именно сравнивается. Если задача заключается в поиске качественных различий — например, понять, почему одна структура меню воспринимается проще другой, — можно работать с небольшими группами. Если же нужно количественно доказать превосходство варианта B, требования к выборке возрастают.
Поэтому фраза «мы протестировали две версии» еще ничего не говорит о достаточности количества респондентов. Важнее понять, какой вывод команда собирается сделать из результатов.
Оценка метрик требует другого подхода
Иногда прототип тестируют с помощью измеримых показателей: доли успешно выполненных заданий, времени выполнения, количества ошибок, оценки удобства или ответов по шкале.
В таком исследовании данные уже выглядят количественными, и здесь возникает распространенная ловушка. Наличие числа еще не означает, что его можно уверенно распространять на всю аудиторию.
Допустим, восемь из десяти участников справились с заданием. Мы получили 80%, но это не означает автоматически, что ровно 80% целевой аудитории смогут выполнить тот же сценарий. При небольшой выборке результат чувствителен буквально к каждому участнику: еще два неуспешных прохождения заметно изменят итоговый процент.
Если команде нужен именно количественный вывод, размер выборки следует определять с учетом ожидаемого эффекта, требуемой точности и метода анализа.
Один прототип — несколько исследовательских задач
В проектах клиентов я часто вижу желание получить максимум информации за одно исследование. Само по себе это рационально: респондентов сложно рекрутировать, а время команды ограничено. Но объединение задач влияет на требования к выборке.
Представим прототип личного кабинета. Команда хочет одновременно проверить:
Фактически перед нами уже не одна исследовательская задача, а несколько. Для поиска очевидных UX-проблем может хватить небольшой группы, тогда как для сравнения двух сегментов или версий прототипа данных потребуется больше.
Поэтому перед запуском исследования полезно составить простую связку:
решение → исследовательский вопрос → метод → сегменты → необходимая выборка.
Сам опрос, скрининг участников и сбор дополнительных оценок можно организовать в Тестографе, но инструмент не заменяет этот методологический этап. Чем точнее сформулирована задача до начала сбора данных, тем проще определить, сколько респондентов действительно необходимо.
Главный принцип здесь простой: размер выборки определяется не прототипом как таковым, а выводом, который мы хотим получить после его тестирования. Для обнаружения проблемы, объяснения поведения и количественного доказательства эффекта нужны разные объемы данных. Именно поэтому универсальная рекомендация вроде «возьмите десять человек» без понимания цели исследования мало что дает.
В UX-исследованиях число пять встречается настолько часто, что иногда воспринимается почти как стандарт: достаточно протестировать прототип на пяти пользователях, обнаружить основные проблемы и переходить к доработке. У этого подхода есть рациональная основа, но проблема начинается тогда, когда ориентир превращается в универсальное правило.
В своей работе я рассматриваю пять респондентов не как необходимый и достаточный размер выборки, а как возможную стартовую точку для определенного типа качественного исследования. Иногда пяти участников действительно хватает. Иногда уже после третьего становится понятно, где находится критическая проблема. А в другом проекте после десяти интервью продолжают появляться совершенно новые наблюдения.
Откуда взялось правило пяти пользователей
Популярность небольших выборок в юзабилити-тестировании связана с простой закономерностью: если проблема встречается у значительной части пользователей, вероятность обнаружить ее возрастает с каждым новым участником.
Допустим, определенная проблема возникает примерно у каждого третьего пользователя. Тогда нам не обязательно опрашивать сотни человек, чтобы впервые с ней столкнуться. Несколько последовательных наблюдений уже дают достаточно высокую вероятность ее обнаружения.
При этом первые участники обычно приносят больше всего новых находок. По мере продолжения тестирования исследователь все чаще наблюдает проблемы, которые уже встречались раньше. Возникает эффект убывающей отдачи: каждый следующий участник дает меньше принципиально новой информации.
Именно эта логика делает небольшие выборки эффективными при поисковом качественном тестировании интерфейса.
Но из нее не следует, что пять человек обнаружат все проблемы или что результаты пяти пользователей можно считать репрезентативными для всей аудитории.
Что на самом деле можно узнать у пяти респондентов
Представим, что мы тестируем форму оформления заявки. Все участники относятся к одной аудитории и должны пройти одинаковый сценарий.
Первый пользователь не замечает кнопку продолжения. Второй пытается ввести данные в неправильном формате. Третий снова не замечает кнопку. Четвертый сомневается в значении одного из полей. Пятый повторяет проблему первого и третьего участников.
Такое исследование уже дает продуктовой команде полезный материал. Мы видим повторяющийся паттерн: кнопка продолжения может быть недостаточно заметной. Также появились две дополнительные точки, которые стоит проверить.
Однако из пяти наблюдений нельзя надежно заключить, что, например, «60% пользователей не замечают кнопку». Три человека из пяти — это действительно 60% внутри нашей небольшой группы, но превращать этот результат в оценку для всей пользовательской аудитории было бы некорректно.
Это важное различие между двумя выводами:
и
Первый вывод может быть полезен уже на небольшой качественной выборке. Второй требует количественного исследования с соответствующим размером выборки.
Пять пользователей — но каких именно?
Есть еще одна проблема, о которой часто забывают. Само количество участников ничего не говорит о качестве выборки.
Предположим, сервисом пользуются две группы: специалисты, которые работают с ним ежедневно, и клиенты, заходящие несколько раз в год. Их знание интерфейса, терминологии и сценариев может сильно различаться.
Если мы привлечем пять опытных специалистов, результаты будут описывать прежде всего их взаимодействие с продуктом. Добавление одного новичка не превращает выборку в полноценное исследование второй аудитории.
Поэтому вопрос нужно задавать не так:
а так:
Если различия между сегментами способны изменить поведение в тестируемом сценарии, каждый из них фактически становится отдельной исследовательской группой.
Например, схема «пять пользователей всего» и схема «по пять пользователей из каждого из трех принципиально разных сегментов» — это два совершенно разных исследования.
Когда пяти участников действительно может хватить
Небольшая группа особенно полезна, если прототип находится на ранней стадии, аудитория достаточно однородна, а задача исследования — быстро обнаружить очевидные препятствия.
Например, команда создала первый интерактивный прототип регистрации. Сейчас ей важно понять, замечают ли пользователи нужные элементы, правильно ли интерпретируют последовательность шагов и могут ли закончить регистрацию без подсказки.
В такой ситуации я бы скорее провел несколько коротких итераций, чем одно большое исследование.
Можно протестировать первую версию на небольшой группе, исправить обнаруженные проблемы, а затем показать измененный вариант следующим участникам. Такой подход часто дает продукту больше пользы, чем тестирование первоначального прототипа сразу на 20–30 людях.
Получается цикл:
Мы не пытаемся доказать статистическую надежность первоначального интерфейса. Наша задача — последовательно находить и устранять проблемы.
Когда пять респондентов — слишком мало
Я бы не ориентировался на правило пяти участников, если исследование предполагает сравнение нескольких существенно различающихся сегментов аудитории, количественную оценку показателей или доказательство преимущества одной версии прототипа над другой.
Также небольшая выборка становится рискованной, когда исследуется сложный продукт с большим количеством сценариев. Если каждый участник проходит только часть функций, фактическое количество наблюдений по конкретной задаче может оказаться совсем небольшим.
Например, мы привлекли десять человек для тестирования банковского приложения. Но сценарий изменения лимита карты прошли только трое. Для этого конкретного сценария наша выборка — фактически три человека, а не десять.
Поэтому при планировании я рекомендую считать не только респондентов, но и число наблюдений по каждому исследовательскому вопросу.
Редкие проблемы небольшой тест может не обнаружить
Есть и математическая причина не воспринимать пять участников как гарантию.
Если проблема распространена, она действительно с большой вероятностью проявится в небольшой группе. Но чем реже она встречается, тем легче полностью пропустить ее.
Условно, если вероятность столкнуться с определенной проблемой у одного пользователя составляет 30%, вероятность обнаружить ее хотя бы один раз среди пяти независимых участников равна:
Но если проблема встречается только у 10% пользователей:
То есть при таких предположениях пять участников с большей вероятностью вообще не покажут нам эту редкую проблему, чем покажут.
Эти расчеты не стоит воспринимать как способ заранее узнать реальную распространенность UX-проблемы — до исследования она нам обычно неизвестна. Они нужны для другого: показать, почему небольшая выборка хорошо обнаруживает частые и очевидные затруднения, но значительно хуже защищает от пропуска редких случаев.
Я использую пять как точку проверки, а не точку остановки
Для качественного тестирования полезнее заранее не устанавливать жесткое правило «пятый участник — последний». Я предпочитаю смотреть на результаты по мере их накопления.
После первых нескольких сессий стоит проверить:
Если новые респонденты в основном подтверждают уже известные наблюдения, а основные сценарии достаточно хорошо покрыты, исследование можно завершать. Если же почти каждый новый участник приносит значимую новую проблему, останавливаться только потому, что достигнуто заранее выбранное число, рано.
Поэтому правило пяти пользователей полезно воспринимать как напоминание о том, что качественному UX-тестированию далеко не всегда нужна большая выборка. Но оно не освобождает исследователя от проектирования выборки. Количество сегментов, сложность сценария, цель исследования и характер выводов остаются важнее любого универсального числа.
Для качественного тестирования я обычно не пытаюсь получить одно «правильное» число с помощью классического статистического калькулятора выборки. Здесь другая логика: нам важно собрать достаточно наблюдений, чтобы обнаружить существенные проблемы, увидеть повторяющиеся паттерны и перестать получать принципиально новую информацию от каждого следующего участника.
Поэтому рабочий расчет начинается не с формулы, а с четырех параметров: количества сегментов, числа сценариев, сложности прототипа и ожидаемого разнообразия поведения пользователей.
Начните с минимальной исследовательской группы
Для простого прототипа с одним основным сценарием и однородной аудиторией разумной стартовой точкой часто становятся 5–8 респондентов.
Например, мы тестируем форму записи на консультацию. Пользователь должен выбрать услугу, дату, время, заполнить контактные данные и подтвердить заявку. Все участники относятся к одному типу клиентов и выполняют одинаковое задание.
Я мог бы начать такое исследование с пяти человек, а после первых сессий решить, нужны ли дополнительные участники.
Здесь важно слово «начать». Мы не утверждаем заранее, что пяти человек обязательно хватит. Мы создаем первую исследовательскую итерацию, после которой оцениваем насыщение данных.
Используйте принцип насыщения
Насыщением в данном случае можно считать состояние, при котором новые участники преимущественно повторяют уже обнаруженные существенные паттерны, а количество действительно новых наблюдений заметно сокращается.
Предположим, после каждой сессии мы фиксируем новые проблемы:
| Респондент | Новые существенные проблемы |
| 1 | 5 |
| 2 | 3 |
| 3 | 2 |
| 4 | 1 |
| 5 | 1 |
| 6 | 0 |
| 7 | 0 |
Если шестой и седьмой участники в основном подтверждают уже известные проблемы, это один из сигналов, что для данного сценария и данной аудитории информации может быть достаточно.
Теперь представим другую картину:
| Респондент | Новые существенные проблемы |
| 1 | 4 |
| 2 | 4 |
| 3 | 3 |
| 4 | 3 |
| 5 | 2 |
| 6 | 3 |
| 7 | 2 |
Здесь я бы не советовал завершать исследование на седьмом участнике. Новые проблемы продолжают появляться слишком активно. Причина может быть в сложности интерфейса, неоднородности аудитории или слишком большом количестве проверяемых сценариев.
Само насыщение тоже нельзя оценивать механически. Если восьмой респондент первым обнаружил критическую проблему, из-за которой невозможно завершить оплату, ценность этого наблюдения гораздо выше нескольких мелких повторяющихся замечаний.
Считайте выборку отдельно для значимых сегментов
Одна из наиболее полезных практик — перестать воспринимать всю аудиторию как единую группу.
Предположим, B2B-сервисом пользуются менеджеры и администраторы. Менеджер создает документы и работает с клиентами, а администратор управляет пользователями, правами доступа и настройками компании.
Если мы набрали восемь респондентов — шесть менеджеров и двух администраторов, — фраза «прототип протестирован на восьми пользователях» звучит убедительнее, чем фактическая ситуация. Сценарии администратора проверили всего два человека.
В подобных случаях первоначальный ориентир можно устанавливать для каждого действительно отличающегося сегмента.
Например:
Если значимых сегмента два:
Но это не формула, которую нужно автоматически применять к любому проекту. Если поведение двух сегментов в тестируемом сценарии практически одинаково, искусственно удваивать выборку нет смысла. Сегментация нужна тогда, когда различия способны повлиять на результат.
Не умножайте выборку на каждый сценарий автоматически
Другая крайность — считать, что для каждого задания обязательно требуется отдельная группа.
Допустим, один участник может за разумное время пройти три связанных сценария: создать аккаунт, оформить заявку и проверить ее статус. Тогда одни и те же 6–8 человек могут дать наблюдения по всем трем задачам.
Но если прототип содержит десять длинных сценариев, провести каждого участника через все функции без потери качества уже сложно. Человек устает, начинает изучать интерфейс в процессе теста и во второй половине сессии действует иначе, чем новый пользователь.
Тогда сценарии можно распределить между группами.
Например, у нас есть 12 участников:
В этом случае в отчете важно указывать не только общее число респондентов, но и количество наблюдений по каждому сценарию.
Добавляйте резерв на отсев
Запланированная выборка и количество приглашенных участников — не одно и то же.
Если нам нужно получить десять качественных завершенных тестов, приглашать ровно десять человек рискованно. Кто-то может не соответствовать критериям после дополнительной проверки, кто-то не явится на модерируемую сессию, а результаты части участников придется исключить из-за технических проблем или нарушения условий теста.
Размер резерва зависит от способа рекрутинга и сложности критериев. В онлайн-исследованиях особенно полезно заранее настроить скрининговые вопросы, чтобы неподходящие участники не попадали в основную часть тестирования.
Для скрининга и последующего сбора ответов можно использовать Тестограф: например, разделить участников по опыту использования продукта, роли или другим значимым признакам и направить их по разным веткам анкеты.
Практические ориентиры
Если мне нужно предварительно оценить объем качественного тестирования еще до рекрутинга, я использую диапазоны, а не одно жесткое число.
Если есть два существенно различающихся сегмента, я бы планировал небольшую исследовательскую группу внутри каждого сегмента — например, по 5–8 человек, а не распределял пять участников между всеми аудиториями.
Для сложного профессионального продукта, где поведение пользователей сильно зависит от опыта, роли и контекста работы, выборка может увеличиться до 10–15 и более участников на значимый тип пользователей. Но и здесь окончательное решение лучше принимать по результатам промежуточного анализа.
Эти диапазоны — не статистические нормативы. Они нужны для первоначального планирования времени, бюджета и рекрутинга.
Планируйте исследование итерациями
На практике мне нравится схема, при которой часть доступного бюджета на респондентов остается в резерве.
Допустим, команда готова привлечь максимум 12 участников. Вместо того чтобы сразу назначать все 12 сессий, можно провести первые 5–6, разобрать результаты и решить, что делать дальше.
Если основные проблемы повторяются, следующие участники могут протестировать уже исправленный прототип. Если результаты противоречат друг другу, мы продолжаем исследование первоначальной версии. Если обнаружилось, что различия связаны с опытом пользователей, резерв можно направить на недостающий сегмент.
Такой подход делает выборку управляемой. Мы не просто выполняем заранее установленный план по количеству интервью, а используем каждого следующего респондента для уменьшения конкретной неопределенности.
В итоге для качественного тестирования прототипа я бы использовал следующий принцип:
Так мы получаем не формально красивое число участников, а объем данных, достаточный для конкретного продуктового решения.
Увеличивать выборку стоит не потому, что «чем больше респондентов, тем лучше». В качественном тестировании дополнительные участники полезны только тогда, когда они помогают проверить то, что предыдущая группа проверить не могла. Поэтому перед расширением исследования я обычно задаю вопрос: какую новую информацию должны дать следующие респонденты?
Есть несколько ситуаций, в которых ответ на него очевиден.
В аудитории есть разные сегменты
Самая частая причина увеличить выборку — неоднородность пользователей. Причем сегментировать аудиторию следует не по любым доступным характеристикам, а по тем признакам, которые потенциально меняют поведение в тестируемом сценарии.
Например, возраст сам по себе не всегда требует отдельных групп. Если люди разных возрастов используют продукт одинаковым способом и решают одну задачу, делить выборку только ради демографического признака необязательно.
Гораздо важнее могут оказаться:
Представим сервис для управления проектами. Руководитель создает проекты и распределяет права, исполнитель работает с задачами, а бухгалтер выгружает документы. Формально все они пользователи одного продукта, но с исследовательской точки зрения это три разных контекста.
Если новый прототип затрагивает функции всех трех ролей, пять участников, распределенных между ними, дадут слишком фрагментарную картину.
Новички и опытные пользователи ведут себя по-разному
Опыт использования продукта — характеристика, которую я рекомендую проверять особенно внимательно.
Постоянный пользователь уже знает расположение элементов, терминологию и логику системы. Иногда он успешно проходит неудачно спроектированный сценарий просто потому, что помнит, как это делалось раньше.
Новый пользователь такого преимущества не имеет.
Если прототип должен быть понятен обеим группам, имеет смысл включить в тест и новичков, и опытных пользователей. Причем результаты лучше анализировать раздельно.
Иначе можно получить среднюю картину, которая скрывает важную проблему. Например, семь из десяти участников успешно выполнили задание. Но после сегментации выясняется, что справились все пять постоянных пользователей и только двое из пяти новичков. Для продуктовой команды это намного более содержательный результат, чем общие 70%.
Проверяются разные устройства
Один и тот же сценарий на компьютере и смартфоне фактически может оказаться двумя разными пользовательскими опытами.
Меняется размер экрана, расположение элементов, способ ввода, навигация и контекст использования. Поэтому результаты тестирования десктопного прототипа нельзя автоматически переносить на мобильную версию.
Если обе платформы критичны для продукта, выборку следует планировать так, чтобы получить достаточное количество наблюдений на каждой из них.
При этом не всегда нужно просто удваивать количество участников. Если большая часть интерфейса одинакова, можно распределить наиболее важные сценарии между группами. Главное — заранее понимать, какие элементы действительно требуют отдельной проверки.
Сценарий сложный или разветвленный
Чем больше вариантов прохождения предусмотрено в прототипе, тем меньше вероятность, что небольшая группа естественным образом покроет их все.
Представим оформление страхового продукта. Один пользователь выбирает стандартные параметры, другой добавляет членов семьи, третий меняет дополнительные опции, четвертый сталкивается с особым условием расчета.
Если протестировать только базовый путь, мы можем получить очень чистый результат и при этом ничего не узнать о проблемах в альтернативных ветках.
В таком случае выборку увеличивают не ради количества как такового, а ради покрытия значимых сценариев.
Перед рекрутингом полезно составить матрицу:
Она быстро показывает пробелы. Например, у нас может быть 20 респондентов в целом, но только два наблюдения по важному мобильному сценарию для новых клиентов.
Результаты участников противоречат друг другу
Иногда небольшая группа не показывает устойчивого паттерна.
Три человека без труда находят функцию, двое долго ее ищут, еще двое идут совершенно другим путем. В такой ситуации увеличение выборки может помочь понять, случайны ли различия или за ними стоит конкретный фактор.
Но я бы не стал просто добавлять еще десять человек. Сначала полезно изучить уже полученные данные.
Возможно, первые три участника были постоянными пользователями, а остальные — новичками. Тогда нам нужна не просто большая выборка, а дополнительная проверка конкретной гипотезы о влиянии опыта.
Дополнительные респонденты особенно ценны, когда мы понимаем, какое противоречие хотим разрешить.
Каждый новый участник продолжает находить существенные проблемы
Это один из наиболее очевидных признаков того, что останавливаться рано.
Если на восьмой или девятой сессии мы продолжаем регулярно обнаруживать новые критические препятствия, данные еще не достигли насыщения. Возможно, прототип слишком сложный или исследование охватывает слишком много задач одновременно.
В такой ситуации есть два варианта: увеличить выборку либо сузить исследование.
Второй вариант иногда оказывается эффективнее. Вместо того чтобы приглашать еще 15 человек для тестирования огромного продукта, можно выделить два наиболее рискованных сценария и сосредоточить следующую итерацию именно на них.
Нужно проверить редкий, но важный случай
Не все UX-проблемы встречаются часто. При этом редкая проблема может иметь высокую цену.
Например, большинство пользователей успешно оформляет заказ, но определенный тип клиента при специфической комбинации параметров не может перейти к оплате. Случай редкий, но его последствия непосредственно влияют на выручку.
Обычная небольшая выборка может вообще не включить таких пользователей. Тогда эффективнее не увеличивать ее случайным образом, а целенаправленно рекрутировать людей, соответствующих нужному сценарию.
Для этого до основной части исследования можно провести скрининг. В Тестографе условия показа вопросов и логика переходов позволяют разделять участников по заданным критериям и строить разные маршруты прохождения исследования.
География действительно влияет на использование продукта
Если продукт работает на нескольких рынках, возникает желание автоматически набрать респондентов из каждой страны. Это не всегда необходимо.
Отдельные географические группы нужны, когда есть основания ожидать различия: язык интерфейса, способы оплаты, локальные привычки, законодательные требования, форматы адресов, валюты или другие особенности сценария.
Если таких различий нет, география сама по себе еще не делает пользователей разными с точки зрения конкретной UX-задачи.
Это общий принцип сегментации: добавляйте группу не потому, что она существует в аналитике, а потому, что принадлежность к ней способна изменить результат тестирования.
Увеличение выборки не исправляет плохой дизайн исследования
Наконец, важно помнить, что большее количество респондентов не компенсирует методологические ошибки.
Если участникам дали наводящее задание, прототип не позволяет реалистично выполнить сценарий или выборка состоит не из целевой аудитории, привлечение дополнительных людей лишь увеличит объем данных сомнительного качества.
Поэтому перед расширением исследования я проверяю три вещи: действительно ли нам не хватает наблюдений, понимаем ли мы, для какого сегмента или сценария их не хватает, и изменят ли дополнительные данные продуктовое решение.
Если на эти вопросы есть конкретные ответы, выборку стоит увеличивать. Если же единственный аргумент звучит как «20 человек надежнее, чем 10», сначала лучше вернуться к цели исследования и структуре выборки.
Как только задача меняется с «найти проблемы в прототипе» на «измерить результат» или «сравнить две версии», ориентиры в 5–8 участников перестают работать так же, как в качественном UX-тестировании. Здесь нас интересует уже не только наличие определенного поведения, но и его частота, величина различий и устойчивость результата.
Поэтому на вопрос «сколько респондентов нужно для A/B-теста прототипа?» я не называю фиксированное число. В количественном исследовании размер выборки зависит от того, какую разницу мы хотим обнаружить и насколько уверенным должен быть вывод.
Почему 10 человек недостаточно для уверенного сравнения двух вариантов
Представим, что мы тестируем два прототипа формы регистрации.
На уровне описания результатов все верно: в нашей выборке вариант B показал результат выше. Ошибка возникает, если после этого сделать вывод: «Версия B лучше на 10 процентных пунктов, поэтому запускаем ее».
При столь небольшом количестве наблюдений результат каждого человека сильно влияет на итоговый процент. Если бы в группе B еще один участник не справился с заданием, показатели сравнялись бы. Если бы один дополнительный участник успешно завершил сценарий A, разница стала бы заметно меньше.
Поэтому при маленькой выборке я предпочитаю формулировку:
Это не делает тест бесполезным. Мы можем анализировать причины ошибок, наблюдать различия в поведении и использовать результаты для формирования следующей гипотезы. Просто уровень доказательности будет другим.
Размер выборки зависит от ожидаемой разницы
Для количественного сравнения принципиально важно, насколько большой эффект мы хотим обнаружить.
Если один прототип позволяет выполнить задачу 50% пользователей, а второй — 90%, столь крупное различие обнаружить значительно проще.
Гораздо сложнее отличить 75% от 80%. Чем меньше ожидаемая разница, тем больше наблюдений обычно потребуется, чтобы отделить реальный эффект от случайных колебаний выборки.
Поэтому нельзя сказать:
Сначала необходимо определить минимальную разницу, которая вообще имеет практический смысл.
Предположим, новый интерфейс повышает успешность выполнения сценария с 80% до 81%. Даже если на огромной выборке такое изменение окажется статистически различимым, возникает продуктовый вопрос: оправдывает ли один процентный пункт стоимость разработки и внедрения?
Размер выборки лучше рассчитывать относительно минимального практически значимого эффекта, а не просто стремления получить статистически значимый результат.
Пример расчета для двух вариантов
Допустим, текущий прототип позволяет успешно завершить сценарий примерно 60% пользователей. Команда считает практически важным улучшение до 80%.
Если планируется классическое сравнение двух независимых долей при уровне значимости 5% и мощности 80%, ориентировочно потребуется около 80 респондентов на каждый вариант, то есть порядка 160 участников суммарно.
Если же команда хочет обнаружить гораздо меньший эффект — например, изменение с 60% до 70%, — требуемая выборка будет уже значительно больше: ориентировочно 350–360 человек на вариант при тех же базовых статистических предпосылках.
Это хороший пример того, почему в количественном тестировании невозможно заранее назвать универсальный объем выборки. Мы изменили ожидаемый эффект всего на 10 процентных пунктов — и получили совершенно другой масштаб исследования.
Конкретный расчет следует делать до запуска теста с учетом выбранного статистического метода, исходного уровня метрики, минимального эффекта, уровня значимости и требуемой мощности.
Если нужна оценка одной метрики
Не всегда требуется сравнивать два прототипа. Иногда команда хочет оценить один вариант и ответить, например, на вопрос:
«Какая доля пользователей сможет самостоятельно выполнить задачу?»
Тогда на размер выборки влияет желаемая точность оценки.
Для простой случайной выборки можно использовать классическую формулу оценки доли:
n = z² × p × (1 − p) / e²,
где:
n — необходимое количество наблюдений;
z — коэффициент, соответствующий выбранному уровню доверия;
p — предполагаемая доля;
e — допустимая погрешность.
Если заранее неизвестно значение p, для консервативной оценки часто используют 0,5 — при нем необходимая выборка получается максимальной.
Например, при доверительном уровне 95% и допустимой погрешности ±10 процентных пунктов ориентир составляет примерно 96 респондентов.
При погрешности ±5 процентных пунктов — уже около 385 респондентов.
Это хорошо показывает цену точности: уменьшение допустимой ошибки в два раза увеличивает необходимую выборку примерно в четыре раза.
Но и эти числа не следует автоматически применять к любому тестированию прототипа. Формула предполагает определенную модель выборки, а реальные UX-исследования могут иметь ограничения рекрутинга, квоты и другие особенности.
Не путайте количество ответов и качество выборки
Даже 500 заполненных анкет не помогут, если респонденты не соответствуют целевой аудитории.
Представим B2B-продукт для финансовых директоров. Получить 500 случайных интернет-пользователей проще, чем найти 100 представителей нужной профессиональной группы. Но большая случайная аудитория не делает исследование более надежным для продукта.
В количественном тестировании особенно важно заранее определить критерии включения:
Для отбора респондентов можно создать отдельный скрининговый блок в Тестографе, а затем с помощью логики опроса направлять подходящих участников к нужной версии задания.
Если сегментов несколько, общий размер выборки может вводить в заблуждение
Допустим, в исследовании участвуют 200 человек. На первый взгляд это уже солидная выборка.
Но затем выясняется, что:
Если продуктовой команде важно отдельно оценить поведение новичков, для этого вопроса у нас фактически только десять наблюдений.
То же происходит при сравнении прототипов. Если мы хотим одновременно сравнить версии A и B среди новых и опытных пользователей, данные начинают делиться уже на четыре аналитические группы:
Именно поэтому выборку нужно рассчитывать на уровне тех групп, между которыми мы действительно собираемся делать количественные сравнения.
Количественный тест не всегда нужен на раннем этапе
Иногда команда пытается провести статистически полноценное сравнение слишком рано.
Если оба прототипа содержат очевидные проблемы, привлекать сотни респондентов для точного измерения разницы между ними может быть нерационально. Сначала дешевле провести небольшое качественное тестирование, устранить основные препятствия и только затем переходить к количественной проверке наиболее перспективных решений.
На практике хорошо работает последовательность:
Так качественная и количественная методологии не конкурируют между собой, а решают разные задачи на разных этапах разработки.
В итоге для сравнительного и количественного тестирования главный ориентир — не минимальное количество людей, которое удастся привлечь. Нужно заранее определить метрику, практически значимый эффект, требуемую точность и группы, по которым будет проводиться анализ. Только после этого можно обоснованно ответить, нужны ли проекту 50, 150 или несколько сотен респондентов.
Даже правильно рассчитанная общая выборка может оказаться бесполезной, если респонденты неправильно распределены между сегментами и версиями прототипа. Например, фраза «в тестировании участвовали 60 человек» звучит убедительно. Но если 50 из них увидели вариант A и только 10 — вариант B, возможности корректного сравнения будут ограничены.
Поэтому при планировании я смотрю не только на итоговое число участников, но и на минимальное количество наблюдений в каждой группе, по которой команда собирается делать отдельный вывод.
Один сегмент и один прототип
Это наиболее простая схема.
Допустим, мы тестируем новый сценарий восстановления пароля среди действующих пользователей. Существенного разделения аудитории нет, все участники получают одинаковое задание и работают с одной версией прототипа.
Для поискового качественного исследования можно начать, например, с 5–8 респондентов и затем оценить насыщение данных.
Схема будет выглядеть так:
При этом число 5–8 остается ориентиром для стартовой качественной итерации, а не гарантией достаточности выборки.
Теперь представим, что новый сценарий должны использовать две принципиально разные аудитории: новые и постоянные клиенты.
Если различия в опыте могут влиять на поведение, я не стал бы набирать восемь человек и случайно распределять их между группами. Может получиться шесть постоянных клиентов и всего два новых.
Логичнее установить ориентир отдельно:
Итого для качественного теста получится примерно 10–16 участников.
Здесь мы увеличиваем выборку не потому, что «16 надежнее 8», а потому, что фактически проводим два связанных исследования одного прототипа.
Допустим, аудитория однородна, но есть прототипы A и B.
Если задача качественная — разобраться, как пользователи воспринимают разные решения, — можно распределить участников между вариантами. Однако при очень маленьких группах сравнение будет скорее исследовательским, чем доказательным.
Например:
Всего — 12.
Такая схема способна показать характерные различия. Например, пользователи варианта A регулярно не замечают фильтр, тогда как у участников варианта B проблема не возникает. Это повод внимательнее изучить решение, но не основание утверждать, что B статистически лучше для всей аудитории.
Если цель — именно количественно доказать различие, выборку для A и B необходимо рассчитывать статистически, как мы разобрали в предыдущей главе.
Два сегмента и две версии
Здесь план исследования начинает заметно усложняться.
Предположим, мы сравниваем A и B отдельно среди новичков и опытных пользователей. Получаем четыре группы:
| Группа | Сегмент | Версия |
| 1 | Новички | A |
| 2 | Новички | B |
| 3 | Опытные | A |
| 4 | Опытные | B |
Если мы хотим иметь по шесть качественных наблюдений в каждой ячейке:
Это одна из причин, почему выборка быстро растет при усложнении дизайна исследования.
Если добавить еще мобильную и десктопную версии и требовать независимые наблюдения для каждой комбинации, теоретически получим уже восемь групп. Поэтому перед умножением сегментов я всегда проверяю, действительно ли нам нужен отдельный вывод по каждой комбинации.
Не создавайте сегменты «на всякий случай»
В исследованиях легко увлечься детализацией.
Команда может захотеть отдельно посмотреть результаты мужчин и женщин, пользователей 18–24, 25–34 и 35–44 лет, жителей разных городов, новых и постоянных клиентов, владельцев iOS и Android.
После пересечения этих признаков выборка распадается на десятки маленьких групп. Чтобы наполнить каждую достаточным количеством наблюдений, потребуется огромное число респондентов.
Поэтому для каждого сегмента я задаю два вопроса:
Если оба ответа отрицательные, выделять отдельную квоту чаще всего не нужно.
Следите за фактическим распределением
Даже если квоты запланированы правильно, реальный сбор данных может пойти иначе.
Предположим, нам нужны:
После запуска исследования выясняется, что постоянные клиенты заполняют анкету гораздо активнее. Мы получаем 80 ответов от них и только 20 от новичков.
Всего — необходимые 100 ответов, но исследовательская задача не выполнена.
Поэтому при сборе данных я рекомендую контролировать наполнение групп в процессе, а не после закрытия исследования. В онлайн-опросе можно использовать скрининговые вопросы и ветвление, чтобы определить сегмент участника до основного задания.
Если исследование проводится через Тестограф, структуру анкеты удобно строить так, чтобы сначала определить характеристики респондента, а затем показать ему соответствующий сценарий или блок вопросов.
Рандомизация важна при сравнении версий
Когда участники распределяются между прототипами A и B, лучше избегать ситуации, в которой принадлежность к группе определяется удобством рекрутинга.
Например, в понедельник мы тестируем A, а через две недели — B. За это время могла измениться аудитория, источник трафика, рекламная кампания или сам контекст использования продукта.
Тогда различия между результатами могут быть связаны не только с интерфейсом.
При количественном сравнении предпочтительнее случайное распределение подходящих участников между вариантами при одинаковых условиях проведения теста. Это снижает вероятность систематических различий между группами.
Если один и тот же респондент последовательно оценивает оба варианта, возникает другая проблема: знакомство с первым прототипом способно повлиять на работу со вторым. Пользователь уже знает задачу, терминологию и ожидаемый результат.
Такой дизайн возможен, но порядок показа версий нужно учитывать при планировании исследования.
Сначала составьте матрицу, потом называйте размер выборки
Перед рекрутингом я рекомендую сделать небольшую таблицу, где строки — это значимые сегменты, а столбцы — версии или сценарии.
Например:
| Сегмент | Прототип A | Прототип B |
| Новые пользователи | 6 | 6 |
| Опытные пользователи | 6 | 6 |
Сразу становится видно, что минимальный план для такого качественного исследования — 24 завершенных теста.
Если предполагается отсев, количество приглашений должно быть больше. Например, при ожидаемой доле пригодных и завершенных ответов 80% для получения 24 результатов ориентировочно понадобится:
Если пригодных завершений ожидается только 60%:
Такой расчет полезнее абстрактного «давайте наберем 30 человек», потому что показывает, откуда появилась цифра и какие группы должны быть заполнены.
Главный принцип распределения выборки можно сформулировать так: считайте не только людей, считайте аналитические группы. Если по определенному сегменту, сценарию или версии вы собираетесь делать самостоятельный вывод, убедитесь, что именно внутри этой группы накоплено достаточно наблюдений. Большое общее количество респондентов не компенсирует пустые или слишком маленькие ячейки исследовательского дизайна.
Тестирование прототипа не обязательно ограничивать модерируемой сессией, где исследователь наблюдает за пользователем и задает вопросы. Часть задач можно перенести в формат онлайн-опроса: показать респонденту прототип или дать ссылку на него, сформулировать задание, а после выполнения собрать ответы о результате, сложностях и восприятии интерфейса.
Такой формат особенно полезен, когда нужно привлечь больше участников, проверить несколько сегментов или дополнить качественные наблюдения количественными данными. Но анкета должна быть спроектирована так, чтобы не подсказывать пользователю правильный путь.
Начните со скрининга
Первый блок исследования должен отвечать на вопрос: тот ли человек проходит тест?
Если прототип предназначен для бухгалтеров малого бизнеса, ответы случайных офисных сотрудников вряд ли будут равноценной заменой. Если проверяется первый опыт использования сервиса, человек, который работает с ним три года, относится уже к другой исследовательской группе.
В скрининг стоит включать только признаки, которые действительно определяют пригодность респондента или его сегмент. Например, роль, опыт использования продукта, частоту выполнения нужной задачи.
Я стараюсь не объяснять участнику слишком подробно, какой именно человек нам нужен. Иначе появляется риск получить желательные ответы. Вместо вопроса «Вы регулярно покупаете авиабилеты самостоятельно?» иногда полезнее спросить о частоте покупки и затем определить подходящую группу по ответу.
Давайте задачу, а не инструкцию по интерфейсу
Одна из самых частых ошибок — формулировка задания, которая фактически объясняет, куда нажать.
Например:
Так мы проверяем способность человека следовать инструкции, а не понятность прототипа.
Лучше поставить задачу:
Теперь пользователь самостоятельно решает, где искать информацию и какие элементы интерфейса использовать.
По той же причине названия кнопок и разделов, которые мы хотим проверить, лучше не повторять в задании без необходимости.
Не задавайте оценочный вопрос слишком рано
После взаимодействия с прототипом хочется сразу спросить: «Насколько удобным был интерфейс?»
Но субъективная оценка сама по себе мало объясняет поведение.
Человек может поставить 9 из 10 и при этом дважды ошибиться при выполнении основной задачи. Или поставить 6, хотя успешно и быстро завершил сценарий, потому что ему не понравился цвет или визуальный стиль.
Поэтому сначала полезнее зафиксировать результат:
И только после этого переходить к шкалам удобства, понятности или удовлетворенности.
Сочетайте закрытые и открытые вопросы
Закрытые вопросы удобны для последующего анализа. Например:
Но если ограничиться только ими, мы узнаем результат и почти ничего — о причине.
Поэтому после ключевых действий я добавляю один короткий открытый вопрос. Например:
или:
Открытый вопрос особенно ценен, если ответ респондента оказался неожиданным. Именно в таких комментариях часто обнаруживаются формулировки, которые исследователь не предусмотрел при составлении вариантов ответа.
При этом не стоит после каждого клика спрашивать пользователя, что он думает. Чем сильнее анкета вмешивается в сценарий, тем менее естественным становится поведение.
Разделяйте наблюдение и самоотчет
Есть принципиальная разница между тем, что пользователь сделал, и тем, что он рассказал о своих действиях.
Если респондент говорит «все было понятно», это не доказывает отсутствие UX-проблем. Аналогично ответ «я бы точно воспользовался этой функцией» не равен реальному использованию после запуска продукта.
Поэтому, когда техническая организация теста позволяет это сделать, я сопоставляю несколько типов данных:
Такой набор гораздо информативнее одного вопроса «Понравился ли вам прототип?».
Используйте ветвление для разных результатов
Не всем участникам нужно показывать одинаковые дополнительные вопросы.
Если человек успешно завершил сценарий, можно уточнить, насколько легко ему было это сделать и были ли моменты сомнения.
Если пользователь не справился, полезнее спросить, на каком этапе возникла проблема и что он ожидал увидеть.
То же относится к сегментам. Новым и постоянным пользователям можно показывать разные уточняющие блоки, сохраняя общую часть исследования для сравнения.
В Тестографе для такой структуры можно использовать логику показа вопросов и разные ветки прохождения анкеты. Это позволяет не создавать отдельный опрос для каждого типа респондентов и при этом не перегружать человека нерелевантными вопросами.
Не превращайте UX-тест в длинную анкету
При удаленном немодерируемом исследовании особенно велик соблазн добавить еще несколько вопросов «раз уж человек уже пришел».
В результате после трехминутного взаимодействия с прототипом участник получает двадцатиминутную анкету об отношении к бренду, удовлетворенности продуктом и намерении рекомендовать его знакомым.
Я рекомендую для каждого вопроса применять простой фильтр:
Если команда не понимает, что будет делать с результатом, вопрос, вероятно, можно убрать.
Короткая анкета снижает утомление и помогает сохранить внимание на тестируемом сценарии.
Пример структуры исследования
Для относительно простого немодерируемого тестирования структура может выглядеть следующим образом:
Если тестируется несколько независимых сценариев, блоки «задание → результат → диагностика» можно повторить.
Онлайн-опрос не заменяет наблюдение во всех случаях
У немодерируемого формата есть ограничения. Исследователь не видит часть контекста, не всегда может понять причину неожиданного действия и не способен сразу задать уточняющий вопрос.
Поэтому для раннего и сложного прототипа я часто предпочитаю сначала провести несколько модерируемых сессий. Они помогают понять язык пользователей и обнаружить неизвестные проблемы. После этого можно построить более структурированный онлайн-тест и привлечь дополнительную выборку.
Получается полезная комбинация:
Сам по себе онлайн-опрос не делает исследование количественным и не решает вопрос достаточности выборки. Это способ организации сбора данных. Методологическая задача остается прежней: определить, кого мы тестируем, какое поведение измеряем и какой вывод хотим сделать на основании полученных ответов.
После всех расчетов главный вывод остается достаточно простым: количество респондентов для тестирования прототипа определяется не самим прототипом, а исследовательской задачей. Поэтому я не рекомендую начинать планирование с вопроса «нам нужно 5, 10 или 100 человек?». Сначала стоит определить, какой вывод команда хочет получить и насколько уверенным он должен быть.
Для первичного качественного тестирования простого сценария я обычно рассматриваю 5–8 представителей одной однородной аудитории как разумную стартовую группу. Это не норматив и не гарантия обнаружения всех проблем. После первых сессий нужно посмотреть, продолжают ли появляться новые существенные наблюдения. Если да — тестирование продолжается. Если новые участники преимущественно повторяют уже обнаруженные паттерны, данных для текущей итерации может быть достаточно.
Практические ориентиры можно свести в таблицу:
| Задача | Возможный ориентир | Что учитывать |
| Найти основные проблемы простого сценария | 5–8 | Одна относительно однородная аудитория |
| Проверить несколько связанных сценариев | 6–10 | Каждый сценарий должен получить достаточно наблюдений |
| Проверить два существенно разных сегмента | 5–8 на сегмент | Результаты анализируются раздельно |
| Исследовать сложный профессиональный продукт | 10–15+ на значимый тип пользователей | Роли и опыт могут сильно менять поведение |
| Качественно сравнить два прототипа | Небольшая группа на каждый вариант | Можно искать различия, но не доказывать их статистически |
| Количественно сравнить A и B | Рассчитывается отдельно | Зависит от ожидаемого эффекта, мощности и уровня значимости |
| Оценить долю с погрешностью около ±10 п. п. при 95% доверии | Около 96 | Ориентир для простой случайной выборки при p = 0,5 |
| Оценить долю с погрешностью около ±5 п. п. при 95% доверии | Около 385 | Требования к выборке резко растут с повышением точности |
Эту таблицу я бы использовал именно как навигацию, а не как готовый калькулятор. Например, наличие двух сегментов еще не означает, что выборку обязательно нужно удвоить. Сначала следует понять, способны ли различия между этими сегментами повлиять на прохождение тестируемого сценария.
Быстрый способ определить свой диапазон
Представим, что команда подготовила новый прототип оформления заказа. Есть одна основная аудитория, один критичный сценарий, а задача исследования — найти препятствия до начала разработки. Здесь логично начать с небольшой качественной группы, например с 5–8 человек.
Теперь изменим условия. Тем же интерфейсом пользуются новые и постоянные клиенты, причем постоянные уже знакомы со старой версией. Нам важно проверить обе группы. Тогда первоначальный ориентир может вырасти примерно до 10–16 участников — по 5–8 на каждый значимый сегмент.
Еще раз меняем задачу. Теперь у команды есть варианты A и B и необходимо не просто посмотреть на поведение пользователей, а доказать, что один вариант повышает долю успешно выполненных заказов. В этот момент ориентир «по пять человек» перестает быть подходящим. Необходим статистический расчет выборки под ожидаемую разницу.
Именно поэтому два внешне похожих тестирования одного и того же интерфейса могут требовать совершенно разного количества участников.
Что проверить до начала рекрутинга
Перед запуском исследования я рекомендую зафиксировать пять вещей в одном коротком документе: какое решение будет принято по результатам теста, кто является целевым пользователем, какие сценарии проверяются, какие сегменты нужно анализировать отдельно и будет ли вывод качественным или количественным.
Этой проверки часто достаточно, чтобы обнаружить проблему еще до сбора данных. Например, команда планировала 12 респондентов, но после составления исследовательской схемы выяснилось, что хочет сравнить два прототипа внутри трех разных пользовательских групп. Формально 12 человек выглядят как нормальная выборка для небольшого UX-теста, но после распределения получится всего по два наблюдения на каждую комбинацию сегмента и версии.
Не стремитесь получить максимальную выборку
В тестировании прототипов больше данных не всегда означает лучшее исследование. Если интерфейс находится на ранней стадии и первые шесть пользователей столкнулись с одной и той же критической проблемой, иногда рациональнее исправить ее и провести следующую итерацию, чем продолжать показывать заведомо проблемный вариант еще двадцати людям.
Я предпочитаю планировать такие исследования с резервом. Например, предусмотреть возможность привлечь до 12 человек, но сначала провести шесть сессий. После анализа решить, нужны ли еще шесть для подтверждения наблюдений, следует ли привлечь недостающий сегмент или лучше сначала изменить прототип.
Так выборка становится частью исследовательского процесса, а не числом, которое необходимо выполнить ради отчета.
Какой ответ дать на вопрос «сколько респондентов нужно?»
Если речь идет о качественном тестировании простого прототипа с одной однородной аудиторией, можно начать примерно с 5–8 участников и оценивать насыщение результатов. При нескольких существенно различающихся аудиториях такой ориентир следует рассматривать отдельно для каждого значимого сегмента.
Если требуется количественно оценить метрику или доказать различие между вариантами, фиксированного универсального числа уже нет. Выборку нужно рассчитывать с учетом метрики, требуемой точности, ожидаемого эффекта и структуры групп.
Организовать скрининг, разделить аудиторию на нужные группы и собрать ответы для последующего анализа можно с помощью Тестографа. Но я бы не начинал исследование с настройки анкеты. Сначала — исследовательский вопрос и решение, которое будет принято на основании данных. Затем — сегменты и сценарии. И только после этого — количество респондентов и способ сбора ответов.
Если сохранить эту последовательность, вопрос о размере выборки становится намного практичнее. Вместо попытки найти универсальное число мы определяем минимальный объем данных, достаточный для конкретного решения. Именно такой подход помогает не тратить бюджет на лишние интервью и одновременно не делать сильных выводов по слишком маленькой выборке.