Тестирование прототипа позволяет проверить продуктовые решения до того, как команда вложит время и бюджет в полноценную разработку. На этом этапе еще относительно легко изменить структуру экрана, перестроить навигацию, переименовать непонятный элемент или полностью пересмотреть пользовательский сценарий. После разработки те же изменения обычно обходятся дороже: затрагивают дизайн, код, аналитику, документацию и повторное тестирование.
Но само по себе присутствие пользователей на тесте еще не делает исследование полезным. На практике я нередко вижу результаты, которые сводятся к нескольким комментариям участников: «в целом понятно», «выглядит удобно», «я бы этим пользовался». Такие ответы могут дополнить исследование, но опираться только на них при выборе продуктового решения рискованно.
Причина в том, что впечатление пользователя и его фактическое поведение не всегда совпадают. Человек может сказать, что интерфейс понятен, но потратить несколько минут на поиск нужной функции. Может высоко оценить экран, хотя выполнил задание только со второй попытки. Или, наоборот, критически отнестись к дизайну, но быстро и без ошибок пройти весь сценарий.
Поэтому при тестировании прототипов я рекомендую разделять как минимум два слоя данных: что пользователь делает и как он оценивает свой опыт.
Первый слой составляют поведенческие показатели. Мы можем фиксировать, удалось ли участнику выполнить задачу, сколько времени ему потребовалось, где он совершал ошибки, сколько действий сделал, возвращался ли на предыдущие экраны и насколько его путь отличался от ожидаемого.
Второй слой — данные, которые мы получаем непосредственно от пользователя. После задания можно попросить оценить его сложность, понятность интерфейса, уверенность в результате или объяснить, что именно вызвало затруднение. Для такой части исследования удобно использовать онлайн-опросы Тестографа: количественные вопросы можно сочетать с открытыми и затем анализировать их вместе с результатами прохождения сценария.
Наиболее интересные выводы обычно появляются именно на пересечении этих двух типов данных. Например, участник успешно выполняет задачу, но ставит низкую оценку простоты. Это сигнал, что сценарий функционально работает, однако требует слишком больших усилий. В другой ситуации пользователь может оценить интерфейс высоко, хотя совершает несколько ошибок. Тогда стоит проверить, действительно ли он замечает проблему и насколько она способна повлиять на реальное использование продукта.
В работе с исследованиями я стараюсь не рассматривать отдельную метрику как окончательный ответ. Время выполнения без контекста мало что говорит о качестве интерфейса. Высокая субъективная оценка тоже не гарантирует отсутствия UX-проблем. Даже успешность выполнения задания становится значительно полезнее, если одновременно посмотреть на ошибки, путь пользователя и его собственную оценку сложности.
Именно поэтому тестирование прототипа лучше строить не как сбор впечатлений, а как небольшое измеримое исследование. В следующих разделах разберем, какие метрики для этого подходят, что именно они показывают и как сочетать их так, чтобы результаты теста помогали принимать конкретные решения по интерфейсу.
Перед запуском тестирования полезно ответить не на вопрос «какие метрики мы можем собрать?», а на другой: что именно мы хотим узнать о прототипе? От этого зависит и сценарий исследования, и задания для участников, и набор показателей.
Например, команда хочет проверить новую форму оформления заявки. В одном случае нас интересует, понимают ли пользователи последовательность шагов. В другом — могут ли они самостоятельно найти нужные поля. В третьем — какой из двух вариантов формы позволяет быстрее выполнить задачу. Внешне исследования похожи, но измерять в них нужно разные вещи.
В работе над методологией таких исследований я обычно разделяю метрики прототипа на три группы: результативные, поведенческие и субъективные.
Результативные метрики отвечают на самый простой вопрос: справился ли человек с поставленной задачей. Пользователь нашел нужный раздел, оформил условный заказ, изменил настройки, отправил заявку — или не смог закончить сценарий. Иногда результата «выполнил / не выполнил» недостаточно, поэтому отдельно выделяют частичное выполнение.
Поведенческие метрики показывают, как именно человек пришел к результату. Здесь можно анализировать время выполнения задания, количество действий, ошибки, возвраты, неверные переходы и отклонения от предполагаемого маршрута. Именно эти показатели часто обнаруживают проблемы, которые остаются незаметными при оценке только конечного результата.
Представим, что четыре из пяти участников успешно находят функцию изменения тарифа. На первый взгляд прототип работает хорошо. Но при просмотре поведения оказывается, что трое сначала открывают два других раздела и только после этого находят нужный. Формально задача выполнена, однако структура навигации явно требует дополнительной проверки.
Субъективные метрики описывают восприятие опыта самим участником. Насколько простой показалась задача? Был ли человек уверен, что нажимает правильную кнопку? Насколько понятными оказались названия разделов? Ожидал ли пользователь увидеть результат именно там, где он появился?
Такие показатели удобно собирать непосредственно после выполнения каждого задания. Например, в Тестографе можно подготовить отдельный блок вопросов для участников исследования и использовать шкалы вместе с открытыми вопросами. Это позволяет получить не только оценку, но и комментарий, объясняющий ее.
Метрики зависят от степени готовности прототипа
Не каждый показатель можно одинаково хорошо использовать на любой стадии проектирования.
Если перед нами ранний статичный макет, бессмысленно пытаться точно измерять время прохождения полноценного пользовательского сценария: взаимодействие еще слишком далеко от будущего продукта. Зато уже можно исследовать понятность терминологии, ожидаемое назначение элементов, информационную архитектуру и то, где пользователь предполагает найти определенную функцию.
С кликабельным прототипом возможностей становится больше. Можно давать участникам конкретные задания, фиксировать успешность, наблюдать за последовательностью действий, находить ошибочные переходы и сравнивать несколько вариантов одного сценария.
При этом высокая детализация прототипа не означает, что нужно собирать максимум доступных данных. Избыточное количество показателей способно даже усложнить анализ: исследователь получает десятки цифр, но не понимает, какая из них должна повлиять на решение команды.
От исследовательского вопроса к метрике
Полезная метрика всегда связана с гипотезой.
Допустим, мы предполагаем, что новая структура каталога позволит пользователю быстрее находить нужный раздел. Тогда можно измерять успешность выполнения задания, время и количество ошибочных переходов.
Если гипотеза звучит иначе — «новое название функции будет понятнее пользователям» — время уже может оказаться второстепенным показателем. Нам важнее проверить, какой элемент человек выбирает первым, что ожидает увидеть после нажатия и насколько уверенно объясняет назначение функции.
Поэтому я стараюсь заранее выстраивать цепочку:
Такой подход защищает исследование от распространенной ошибки, когда сначала собирают все доступные данные, а уже после теста пытаются найти в них подтверждение нужной гипотезы.
Опрос и наблюдение должны дополнять друг друга
Еще один важный принцип — не превращать исследование прототипа исключительно в анкетирование. Если задача теста заключается в проверке интерфейса, участнику сначала лучше дать возможность самостоятельно выполнить действие, а уже затем задавать вопросы.
Например, вместо вопроса «Легко ли вам было бы найти настройки уведомлений?» мы предлагаем найти их в прототипе. После выполнения задания спрашиваем, насколько простым или сложным оказался поиск и что вызвало затруднение.
Разница принципиальная. В первом случае человек прогнозирует собственное поведение. Во втором — оценивает уже полученный опыт.
В результате у исследователя появляется гораздо более содержательная картина. Мы видим не только мнение участника, но и результат его действий. А если эти данные противоречат друг другу, само противоречие становится материалом для анализа.
Дальше рассмотрим одну из базовых групп показателей тестирования прототипов — успешность выполнения задач и пользовательские ошибки.
Одна из базовых метрик при тестировании прототипа — Task Success Rate, или доля успешно выполненных заданий. Она показывает, какая часть участников смогла достичь цели, заложенной в сценарии исследования.
Если мы тестируем интернет-магазин, заданием может быть поиск определенного товара и переход к оформлению заказа. Для банковского приложения — поиск истории операций или настройка лимита. Для корпоративного сервиса — создание нового проекта и приглашение сотрудника. В каждом случае заранее определяется конкретная точка, достижение которой считается успешным выполнением.
В простом варианте показатель можно рассчитать так:
Например, если 8 из 10 участников самостоятельно завершили сценарий, успешность составляет 80%. Однако сама цифра еще не объясняет, насколько хорошо спроектирован интерфейс.
Что считать успешным выполнением
Критерий успеха важно определить до проведения теста. Иначе возникает риск подстраивать трактовку результатов под фактическое поведение участников.
Для одного исследования достаточно бинарного результата: пользователь либо выполнил задачу, либо нет. Для другого полезнее выделить три состояния: успешное выполнение, частичное выполнение и неуспех.
Частичным можно считать сценарий, в котором человек дошел до нужного раздела, но не смог завершить последнее действие. Например, нашел настройки уведомлений, но неправильно понял переключатели. Такое поведение нельзя приравнивать ни к полностью успешному, ни к полностью проваленному заданию.
Отдельно стоит определить, считается ли результат успешным, если участнику потребовалась подсказка модератора. В большинстве исследований я рекомендую фиксировать выполнение с помощью отдельно. Иначе прототип получает результат, который пользователь в реальной ситуации, возможно, не смог бы получить самостоятельно.
Правильный результат не всегда означает хороший интерфейс
Представим, что участнику нужно изменить адрес доставки. Он открывает профиль, затем настройки аккаунта, возвращается назад, переходит в историю заказов, снова возвращается и только после этого обнаруживает адреса в разделе доставки.
Задача выполнена. В расчете Task Success Rate это будет успех.
Но с точки зрения пользовательского опыта здесь есть очевидный сигнал: человек не понимал структуру интерфейса и несколько раз проверял неверные гипотезы.
Поэтому процент успешного выполнения лучше анализировать вместе с маршрутом пользователя. Полезно различать прямой успех, когда задача решена ожидаемым способом без существенных затруднений, и непрямой успех, когда пользователь достиг цели после ошибок, возвратов или долгого поиска.
Так мы избегаем ситуации, когда высокий Task Success Rate создает ложное ощущение, что прототип не требует изменений.
Ошибки как отдельный источник данных
При тестировании я рекомендую фиксировать не только сам факт ошибки, но и ее характер. Особенно важны повторяющиеся ошибки у разных участников.
Например, если один человек случайно нажал не ту кнопку, это еще не обязательно проблема дизайна. Если пять участников независимо выбирают один и тот же неправильный элемент, стоит проверить название, расположение или визуальную иерархию элементов.
Особое внимание имеет смысл уделять критическим ошибкам — действиям, после которых пользователь не может самостоятельно завершить сценарий либо приходит к неправильному результату, считая его правильным.
Некритическая ошибка создает дополнительное усилие, но не блокирует достижение цели. Пользователь открывает неподходящий раздел, понимает это, возвращается и продолжает работу.
Такое разделение помогает приоритизировать изменения. Не каждая обнаруженная проблема требует одинакового внимания команды.
Сопоставляем успех с уверенностью пользователя
Есть еще один полезный ракурс: после выполнения задания спросить участника, насколько он уверен, что сделал все правильно.
Получаются четыре показательных ситуации. Пользователь может успешно выполнить задачу и быть уверенным в результате — наиболее благоприятный вариант. Может выполнить ее правильно, но сомневаться. Может ошибиться и понимать, что задача не решена. Наконец, наиболее интересный случай — выполнить задачу неправильно, но быть уверенным в успехе.
Последняя ситуация особенно важна. Интерфейс не просто затрудняет действие, а создает ложное ощущение правильного результата. В реальном продукте подобные проблемы способны приводить к повторным обращениям, неправильным настройкам и другим нежелательным последствиям.
Для измерения уверенности достаточно короткого вопроса после задания, например оценки по шкале. Такой вопрос можно включить в анкету исследования в Тестографе, а затем сопоставить ответы участников с фактическими результатами выполнения сценария.
Task Success Rate в таком подходе становится не итоговой оценкой качества прототипа, а отправной точкой анализа. Мы выясняем, достиг ли пользователь цели, каким путем он к ней пришел, какие ошибки совершил и понимал ли сам, насколько успешно справился.
Следующий шаг — посмотреть, сколько усилий потребовало это достижение. Для этого пригодятся время выполнения задания, количество действий и другие показатели эффективности прохождения сценария.
Если Task Success Rate отвечает на вопрос, достиг ли пользователь цели, то метрики эффективности показывают, сколько усилий ему для этого потребовалось. Два участника могут одинаково успешно выполнить задание, но первый сделает это за четыре действия, а второй — после долгого поиска, нескольких возвратов и попыток открыть неподходящие разделы.
Поэтому при анализе прототипов я не рассматриваю успешность отдельно от самого процесса взаимодействия.
Time on Task: сколько времени заняло задание
Time on Task — время от начала выполнения задания до достижения заданной цели или прекращения попытки. Это одна из самых понятных количественных метрик, но одновременно одна из тех, которые легко интерпретировать неправильно.
Предположим, в одном варианте прототипа участники выполняют определенное действие в среднем за 40 секунд, а в другом — за 55. Нельзя автоматически заключить, что первый вариант лучше. Разница может возникнуть из-за сложности задания, знакомства участников с похожими интерфейсами, особенностей самого прототипа или нескольких очень долгих попыток.
Особенно осторожно стоит относиться к среднему времени на небольших выборках. Один участник, который остановился и несколько минут рассуждал вслух, способен заметно изменить среднее значение. Поэтому полезно смотреть не только на итоговую цифру, но и на результаты отдельных участников и контекст их действий.
Время становится значительно информативнее при сравнении сопоставимых сценариев: например, двух вариантов одной формы или старой и новой навигации.
Количество действий
Еще один показатель — сколько действий потребовалось пользователю для достижения цели. В кликабельном прототипе это могут быть переходы между экранами, клики, возвраты и другие доступные взаимодействия.
Допустим, предполагаемый сценарий состоит из пяти шагов. Участник выполняет задачу за девять. Формально результат положительный, но четыре дополнительных действия требуют объяснения.
Само превышение ожидаемого количества шагов не всегда означает проблему. Иногда пользователь выбирает альтернативный маршрут, который оказывается вполне логичным. Поэтому задача исследователя — не просто посчитать клики, а понять, почему возникли дополнительные действия.
Отклонение от предполагаемого пути
При проектировании сценария команда обычно представляет определенную последовательность действий. Ее можно использовать как ориентир, но не как единственно правильный маршрут.
Если пользователи регулярно идут другим путем и успешно достигают результата, возможны как минимум две интерпретации. Первая — интерфейс недостаточно явно направляет их по предусмотренному сценарию. Вторая — сами пользователи обнаружили более естественный маршрут, который команда не предусмотрела.
Второй вариант особенно интересен. Тестирование прототипа позволяет не только искать ошибки пользователей, но и проверять наши собственные представления об их поведении.
Поэтому я рекомендую фиксировать повторяющиеся альтернативные маршруты. Если несколько участников независимо выбирают одну и ту же последовательность действий, это уже не случайность, а материал для пересмотра информационной архитектуры или пользовательского потока.
Первое действие как отдельный сигнал
В некоторых исследованиях полезно отдельно смотреть, куда пользователь нажимает первым.
Представим экран личного кабинета с несколькими разделами. Задача — найти возможность скачать закрывающие документы. Если большинство участников сразу выбирают «Документы», направление кажется очевидным. Если первые клики распределяются между «Профилем», «Оплатой», «Историей операций» и другими разделами, вероятно, структура или названия не дают достаточно ясного ориентира.
Первое действие особенно полезно при проверке навигации, информационной архитектуры и терминологии. Оно показывает первоначальную гипотезу пользователя до того, как он начинает методом исключения исследовать интерфейс.
Почему быстрее — не обязательно лучше
Оптимизировать интерфейс исключительно под минимальное время опасно. Для некоторых действий дополнительный шаг повышает понятность или помогает предотвратить ошибку.
Например, подтверждение перед необратимым действием делает сценарий длиннее. Но удаление такого шага ради сокращения времени может ухудшить опыт и повысить цену пользовательской ошибки.
Поэтому вместо вопроса «Как сделать сценарий максимально быстрым?» я предпочитаю формулировку: «Какие действия пользователя действительно необходимы для понятного и предсказуемого достижения цели?»
Тогда время и количество действий становятся диагностическими метриками, а не самоцелью.
Сравнение вариантов прототипа
Метрики эффективности особенно полезны, когда команда тестирует несколько решений одной задачи. Например, в варианте A функция находится в основном меню, а в варианте B — внутри тематического раздела.
Можно сравнить успешность выполнения, время, количество лишних переходов и долю правильных первых действий. Если один вариант показывает преимущество сразу по нескольким показателям, аргументация становится значительно сильнее, чем вывод «участникам этот вариант понравился больше».
Но и здесь важно учитывать размер и состав выборки. При небольшом числе участников разницу в несколько секунд или один дополнительный клик не стоит автоматически превращать в доказательство превосходства одного дизайна.
В итоге метрики эффективности помогают увидеть то, что скрывается за успешным завершением задания. Пользователь мог достичь цели быстро и напрямую, а мог потратить заметные усилия на поиск правильного пути. Именно это различие часто указывает, где интерфейс действительно помогает человеку, а где заставляет его адаптироваться к логике продукта.
Поведенческие показатели показывают, что произошло во время теста, но не всегда объясняют, как сам пользователь воспринимал взаимодействие. Человек может быстро выполнить задание и при этом сомневаться практически на каждом шаге. Или потратить больше времени, чем ожидалось, но считать сценарий совершенно понятным.
Поэтому после выполнения заданий я обычно рекомендую добавлять несколько коротких оценочных вопросов. Они помогают измерить субъективную сторону пользовательского опыта и сопоставить ее с фактическим поведением.
Оценка сложности задания
Один из самых полезных вопросов — насколько легко или сложно было выполнить конкретную задачу. Его лучше задавать сразу после завершения сценария, пока участник хорошо помнит собственные действия и затруднения.
Например, после поиска нужной функции можно предложить оценить простоту выполнения задания по шкале. Главное — использовать одинаковую формулировку и шкалу для всех участников и всех сопоставляемых сценариев.
Такая оценка становится особенно полезной при сравнении. Если одно задание получает заметно более низкие оценки, чем остальные, стоит посмотреть, что происходило на соответствующих экранах. Если тестируются два варианта прототипа, можно сравнить воспринимаемую сложность одного и того же действия.
При этом низкая оценка не говорит, почему возникла проблема. Пользователь мог не понимать термин, не заметить кнопку, неправильно интерпретировать структуру меню или ожидать совершенно другой сценарий. Поэтому количественную оценку иногда стоит дополнить одним открытым вопросом.
Уверенность в результате
Не менее интересный показатель — уверенность пользователя в том, что он выполнил задачу правильно.
На практике это позволяет обнаружить проблемы, которые сложно увидеть только через успешность и время. Представим, что человек прошел сценарий быстро и без ошибок, но после завершения оценивает свою уверенность на 2 балла из 5. Возможно, интерфейс не дает достаточно заметной обратной связи: пользователь совершил правильное действие, но не получил понятного подтверждения результата.
Еще важнее обратная ситуация: участник совершает ошибку, но уверен, что все сделал правильно. Такой результат может указывать на серьезную UX-проблему, поскольку интерфейс формирует ложное представление об успешном завершении действия.
Понятность интерфейса и терминов
Отдельно можно измерять понятность конкретных элементов. Это полезно, когда исследование посвящено новой навигации, необычной функции или терминологии.
Однако вопросы вида «Вам понятна эта кнопка?» дают ограниченную информацию. Пользователь может ответить утвердительно, хотя вкладывает в название совсем не тот смысл, который предполагает команда.
Поэтому для важных элементов я предпочитаю проверять понимание через ожидание. Например: «Что, по вашему мнению, произойдет после нажатия этой кнопки?» или «Какую информацию вы ожидаете увидеть в этом разделе?»
Здесь мы получаем уже не абстрактную оценку понятности, а пользовательскую интерпретацию элемента. Ее можно сравнить с реальным назначением функции.
Ожидание до действия и оценка после него
Интересный прием — разделить измерение на два момента.
До взаимодействия мы выясняем, чего человек ожидает от элемента. После — соответствует ли полученный результат его ожиданиям.
Допустим, участник видит кнопку «Архивировать». Перед нажатием он объясняет, что, по его мнению, произойдет. Затем выполняет действие и оценивает, совпал ли результат с ожиданием. Если интерпретации разных участников систематически расходятся с заложенной логикой, проблема может находиться не в самом сценарии, а в терминологии или визуальном представлении функции.
Такой подход особенно полезен на ранних этапах, когда изменить название или логику элемента значительно проще, чем после разработки.
Не превращайте тест прототипа в длинную анкету
Здесь важно соблюдать баланс. После каждого действия можно задать десяток вопросов, но это быстро утомит участника и изменит само взаимодействие с прототипом.
Если после каждого экрана просить оценить понятность, привлекательность, удобство, скорость, доверие, удовлетворенность и еще несколько параметров, человек начинает анализировать интерфейс как эксперт, а не пользоваться им как обычный пользователь.
Поэтому я предпочитаю выбирать только те вопросы, ответы на которые действительно понадобятся при принятии решения.
Для одного задания это может быть оценка сложности. Для другого — уверенность в результате. Для третьего — открытый вопрос о причине затруднения. В Тестографе можно объединить разные типы вопросов в одном исследовательском сценарии, но методологически важнее не количество собранных показателей, а их связь с проверяемыми гипотезами.
Самое полезное — расхождение между словами и действиями
При анализе я в первую очередь обращаю внимание не только на высокие или низкие оценки, но и на случаи, когда субъективные и поведенческие данные противоречат друг другу.
Пользователь говорит, что задача простая, но делает много лишних переходов. Быстро достигает цели, но не уверен в результате. Ставит высокую оценку интерфейсу, хотя неправильно понимает назначение важной функции.
Такие расхождения часто дают больше информации, чем сама средняя оценка.
Именно поэтому субъективные метрики лучше использовать не вместо наблюдения за поведением, а вместе с ним. В следующей части рассмотрим стандартизированные показатели — SUS, SEQ и UMUX-Lite — и разберемся, когда они действительно полезны при тестировании прототипов.
Когда нужно не просто собрать впечатления участников, а получить показатель, который можно последовательно использовать в нескольких исследованиях, пригодятся стандартизированные UX-метрики. Их преимущество в том, что команда не придумывает каждый раз собственную шкалу «удобства», а применяет одинаковый инструмент и получает сопоставимые результаты.
При тестировании прототипов чаще всего полезны SUS, SEQ и UMUX-Lite. Но они измеряют разные аспекты опыта, поэтому выбирать методику стоит исходя из исследовательской задачи.
SUS: общая оценка воспринимаемого удобства
System Usability Scale (SUS) используют для общей оценки воспринимаемого юзабилити системы. Методика включает десять утверждений, которые участник оценивает после взаимодействия с продуктом или прототипом. После пересчета ответов получается итоговый показатель от 0 до 100.
Важно не интерпретировать его как обычный процент. Например, результат 80 не означает, что интерфейс «удобен на 80%». Это индекс, который имеет смысл рассматривать относительно результатов других исследований, предыдущих версий продукта или принятых ориентиров.
SUS особенно полезен, когда прототип достаточно проработан и участник успел выполнить несколько связанных задач. Если показать человеку один экран и сразу предложить оценить всю систему по десяти пунктам, часть утверждений окажется оторвана от реального опыта.
На практике я бы использовал SUS, например, при сравнении двух достаточно полных вариантов пользовательского сценария или при последовательных итерациях одного продукта. Тогда можно наблюдать не только отдельные проблемы, но и изменение общей воспринимаемой удобности.
SEQ: оценка конкретного задания
Для прототипов часто практичнее Single Ease Question (SEQ). В отличие от SUS, этот показатель относится не ко всему интерфейсу, а к только что выполненному заданию.
После завершения сценария участника просят оценить, насколько простым или сложным было его выполнение. В классическом варианте используется семибалльная шкала.
Главное преимущество SEQ — привязка к конкретному опыту. Участнику не нужно вспоминать весь тест и формировать общую оценку продукта. Он только что закончил действие и может оценить его сложность.
Допустим, мы тестируем четыре сценария: регистрацию, поиск услуги, изменение персональных данных и настройку уведомлений. Общая оценка прототипа может быть высокой, но SEQ способен показать, что именно настройка уведомлений систематически воспринимается как более сложная.
После этого имеет смысл вернуться к поведенческим данным: времени выполнения, ошибочным переходам, первому действию и комментариям участников. Так количественная оценка превращается в диагностический сигнал.
UMUX-Lite: когда нужна короткая общая оценка
UMUX-Lite подходит для ситуаций, когда нужна компактная оценка воспринимаемого качества взаимодействия, но десять утверждений SUS делают исследование слишком длинным. Методика использует всего два утверждения, связанных с возможностями системы и простотой ее использования.
Для тестирования прототипов краткость может быть существенным преимуществом. Участники уже выполняют задания, отвечают на вопросы после сценариев и иногда дают развернутые комментарии. Добавление еще одного большого блока способно увеличивать усталость респондентов.
Но компактность имеет обратную сторону: UMUX-Lite дает общую оценку и практически ничего не объясняет о причинах проблемы. Если показатель оказался низким, придется обращаться к другим данным исследования, чтобы понять, что именно нужно менять.
Как выбрать между SUS, SEQ и UMUX-Lite
Я бы не рассматривал эти методики как конкурирующие. Они отвечают на разные исследовательские вопросы.
Если необходимо оценить конкретное действие, чаще подойдет SEQ. Если нужна более развернутая общая оценка воспринимаемого юзабилити после работы с прототипом — можно использовать SUS. Если требуется компактный общий показатель и важно сократить нагрузку на участника — стоит рассмотреть UMUX-Lite.
В некоторых исследованиях методы можно сочетать. Например, после каждого ключевого задания собирать SEQ, а в конце теста — общую оценку прототипа. Но добавлять несколько стандартизированных шкал просто ради большего количества данных я не рекомендую.
Почему NPS не заменяет метрики юзабилити
Отдельно стоит сказать о Net Promoter Score (NPS). Иногда его пытаются использовать как универсальную оценку интерфейса: участника спрашивают о готовности рекомендовать продукт и по результату делают вывод о качестве прототипа.
Для диагностики юзабилити это слабый инструмент.
Готовность рекомендовать продукт зависит не только от интерфейса. На нее могут влиять ценность самого предложения, цена, отношение к бренду, наличие альтернатив и множество других факторов. На раннем прототипе часть этих факторов вообще невозможно адекватно оценить.
Поэтому низкий NPS не объяснит, где находится UX-проблема, а высокий не докажет, что пользовательский сценарий спроектирован хорошо.
Если задача исследования — понять, способен ли пользователь самостоятельно оформить заявку, найти функцию или изменить настройку, гораздо полезнее измерить успешность, ошибки, время и воспринимаемую сложность соответствующего действия.
Стандартизированная метрика не отменяет анализа контекста
Самая распространенная ошибка здесь — получить одно число и превратить его в окончательный вердикт о прототипе.
Предположим, SEQ показывает, что определенное задание воспринимается как сложное. Это еще не решение. Нужно посмотреть, где участники задерживались, какие действия совершали, что выбирали первым и как объясняли свои затруднения.
Стандартизированная метрика помогает обнаружить и сравнить проблему, но редко объясняет ее самостоятельно.
Поэтому в исследованиях прототипов я рассматриваю SUS, SEQ и UMUX-Lite как дополнительный слой данных. Они особенно полезны при сравнении версий и повторных исследованиях, когда одна и та же методика применяется последовательно. А чтобы понять причины полученного результата, количественные показатели стоит дополнять наблюдениями и качественными вопросами.
Количественные показатели хорошо отвечают на вопросы «сколько?», «как часто?» и «насколько?», но значительно хуже объясняют причины поведения. Мы можем увидеть, что участники долго выполняют задание или низко оценивают его простоту, однако из одной цифры не узнаем, что именно им помешало.
Поэтому при тестировании прототипов я дополняю метрики качественными данными. Это не означает, что после каждого действия нужно проводить большое интервью. Иногда одного правильно сформулированного открытого вопроса достаточно, чтобы понять причину неожиданного результата.
Открытый вопрос после задания
Один из наиболее практичных вариантов — сначала дать участнику выполнить сценарий, затем получить количественную оценку и только после этого попросить коротко объяснить ее.
Например, пользователь завершил оформление заявки и оценил простоту процесса на 3 балла из 7. После этого можно спросить: «Что больше всего затруднило выполнение задачи?»
Ответ дает контекст числовому показателю. Один участник может указать на непонятное название поля, другой — на расположение кнопки продолжения, третий — на отсутствие подтверждения после действия.
Если похожая причина появляется в ответах нескольких людей и одновременно отражается в поведенческих метриках, оснований для пересмотра решения становится больше.
Не подсказывать проблему формулировкой вопроса
При подготовке анкеты важно избегать наводящих формулировок. Вопрос «Было ли вам сложно найти кнопку продолжения?» уже сообщает участнику, что исследователь предполагает наличие проблемы именно с этой кнопкой.
Лучше использовать нейтральный вариант: «Что, если что-либо, вызвало затруднение при выполнении задания?» или попросить участника описать момент, в котором ему пришлось задуматься.
По этой же причине не стоит заранее перечислять предполагаемые недостатки интерфейса. Если дать варианты «непонятное название», «незаметная кнопка», «слишком много полей», мы частично ограничиваем пространство ответов собственными гипотезами.
Особенно важны противоречия
При анализе результатов я отдельно смотрю на ситуации, когда слова участника расходятся с его действиями.
Например, человек оценивает простоту задания на 7 из 7, но во время прохождения несколько раз возвращается назад. Это не означает, что участник «неправильно» оценил интерфейс. Возможно, возвраты для него естественны и не воспринимаются как затруднение.
Другой участник проходит сценарий практически идеально, но ставит низкую оценку. В комментарии выясняется, что он постоянно сомневался, правильно ли понимает названия элементов. Поведенчески сценарий работает, но субъективно требует заметного когнитивного усилия.
Именно такие расхождения помогают избежать слишком прямолинейной интерпретации цифр.
Как анализировать открытые ответы
Качественные комментарии не стоит просто переносить в отчет длинным списком цитат. Гораздо полезнее сгруппировать их по повторяющимся причинам.
Например, после тестирования формы могут появиться несколько устойчивых тем: непонятные названия полей, отсутствие ожидаемой подсказки, сомнения перед отправкой и недостаточно заметное подтверждение успешного действия.
Затем эти темы можно сопоставить с количественными показателями. Если участники, упоминающие проблему с терминологией, одновременно чаще ошибаются или дольше выполняют задание, мы получаем более убедительную связь между особенностью интерфейса и наблюдаемым поведением.
При этом важно не превращать единичный комментарий в статистический вывод. Фраза одного участника может подсказать полезную гипотезу, но сама по себе еще не показывает распространенность проблемы.
Опрос как часть тестирования прототипа
В Тестографе можно собрать в одном исследовании шкальные оценки, вопросы с вариантами ответа и открытые комментарии. Для тестирования прототипа такой опрос удобно использовать как сопровождающий инструмент: участник выполняет задание, после чего отвечает на несколько вопросов о полученном опыте.
Здесь особенно важно соблюдать последовательность. Сначала действие — затем оценка. Если подробно расспросить человека о возможных проблемах до выполнения сценария, мы рискуем привлечь его внимание к элементам, которые он иначе мог бы вообще не заметить.
В результате качественные данные становятся не альтернативой метрикам, а способом их интерпретации. Числа показывают, где стоит искать проблему, наблюдение помогает увидеть, как она проявляется, а ответы участников дают материал для понимания, почему она могла возникнуть.
Именно сочетание этих источников позволяет перейти от констатации «пользователям было сложно» к гораздо более полезному выводу: какой элемент сценария вызывает затруднение, у кого оно возникает и какое изменение прототипа имеет смысл проверить в следующей итерации.
Главная ошибка при подготовке тестирования прототипа — пытаться измерить все, что технически можно измерить. Успешность, время, клики, ошибки, удовлетворенность, уверенность, SEQ, SUS и несколько открытых вопросов быстро превращают небольшой UX-тест в перегруженное исследование. Данных становится больше, но принимать решения по ним не обязательно проще.
В работе с клиентскими исследованиями я предпочитаю начинать с продуктового вопроса. Команда должна понимать, какое решение она собирается принять после получения результатов. Уже под это решение выбираются гипотезы, задания и метрики.
От гипотезы к критерию решения
Удобная логика построения исследования выглядит так:
Допустим, команда изменила структуру личного кабинета и предполагает, что пользователям станет проще находить платежные документы. Просить участников просто оценить новый дизайн недостаточно.
Лучше поставить конкретную задачу: «Найдите счет за прошлый месяц и скачайте его». После этого можно зафиксировать успешность выполнения, первый выбранный раздел, количество ошибочных переходов и время.
Если участники быстро находят документ, редко ошибаются и высоко оценивают простоту задания, данные согласуются между собой. Если успешность высокая, но большинство сначала открывает неподходящий раздел, появляется основание дополнительно проверить структуру навигации.
То есть метрика выбирается не потому, что ее принято использовать в UX-исследованиях, а потому, что она помогает проверить конкретное предположение.
Разным прототипам нужны разные показатели
Для проверки навигации я в первую очередь смотрел бы на успешность, первое действие, ошибочные переходы и субъективную оценку сложности.
При тестировании формы полезнее могут оказаться доля завершивших сценарий, ошибки при заполнении, возвраты к предыдущим полям и места, где участники прекращают выполнение.
Для нового сложного сценария стоит анализировать не только достижение конечной цели, но и прохождение отдельных этапов. Это помогает определить конкретную точку, после которой пользователи начинают испытывать трудности.
При сравнении двух вариантов одного решения особенно полезны одинаковые показатели, рассчитанные по единой методике. Иначе сравнение теряет смысл: нельзя в одном варианте считать выполнение с подсказкой успехом, а в другом — ошибкой.
Не каждое действие требует отдельного вопроса
Количество вопросов после задания тоже стоит ограничивать исследовательской целью.
Если нас интересует понятность сценария, может быть достаточно SEQ и одного открытого вопроса для участников с низкой оценкой. Если проверяем риск неправильного действия, полезнее спросить об уверенности в результате. Если исследуется терминология, лучше попросить объяснить значение элемента своими словами.
В Тестографе можно использовать логику показа вопросов, чтобы участники видели только релевантные им продолжения анкеты. Например, дополнительный вопрос о причине затруднения можно показывать тем, кто поставил низкую оценку. Это помогает не увеличивать анкету одинаково для всех участников.
Сегментация результатов
Общий показатель иногда скрывает различия между группами пользователей.
Представим, что новый сценарий успешно выполняют 80% участников. Сам по себе результат выглядит достаточно однородным. Но после сегментации выясняется, что среди опытных пользователей успешность почти максимальная, тогда как люди, впервые сталкивающиеся с продуктом, регулярно ошибаются.
Среднее значение в такой ситуации описывает выборку, но плохо описывает реальную UX-проблему.
Поэтому еще до тестирования стоит определить, какие характеристики участников действительно могут влиять на результат. Это может быть опыт использования продукта, роль в компании, частота выполнения соответствующей задачи или знакомство с определенным типом сервисов.
При этом сегментировать небольшую выборку по множеству признаков не стоит. Если после каждого разделения в группе остается два-три человека, проценты начинают создавать иллюзию точности, которой исследование фактически не имеет.
Сколько заданий включать в исследование
Универсального числа нет. Я ориентируюсь прежде всего на сложность сценариев и нагрузку на участника.
Лучше подробно проверить несколько действительно важных задач, чем поверхностно пройти десяток пользовательских потоков. Чем длиннее исследование, тем выше вероятность усталости: участник начинает быстрее читать инструкции, менее внимательно отвечать на вопросы и иначе взаимодействовать с интерфейсом.
Кроме того, последовательность заданий может обучать человека. Если в первом сценарии он случайно обнаружил определенный раздел, во втором поиск связанной функции уже не будет происходить с нуля. Это необходимо учитывать при интерпретации времени и количества ошибок.
Анализировать метрики нужно в связке
После исследования я стараюсь собрать результаты вокруг каждого задания, а не вокруг отдельных показателей.
Допустим, успешность составляет 90%. Это выглядит хорошо. Но затем мы видим, что половина участников сначала выбирает неправильный раздел, время выполнения сильно различается, а оценка простоты заметно ниже, чем у остальных сценариев.
Вывод уже будет другим: пользователи в итоге достигают цели, но интерфейс недостаточно хорошо направляет их к ней.
И наоборот, немного большее время выполнения само по себе не обязательно требует редизайна, если участники действуют без ошибок, уверены в результате и считают сценарий понятным.
Именно поэтому хороший план тестирования прототипа — это не длинный перечень метрик. Это заранее выстроенная система, в которой понятно, какую гипотезу проверяет каждое задание, какой показатель даст необходимый сигнал и что команда будет делать с полученным результатом.
Тестирование прототипа становится полезным для продуктовой команды не тогда, когда исследователь собрал как можно больше показателей, а когда полученные данные позволяют ответить на конкретный вопрос: что в интерфейсе работает, где возникает проблема и какое решение стоит проверить следующим.
Поэтому я не рекомендую искать одну универсальную метрику качества прототипа. Task Success Rate показывает, достигают ли пользователи цели, но не рассказывает, насколько сложным был путь. Время выполнения помогает оценить эффективность, однако само по себе не объясняет причины задержки. Количество ошибок показывает проблемные места сценария, но требует анализа контекста. SUS, SEQ, UMUX-Lite и собственные шкальные вопросы позволяют измерить восприятие интерфейса, однако субъективная оценка не заменяет наблюдение за реальным поведением.
Наиболее полезная картина появляется, когда эти данные рассматриваются вместе.
Например, низкая успешность и большое количество одинаковых ошибок у разных участников — серьезный повод пересмотреть сценарий. Высокая успешность при большом числе лишних переходов может указывать на проблему навигации. Быстрое выполнение при низкой уверенности в результате — сигнал проверить обратную связь интерфейса. А высокая субъективная оценка при фактических ошибках заставляет внимательнее посмотреть, понимают ли пользователи последствия своих действий.
При этом далеко не каждое обнаруженное затруднение требует немедленного редизайна. В исследованиях важно учитывать частоту проблемы, ее влияние на достижение цели и последствия ошибки. Если затруднение встречается у нескольких участников и мешает выполнить критически важный сценарий, его приоритет будет выше, чем у единичного дополнительного клика, который практически не влияет на результат.
Поэтому еще до запуска тестирования полезно определить критерии, по которым команда будет принимать решения. Какие результаты заставят пересмотреть прототип? Какое поведение считается критической ошибкой? Что будет достаточным основанием для сравнения двух вариантов? Какие результаты потребуют дополнительного исследования?
Так метрики перестают быть цифрами для отчета и становятся частью продуктового процесса.
Из практики анализа исследований я бы сформулировал основной принцип так: каждая собираемая метрика должна иметь понятное назначение. Если мы не можем объяснить, какое решение изменится в зависимости от ее значения, вероятно, этот показатель не нужен в текущем тесте.
Для одного исследования достаточно успешности, ошибок и короткой оценки сложности. Для другого понадобятся время, анализ пользовательского маршрута и стандартизированная шкала. В третьем исследовании наиболее ценными окажутся открытые ответы и расхождения между тем, что участники говорят, и тем, что они фактически делают.
Именно поэтому набор метрик стоит проектировать одновременно со сценарием тестирования. Сначала определяем гипотезу и пользовательскую задачу, затем решаем, какое поведение будет свидетельствовать о проблеме, и только после этого выбираем показатели и вопросы.
Такой подход позволяет использовать прототип не просто для демонстрации будущего продукта, а как исследовательский инструмент. Еще до разработки команда получает возможность проверить свои предположения на пользователях, обнаружить слабые места сценария и аргументированно решить, что оставить, а что изменить в следующей итерации.