Когда у команды есть два варианта прототипа, выбор часто происходит быстрее, чем его успевают проверить. Дизайнер аргументирует решение привычными паттернами, продакт смотрит на бизнес-логику, разработчики оценивают сложность реализации, а руководитель может предпочесть вариант, который кажется ему понятнее. В итоге обсуждение постепенно сводится к вопросу: «Какой вариант нам нравится больше?»
Проблема в том, что будущий пользователь в этом обсуждении не участвует.
В работе с исследованиями я регулярно сталкиваюсь с похожей ситуацией: команда уже подготовила два достаточно проработанных решения, но не понимает, какое из них передавать в разработку. Причем иногда различия кажутся небольшими — например, по-разному организована форма, изменена последовательность экранов или иначе расположено основное действие. На практике именно такие изменения могут влиять на то, замечает ли пользователь нужную функцию, правильно ли понимает следующий шаг и может ли выполнить задачу без дополнительных объяснений.
Проверить это выгоднее на прототипе, чем после релиза. Пока продукт существует в Figma или другом инструменте прототипирования, спорное решение относительно легко изменить. После разработки то же изменение затрагивает дизайн, код, тестирование, документацию и сроки команды. Поэтому сравнительное тестирование прототипов я рассматриваю не столько как способ найти «самый красивый» вариант, сколько как возможность снизить неопределенность до того, как компания вложит ресурсы в реализацию.
В этой статье разберем, как организовать такое сравнение системно: определить гипотезу, выбрать критерии оценки, подобрать респондентов, подготовить сценарий исследования и проанализировать результаты. Отдельно поговорим о ситуации, когда различия между вариантами есть, но данных недостаточно, чтобы уверенно объявить один из них победителем.
Материал будет особенно полезен продуктовым менеджерам, UX-исследователям, дизайнерам, маркетологам и командам, которые готовят новый сервис, функцию, личный кабинет, форму или другой цифровой интерфейс. Для сбора количественной и качественной обратной связи на этапе проверки гипотез можно использовать Тестограф: например, распределить респондентов между вариантами прототипа и после выполнения задания задать одинаковый набор вопросов.
Главная идея сравнительного тестирования проста: решение о разработке желательно принимать не потому, что вариант B получил больше голосов на внутренней встрече, а потому, что заранее выбранные показатели дают основания считать его более подходящим для пользователей и задачи продукта.
При этом исследование не всегда заканчивается победой A или B. Иногда наиболее полезный результат выглядит иначе: вариант A лучше решает одну часть пользовательской задачи, вариант B — другую, а открытые ответы показывают проблему, которая присутствует в обоих. Тогда ценность тестирования заключается в возможности увидеть третий путь еще до разработки.
Дальше разберем, что именно имеет смысл сравнивать в двух прототипах и как отделить проверяемое различие от десятка изменений, смешанных в одном эксперименте.
Сравнивать два прототипа имеет смысл только тогда, когда команда понимает, какое различие она проверяет. Если вариант A и вариант B одновременно отличаются структурой, текстами, визуальным стилем, количеством шагов, набором полей и расположением кнопок, результат исследования будет трудно интерпретировать. Даже если один вариант покажет лучшие результаты, останется непонятно, что именно повлияло на поведение пользователей.
Поэтому перед тестированием я обычно предлагаю сформулировать различие между прототипами одной короткой фразой. Например: «Мы проверяем, какая структура формы помогает пользователю быстрее завершить регистрацию» или «Хотим понять, какой вариант навигации делает нужный раздел заметнее». Такая формулировка сразу задает границы исследования.
Чаще всего команды сравнивают несколько типов решений:
структуру страницы или экрана, расположение блоков, порядок шагов, навигацию, тексты интерфейса, состав полей, расположение основного действия, сценарий регистрации, оформления заказа или оплаты.
Здесь важно не путать сравнение интерфейсов с оценкой общего впечатления. Вопрос «Какой вариант вам нравится больше?» может быть полезным, но сам по себе почти ничего не говорит о том, какой прототип лучше решает задачу пользователя. Человек может предпочесть визуально более аккуратный вариант и при этом совершать в нем больше ошибок.
В практических исследованиях я советую разделять три уровня сравнения.
Например, если участники быстрее проходят вариант A, но субъективно чаще выбирают вариант B, это не означает, что исследование «дало противоречивый результат». Наоборот, это повод разобраться, почему рационально более эффективный сценарий воспринимается хуже, или почему приятный интерфейс не помогает выполнить задачу.
Отдельная ошибка — сравнивать прототипы, которые находятся на разном уровне готовности. Если в одном варианте тексты уже отредактированы, состояния продуманы и навигация работает последовательно, а второй остается черновым, исследование будет измерять не только саму гипотезу, но и степень проработки решений.
Поэтому перед запуском я рекомендую привести оба варианта к сопоставимому уровню детализации. Это не означает, что прототипы должны быть полностью идентичными по оформлению. Но респондент не должен получать дополнительные подсказки только потому, что один из вариантов сделан аккуратнее.
Есть и еще один важный момент: не все различия стоит проверять отдельным исследованием. Если речь идет о незначительном визуальном изменении, которое почти не влияет на сценарий, полноценное сравнительное тестирование может оказаться избыточным. Но если решение затрагивает путь пользователя, понимание продукта, количество шагов или вероятность ошибки, проверка до разработки обычно оправдана.
Хорошо поставленное сравнение начинается не с вопроса «A или B?», а с вопроса «Какое конкретное пользовательское поведение должно измениться между A и B?». Именно этот ответ затем становится основой гипотезы и критериев выбора победителя.
После того как различие между прототипами определено, нужно договориться, по какому признаку команда будет выбирать лучший вариант. Сделать это желательно до получения результатов. Иначе появляется соблазн посмотреть на данные и выбрать именно тот показатель, по которому предпочтительный для команды прототип оказался сильнее.
Рабочая гипотеза должна связывать изменение интерфейса с ожидаемым поведением пользователя. Например: «Если сократить регистрацию с трех экранов до одного, пользователи будут чаще успешно завершать задачу». Или: «Если вынести выбор способа доставки на отдельный шаг, пользователи будут реже ошибаться при оформлении заказа».
Формулировка «вариант B удобнее варианта A» слишком расплывчата. Что значит «удобнее»? Пользователь быстрее справляется с задачей, делает меньше ошибок, выше оценивает понятность или просто предпочитает внешний вид? Все эти показатели могут дать разные результаты.
Поэтому для исследования полезно заранее выбрать основную метрику. В зависимости от задачи это может быть:
При этом я не рекомендую превращать исследование в соревнование десятков показателей. Чем больше равноправных метрик мы используем, тем проще получить ситуацию, в которой A выигрывает по трем показателям, B — по другим трем, а команда снова возвращается к обсуждению мнений.
Гораздо практичнее определить один основной критерий, непосредственно связанный с гипотезой, и несколько дополнительных показателей, которые помогают объяснить результат.
Представим, что мы сравниваем две версии формы заявки. В варианте A все поля находятся на одном экране, в B форма разделена на несколько последовательных шагов. Основным критерием можно сделать успешное завершение сценария. Дополнительно измерить субъективную простоту, количество затруднений и понять из открытых ответов, что именно вызывало проблемы.
Тогда решение принимается не по принципу «у B средняя оценка 4,3, а у A — 4,1», а в контексте исходной задачи. Если главная цель — увеличить вероятность завершения формы, именно этот показатель должен иметь больший вес.
Не всегда нужна победа с большим отрывом
Еще до исследования стоит определить, какая разница между прототипами вообще будет иметь практическое значение.
Допустим, один вариант оказывается немного лучше другого. Формально разница существует, но достаточно ли ее, чтобы переделывать решение или выбирать более дорогой в разработке сценарий? Ответ зависит от продукта.
Если вариант B требует значительно больше времени разработчиков, улучшение второстепенной оценки на несколько процентов может не оправдать дополнительных затрат. Но такое же небольшое изменение в критическом сценарии — например, при оформлении заказа — потенциально может иметь гораздо большее значение.
Поэтому при анализе я разделяю два вопроса: есть ли различие в данных и достаточно ли оно важно для продуктового решения. Это не одно и то же.
Статистические методы помогают оценить, насколько наблюдаемая разница может быть связана со случайными колебаниями выборки. Продуктовая значимость отвечает на другой вопрос: имеет ли обнаруженный эффект достаточную ценность для бизнеса и пользователей, чтобы на его основании менять решение.
Зафиксируйте правила до просмотра результатов
Полезная практика — еще перед запуском исследования записать, что команда будет считать убедительным результатом. Не обязательно составлять сложный исследовательский документ. Иногда достаточно нескольких предложений: какую гипотезу проверяем, какая метрика основная, какие показатели вспомогательные и при каких результатах будем выбирать A или B.
Такой подход особенно полезен, если у участников проекта уже есть фаворит. Исследование тогда сложнее превратить в инструмент подтверждения заранее принятого решения.
При работе с опросом эти показатели можно заложить непосредственно в структуру анкеты: одинаковые вопросы, шкалы и задания используются для обоих вариантов, а ответы затем сравниваются между группами. В Тестографе такой подход позволяет собрать результаты в единой логике исследования и затем анализировать различия между группами респондентов.
Но прежде чем составлять вопросы, необходимо решить еще одну методологическую задачу: показывать каждому человеку только один прототип или дать ему последовательно протестировать оба. От этого зависит и структура исследования, и то, насколько надежно мы сможем интерпретировать полученную разницу.
Когда гипотеза и основная метрика определены, возникает следующий вопрос: как именно показать участникам варианты A и B. На практике выбор дизайна исследования заметно влияет на результат. Одно дело — когда человек видит только один прототип и оценивает его независимо. Другое — когда он последовательно работает с обоими и неизбежно начинает их сравнивать.
Я обычно рассматриваю три базовых схемы:
Первый подход ближе к независимому тестированию. Респондент не знает, что существует альтернативный интерфейс, поэтому воспринимает показанный вариант как самостоятельный продукт. Это полезно, когда важно измерить успешность выполнения задачи, понятность или субъективную оценку без прямого влияния второго прототипа.
Но у такого дизайна есть требование: группы должны быть сопоставимыми. Если вариант A тестируют в основном опытные пользователи продукта, а B — новички, различия в результатах могут объясняться не интерфейсом. Поэтому распределение участников между вариантами лучше проводить случайно, а характеристики групп контролировать.
Второй подход позволяет получить оценку обоих вариантов от одного человека. Его преимущество в том, что индивидуальные особенности респондентов меньше влияют на сравнение: один и тот же пользователь проходит A и B. Однако появляется эффект порядка.
Допустим, человек сначала выполняет задачу в A. Во время прохождения он уже понимает логику продукта, узнает терминологию и запоминает, где искать нужную функцию. Когда ему показывают B, часть задачи становится проще не благодаря интерфейсу, а благодаря опыту, полученному несколькими минутами ранее.
Поэтому нельзя всем участникам показывать варианты в одинаковой последовательности. Часть респондентов должна получить A → B, а другая часть — B → A. Такая ротация не устраняет эффект обучения полностью, но позволяет уменьшить его систематическое влияние на один из вариантов.
Когда достаточно изображений, а когда нужен интерактивный прототип
Метод показа зависит от того, что именно мы проверяем. Для оценки текста, визуальной иерархии или понятности отдельного экрана иногда достаточно изображения. Респондент может изучить два решения и ответить на одинаковые вопросы.
Если же гипотеза связана с поведением — например, сможет ли пользователь найти нужный раздел, пройти регистрацию или оформить заявку, — статичного изображения обычно недостаточно. Нужен кликабельный прототип, в котором можно выполнить хотя бы основной сценарий.
Важно, чтобы способ взаимодействия не подсказывал правильный путь. Если исследователь заранее объясняет, какую кнопку нажать и где находится нужная функция, мы фактически перестаем проверять интерфейс.
Я предпочитаю давать задание через цель пользователя. Не «Нажмите кнопку “Добавить участника”, затем откройте настройки», а, например: «Представьте, что вам нужно предоставить доступ к проекту новому сотруднику. Покажите, как бы вы это сделали».
Так мы наблюдаем не выполнение инструкции, а способность интерфейса направить человека к нужному действию.
Как выбрать схему для своего исследования
Если команде важно понять, насколько каждый вариант работает сам по себе, я чаще рекомендую разделение аудитории на две группы. Если выборка ограничена и необходимо получить подробное сравнительное мнение, можно показать оба прототипа одному человеку, обязательно контролируя порядок.
Иногда полезно объединить подходы. Сначала участник выполняет задачу без знания альтернативы и оценивает увиденный интерфейс, а позже знакомится со вторым вариантом и отвечает на сравнительные вопросы. Главное — не смешивать первоначальную оценку и последующее предпочтение при анализе.
И еще один принцип: дизайн исследования нужно выбирать не по тому, какой вариант проще технически запустить, а по тому, какие данные необходимы для решения продуктовой задачи.
После выбора схемы остается определить, кого приглашать в исследование и сколько участников действительно потребуется. Именно здесь часто возникает следующая проблема: прототип тестируют на удобной аудитории — коллегах, знакомых или первых доступных респондентах, — хотя будущие пользователи продукта могут вести себя совсем иначе.
Даже хорошо спроектированное сравнение A и B мало что даст, если прототипы тестируют не на тех людях. Один из самых доступных способов быстро получить обратную связь — отправить ссылку коллегам. Для проверки технической работоспособности исследования это нормально. Для выбора продуктового решения такая выборка часто оказывается слабой.
Коллеги знают продукт, его терминологию и внутреннюю логику. Они могут понимать назначение функции еще до того, как увидят интерфейс. Реальному пользователю приходится разбираться во всем этом самостоятельно.
Поэтому я начинаю подбор участников не с вопроса «Где найти респондентов?», а с вопроса «Кто столкнется с этим сценарием после запуска?»
Если мы проверяем оформление первого заказа, нужны люди, сопоставимые с потенциальными покупателями. Если исследуем новый раздел корпоративного сервиса, важны должность, рабочие задачи и опыт использования подобных инструментов. Для продукта с разными типами пользователей может потребоваться несколько сегментов.
Критерии отбора удобно зафиксировать заранее:
возраст или другие действительно значимые характеристики аудитории, опыт использования продукта или его аналогов, роль и профессиональный контекст для B2B-сервисов, частота выполнения исследуемой задачи, а также критерии, по которым человек не должен участвовать в тесте.
Последний пункт тоже важен. Например, если мы проверяем интерфейс для новых пользователей, постоянные клиенты могут оказаться неподходящими респондентами: они уже знают структуру продукта и способны пройти сценарий по памяти.
Скрининг до показа прототипа
Для отбора можно использовать несколько скрининговых вопросов в начале исследования. Их задача — не собрать максимум информации о человеке, а определить, соответствует ли он необходимому профилю.
При этом скрининг не должен раскрывать правильный ответ. Вопрос «Вы регулярно пользуетесь сервисами для управления проектами?» слишком явно показывает, кого ищет исследователь. Если участие предполагает вознаграждение, это может дополнительно мотивировать человека выбрать подходящий вариант.
Лучше спрашивать о поведении через нейтральный набор вариантов или уточнять конкретный опыт за определенный период. В онлайн-опросе неподходящих участников можно завершать по отдельному сценарию, не показывая им основной блок исследования.
Сколько респондентов нужно
Универсального числа здесь нет. Размер выборки зависит прежде всего от того, что команда собирается доказать с помощью исследования.
Если задача — найти основные проблемы сценария, исследование может быть преимущественно качественным. Несколько внимательно проведенных тестов способны быстро показать, где пользователи останавливаются, неправильно интерпретируют элементы или выбирают неожиданный путь. Но на основании такой небольшой выборки не стоит утверждать, что «вариант B на 12% лучше A».
Для количественного сравнения требования другие. Если мы хотим сопоставить долю успешно выполнивших задачу, средние оценки или другие показатели и сделать вывод о различии между вариантами, выборку нужно планировать исходя из ожидаемого эффекта, разброса показателя и требуемой надежности результата.
Здесь возникает важный компромисс. Чем меньшую разницу между A и B команда хочет надежно обнаружить, тем больше участников обычно потребуется. Если нас интересует только очень заметное преимущество одного решения, требования к выборке могут быть ниже.
Поэтому я не советую начинать с формулировки «Давайте возьмем 100 человек». Сначала нужно определить, какое изменение будет достаточно значимым для продуктового решения, а уже затем оценивать необходимое количество наблюдений.
Не забывайте о сегментах
Еще одна распространенная ситуация возникает после сбора данных. Команда набрала, например, общую выборку и только затем решила сравнить новичков и опытных пользователей, мобильную и десктопную аудиторию или несколько профессиональных ролей.
После такого дробления в каждом сегменте может остаться слишком мало наблюдений для уверенных выводов.
Если различия между группами принципиально важны, сегментацию стоит заложить еще на этапе планирования. В Тестографе можно включить в анкету вопросы для отбора и последующей сегментации респондентов, чтобы анализировать результаты A и B не только в целом, но и в нужных группах.
При этом сегментация должна иметь содержательный смысл. Если начать делить небольшую выборку по десяткам признаков и искать, где обнаружилась самая заметная разница, легко принять случайное колебание за продуктовый инсайт.
В итоге качество выборки определяется не только количеством участников. Пятьдесят представителей нужной аудитории могут дать более полезные данные, чем несколько сотен случайных людей, особенно когда прототип рассчитан на конкретный сценарий или профессиональную роль.
Когда аудитория определена, можно переходить непосредственно к тому, что увидит респондент: заданию, последовательности действий и вопросам после взаимодействия с прототипом. От их формулировок во многом зависит, будем ли мы измерять реальный пользовательский опыт или ответы, которые сами подсказали участникам исследования.
Сценарий тестирования должен создавать для респондента понятную ситуацию, но не объяснять, как выполнить задачу. Это тонкая граница: если дать слишком мало контекста, человек не поймет, зачем взаимодействовать с прототипом. Если дать слишком подробную инструкцию, мы сами проложим ему маршрут и затем ошибочно решим, что интерфейс оказался понятным.
Представим, что мы сравниваем два прототипа сервиса, в котором нужно пригласить коллегу в проект. Неудачное задание будет звучать так: «Откройте раздел “Команда”, нажмите “Добавить участника” и укажите его email». Здесь уже названы раздел, элемент интерфейса и последовательность действий.
Лучше сформулировать ситуацию через цель: «Вы создали рабочий проект и хотите предоставить к нему доступ коллеге. Покажите, как бы вы это сделали».
Теперь участнику приходится самостоятельно интерпретировать интерфейс. Если он долго ищет нужную функцию, открывает другой раздел или не понимает название кнопки, мы получаем полезные данные о прототипе.
Одинаковые условия для A и B
При сравнительном исследовании особенно важно сохранить одинаковые условия. Участники двух групп должны получать одно и то же задание, сопоставимый контекст и одинаковые вопросы после прохождения сценария. Иначе вместе с интерфейсом изменится сам эксперимент.
Я обычно разделяю вопросы на несколько типов:
Порядок здесь имеет значение. Сначала лучше зафиксировать результат взаимодействия, а уже затем спрашивать мнение. Если перед заданием попросить человека внимательно оценивать удобство навигации, он начнет изучать ее гораздо тщательнее, чем сделал бы при обычном использовании продукта.
Не спрашивайте только о том, что понравилось
В исследованиях прототипов легко увлечься оценочными шкалами: «Насколько вам понравился интерфейс?», «Насколько современным он выглядит?», «Как вы оцениваете удобство?». Такие вопросы дают аккуратные числа, которые удобно сравнивать, но не всегда помогают принять решение.
Мне полезнее знать, смог ли человек выполнить задачу и что помешало ему это сделать.
После прохождения сценария можно спросить: «Насколько легко или сложно было выполнить задачу?» Затем уточнить причину оценки. Открытый ответ помогает увидеть то, что исследователь не предусмотрел при составлении анкеты.
Например, вариант B может получить более низкую оценку не из-за структуры, которую мы проверяем, а из-за непонятного названия одной кнопки. Это принципиально разные выводы. В первом случае может потребоваться пересмотреть весь сценарий, во втором — достаточно изменить микрокопирайтинг.
Избегайте вопросов, которые защищают гипотезу
Особенно внимательно я отношусь к формулировкам вроде «Насколько новая упрощенная форма оказалась удобнее?» Слова «новая» и «упрощенная» уже создают рамку, в которой участнику предлагается подтвердить улучшение.
Нейтральнее спросить: «Какой вариант было проще использовать для выполнения задачи?» — если человек видел оба прототипа. После этого важно попросить объяснить выбор.
То же касается вопросов о конкретной функции. Если спросить «Заметили ли вы кнопку продолжения?», человек может ответить утвердительно уже после того, как вопрос обратил его внимание на кнопку. Если задача исследования — проверить заметность элемента, лучше сначала наблюдать, нашел ли его пользователь самостоятельно.
Открытые ответы нужны, но в разумном количестве
Полностью закрытая анкета позволяет быстро получить показатели, но часто оставляет исследователя без объяснения причин. Полностью открытая, наоборот, создает большой объем разнородного текста, который сложно сопоставлять между A и B.
Поэтому я предпочитаю сочетать подходы. Основные критерии фиксируются одинаковыми закрытыми вопросами, а открытые используются там, где особенно важно понять мотив или источник проблемы.
Такую логику можно собрать в онлайн-опросе: показать респонденту нужный вариант прототипа, провести его через одинаковую последовательность вопросов и сохранить ответы для последующего сравнения групп. При подготовке исследования в Тестографе стоит заранее продумать ветвление анкеты, чтобы участники A и B проходили сопоставимые сценарии и различия в структуре опроса не влияли на результат.
В итоге хороший сценарий не пытается доказать, что один из прототипов лучше. Он создает условия, в которых оба варианта получают одинаковую возможность показать свои сильные и слабые стороны.
После завершения сбора данных начинается самая ответственная часть исследования: нужно сопоставить результаты и определить, действительно ли различия между A и B достаточно убедительны, чтобы на их основании принимать решение о разработке.
После завершения тестирования легко перейти сразу к средним значениям и попытаться определить победителя. Вариант A получил оценку 4,2, вариант B — 4,5; в A задачу завершили 76% участников, в B — 82%. На первый взгляд вывод очевиден: B лучше. Но именно на этом этапе я советую не торопиться.
Начинать анализ стоит с основной метрики, которую мы определили до запуска исследования. Если гипотеза касалась успешного выполнения задачи, именно этот показатель должен быть первым. Оценки удобства, предпочтения и открытые ответы помогают объяснить результат, но не должны незаметно становиться главным критерием только потому, что показывают более заметную разницу.
При анализе я последовательно смотрю на несколько уровней данных:
Предположим, в варианте A задачу успешно выполнили 78% участников, а в B — 84%. Само наличие шести процентных пунктов разницы еще не означает, что B гарантированно лучше. На небольшой выборке подобное отличие может возникнуть из-за случайных колебаний состава участников.
Здесь полезны статистические методы: они помогают оценить неопределенность результата и понять, насколько полученные данные совместимы с реальным различием между вариантами. Конкретный метод зависит от типа показателя и дизайна исследования. Например, сравнение долей успешного выполнения и сопоставление оценок по шкале требуют разных расчетов.
Но статистическая значимость — не единственный критерий.
Статистическая и продуктовая значимость — разные вещи
На большой выборке статистически заметной может стать очень небольшая разница. Представим, что B повышает успешность выполнения задачи с 90 до 91%. При достаточном количестве наблюдений такое различие может оказаться статистически убедительным, но команде все равно придется решить, оправдывает ли один процентный пункт дополнительные расходы на реализацию.
Возможна и обратная ситуация. На ограниченной выборке вариант показывает достаточно крупное улучшение, которое важно для бизнеса, но данных пока недостаточно для уверенного статистического вывода. Это не повод автоматически считать варианты одинаковыми. Правильнее признать неопределенность и, если решение действительно важно, собрать дополнительные данные.
Поэтому результат я предпочитаю формулировать не как «B победил», а конкретнее: что изменилось, насколько изменилось и насколько уверенно мы можем связать это изменение с вариантом прототипа.
Среднее значение может скрывать важные различия
Предположим, средняя оценка удобства у A и B практически одинаковая. Если остановиться на этом показателе, можно решить, что прототипы равноценны.
Но после сегментации выясняется, что новые пользователи значительно лучше справляются с A, а опытные почти не замечают разницы. Для продукта, который активно привлекает новую аудиторию, это уже важный результат.
При этом сегменты желательно определять до анализа, а не искать их бесконечно после получения данных. Если разбивать выборку десятками способов, рано или поздно где-нибудь появится эффект просто случайно.
Открытые ответы объясняют числа
Количественный показатель отвечает на вопрос «что произошло», но часто не отвечает на вопрос «почему».
Допустим, в B пользователи чаще успешно выполняют задачу, но ниже оценивают удобство. Открытые комментарии могут показать, что сценарий стал понятнее, однако участникам не нравится необходимость проходить дополнительный экран. Тогда перед командой появляется более содержательный выбор: сохранить понятную структуру B, но попробовать сократить ощущение лишнего шага.
При анализе открытых ответов я группирую повторяющиеся проблемы и мотивы, а не выбираю несколько наиболее ярких цитат. Один эмоциональный комментарий легко запоминается, но он не обязательно отражает типичный опыт аудитории.
Особенно интересны случаи, когда поведение и самооценка расходятся. Пользователь может сказать, что оба варианта одинаково простые, хотя в одном из них он выполнил задачу сразу, а в другом несколько раз выбрал неверное действие. Для продуктового решения такое наблюдаемое поведение часто информативнее общего впечатления.
Что делать, если явного победителя нет
Это нормальный результат исследования. Если A и B показывают близкие результаты, не нужно искусственно выбирать победителя по минимальной разнице в одном из второстепенных показателей.
Отсутствие убедительного преимущества тоже является данными. В таком случае можно учитывать стоимость и скорость разработки, соответствие дизайн-системе, технические ограничения или возможность дальнейшего масштабирования решения.
Иногда результаты подсказывают и третий вариант. Например, пользователи быстрее проходят сценарий A, но лучше понимают тексты и структуру B. Вместо выбора одного прототипа целиком команда может объединить сильные элементы обоих и проверить новую версию.
Именно поэтому анализ сравнительного тестирования — это не поиск большего числа в отчете. Его задача — снизить неопределенность настолько, чтобы команда могла обоснованно принять следующее продуктовое решение.
Однако даже аккуратные расчеты не исправят ошибки, допущенные при организации исследования. Поэтому далее разберем ситуации, из-за которых сравнение двух прототипов может дать убедительные на вид, но ненадежные выводы.
Большинство проблем сравнительного тестирования возникает не на этапе расчетов, а раньше — при подготовке исследования. Результаты при этом могут выглядеть вполне убедительно: есть проценты, средние оценки, диаграммы и комментарии участников. Но если условия для A и B различались, выборка была смещена или критерий победы появился уже после просмотра данных, уверенность в выводах оказывается выше, чем качество самого исследования.
Одна из самых частых ошибок — слишком маленькая выборка для количественных выводов. Например, из десяти человек семь предпочли A, а трое — B. Записать результат 70% против 30% технически можно, но сам процент создает иллюзию точности. При таком количестве участников изменение ответов всего нескольких человек полностью меняет картину.
Небольшая выборка вполне подходит для поиска проблем интерфейса и изучения причин поведения. Но ее возможности не нужно распространять на задачи, для которых она не предназначена.
Не менее опасны различия между группами. Если A тестировали преимущественно постоянные пользователи, а B — люди, впервые столкнувшиеся с продуктом, сравнение становится сомнительным. То же происходит, если участники выполняют задания на разных устройствах, получают разные инструкции или одна группа имеет дополнительный контекст.
Еще несколько ошибок особенно заметно влияют на результат:
Предпочтение пользователя не равно эффективности интерфейса
Вопрос о выборе между A и B выглядит самым естественным. Если большинство выбрало B, почему просто не отправить его в разработку?
Потому что предпочтение измеряет именно предпочтение.
Пользователю может больше нравиться вариант с крупными иллюстрациями, дополнительной информацией или необычной навигацией. При этом задачу он быстрее и точнее выполняет в другом прототипе. Это не делает вопрос о предпочтении бесполезным — просто его нельзя автоматически превращать в главный показатель качества интерфейса.
Особенно осторожно я отношусь к прямому голосованию, если участник сначала несколько минут подробно сравнивал макеты. В реальном продукте пользователь обычно не выбирает между двумя интерфейсами. Он получает один и пытается решить свою задачу.
Не меняйте критерий победы после получения данных
Допустим, до исследования команда решила сравнивать успешность выполнения сценария. После теста разницы почти нет, зато B получил более высокую субъективную оценку. Возникает соблазн объявить его победителем уже по удобству.
Иногда дополнительный показатель действительно важен. Проблема появляется, когда правило выбора меняется только потому, что первоначальная гипотеза не получила ожидаемой поддержки.
Гораздо полезнее зафиксировать результат таким, какой он есть: по основной метрике убедительного преимущества не обнаружено, но дополнительный показатель указывает на потенциальное различие, которое стоит учитывать или проверить отдельно.
Не пытайтесь доказать решение, которое уже принято
Это, пожалуй, самая сложная методологическая ошибка, потому что она связана не с инструментом исследования, а с ожиданиями команды.
Если один прототип уже нравится ключевым участникам проекта, исследование легко начать воспринимать как способ получить подтверждение. Тогда незаметно появляются более выгодная формулировка задания, удобная интерпретация спорного результата или повышенное внимание к показателям, где фаворит оказался сильнее.
В своей работе я стараюсь отделять исследовательский вопрос от желаемого ответа. Хорошее тестирование должно допускать три результата: лучше A, лучше B или имеющихся данных недостаточно для выбора.
Последний вариант не означает, что исследование провалилось. Иногда именно отсутствие заметной пользовательской разницы позволяет команде спокойно выбрать технически более простой или дешевый вариант.
Перед запуском полезно провести короткую проверку исследования: одинаковы ли условия для групп, соответствует ли выборка аудитории, нейтрально ли сформулировано задание, определена ли основная метрика и понятно ли заранее, как команда будет интерпретировать разные результаты.
Если эти условия соблюдены, данные становятся не аргументом в споре о дизайне, а инструментом принятия решения. Остается последний шаг — перевести результаты теста в конкретное действие: выбрать A или B, доработать один из вариантов либо собрать третью версию из наиболее удачных решений обоих прототипов.
Сравнение прототипов имеет смысл только в том случае, если результаты заканчиваются продуктовым решением. Исследование не должно превращаться в отчет, который команда посмотрела на встрече, обсудила и отложила. До начала разработки нужно ответить на более практичный вопрос: что именно мы делаем с полученными данными?
Я обычно свожу результаты к одному из четырех решений:
Самый простой сценарий — один вариант показывает устойчивое преимущество по заранее выбранной основной метрике, а дополнительные данные не выявляют критических проблем. Например, пользователи чаще завершают задачу в B, совершают меньше ошибок и в открытых ответах не сообщают о новых существенных затруднениях. Если разница имеет продуктовую ценность, у команды появляются разумные основания выбрать B.
Но на практике результат часто оказывается сложнее.
Предположим, A позволяет быстрее выполнить задачу, а в B пользователи реже ошибаются. Здесь нельзя просто посчитать количество «побед» каждого прототипа. Нужно вернуться к исходной гипотезе и контексту продукта. Для операции, где ошибка может привести к потере данных или неверной оплате, снижение числа ошибок может быть важнее нескольких секунд экономии. Для часто повторяющегося рутинного действия скорость, напротив, способна иметь больший вес.
Если A и B почти не отличаются
Отсутствие заметной разницы — тоже полезный результат. До тестирования команда могла несколько дней спорить о двух решениях, предполагая, что выбор существенно повлияет на пользователей. Исследование может показать, что аудитория одинаково успешно справляется с обоими.
В этом случае в решение можно включить факторы, которые не относятся непосредственно к UX: стоимость реализации, сроки, техническую сложность, соответствие существующей дизайн-системе, удобство поддержки и возможность масштабировать решение в будущем.
Так тестирование помогает не только выбрать лучший интерфейс, но и понять, когда разница между интерфейсами недостаточно существенна, чтобы тратить на нее дополнительные ресурсы.
Иногда лучший результат — вариант C
Сравнительный тест не обязан заканчиваться выбором одного готового прототипа целиком.
Допустим, в A пользователи быстро находят начало нужного сценария, но затем путаются в последовательности шагов. В B первый экран оказывается менее понятным, зато дальнейший процесс проходит практически без ошибок. В такой ситуации логичным следующим шагом может стать новый прототип: точку входа взять из A, а структуру дальнейшего сценария — из B.
Это особенно ценный результат раннего исследования. Если бы команда сразу разработала один вариант, подобные выводы пришлось бы получать уже на работающем продукте, где стоимость изменений выше.
Новый вариант C при существенных изменениях желательно проверить повторно. Нельзя автоматически предполагать, что соединение двух удачных решений сохранит преимущества каждого: элементы интерфейса взаимодействуют друг с другом, и новая комбинация может создать новый пользовательский сценарий.
Когда нужно провести еще один тест
Дополнительное исследование оправдано, если цена ошибочного решения высока, а полученных данных недостаточно. Например, выборка оказалась меньше запланированной, результаты A и B слишком близки или разные показатели дают противоречивую картину.
Но повторное тестирование не должно становиться способом собирать данные до тех пор, пока команда наконец не получит желаемого победителя. Перед новым запуском нужно определить, какая именно неопределенность осталась и какие дополнительные данные позволят ее уменьшить.
Для повторной проверки можно создать отдельный опрос в Тестографе, сохранив одинаковую методику для сравниваемых вариантов. Это особенно важно, если после первого этапа появился доработанный прототип: изменение вопросов или условий тестирования одновременно с изменением интерфейса усложнит сопоставление результатов.
Короткий алгоритм перед передачей прототипа в разработку
Вся методика, описанная в статье, сводится к последовательной логике. Сначала команда определяет конкретное различие между A и B и формулирует гипотезу. Затем выбирает основную метрику, проектирует одинаковые условия тестирования, привлекает подходящую аудиторию и только после этого собирает данные.
При анализе важно смотреть не только на то, у какого варианта показатель выше, но и на величину различия, неопределенность результата и его практическую ценность. Открытые ответы и наблюдения помогают понять причины, но не должны использоваться для произвольного переопределения исходных критериев.
И наконец, результат исследования нужно перевести в действие: разрабатывать A, разрабатывать B, доработать решение или признать, что для уверенного выбора пока недостаточно данных.
Сравнение двух прототипов до разработки не устраняет продуктовый риск полностью. Оно делает другое — позволяет заменить часть предположений наблюдениями и данными в тот момент, когда изменить решение еще относительно легко.
Именно поэтому я предпочитаю проверять спорные сценарии до того, как они превратятся в задачи для разработчиков. Чем раньше команда понимает, как реальные пользователи воспринимают два решения, тем меньше ей приходится платить за предположения после релиза.