Когда команда тестирует интерактивный прототип в Figma, велик соблазн сразу перейти к измеримым результатам: сколько пользователей выполнили задачу, сколько времени им понадобилось, где они ошиблись и какую оценку поставили интерфейсу. Такие показатели действительно нужны, но сами по себе они редко объясняют, что именно происходит с пользовательским опытом и почему.
В работе с исследованиями я часто сталкиваюсь с одной и той же ситуацией: команда получает результаты тестирования и пытается найти в них однозначный ответ — хороший получился интерфейс или плохой. Например, 8 из 10 участников дошли до нужного экрана. На первый взгляд результат выглядит убедительно. Но что произошло с двумя остальными? А восемь успешных участников действительно поняли интерфейс или нашли нужный элемент методом перебора? Совпал ли их путь с тем, который предполагал дизайнер? Были ли они уверены в своих действиях?
Поэтому анализ Figma-прототипа я бы начинал не с процентов, а с исследовательского вопроса. Что именно мы хотели узнать, показывая этот прототип пользователям? Проверить, заметят ли они новую функцию? Понять, смогут ли оформить заказ без подсказки? Сравнить два варианта навигации? Выяснить, соответствует ли название раздела ожиданиям аудитории?
От ответа зависит и то, какие данные будут действительно полезны.
Интерактивный прототип позволяет проверить пользовательскую логику еще до разработки полноценного продукта. Можно увидеть, куда человек пытается нажать, какой путь выбирает, где останавливается, возвращается назад или принимает неожиданное для команды решение. Если дополнить такое тестирование вопросами, появляется еще один слой данных: пользователь может объяснить, чего ожидал от элемента, насколько был уверен в своем выборе и что показалось ему непонятным.
Именно сочетание поведения и обратной связи обычно дает наиболее содержательный материал. Для сбора второй части исследования можно использовать Тестограф: например, предложить участнику выполнить сценарий в прототипе, а затем ответить на несколько вопросов о сложности задачи, понятности отдельных элементов и причинах совершенных действий.
При этом важно учитывать ограничения метода. Figma-прототип — это модель будущего продукта, а не сам продукт. В нем может отсутствовать часть состояний интерфейса, реальные данные, привычная скорость отклика, полноценная мобильная среда и последствия действий пользователя. Поэтому результаты такого тестирования не стоит автоматически переносить на поведение аудитории после релиза.
Особенно осторожно я отношусь к попыткам сделать вывод только на основании одной метрики. Высокий процент выполнения задания еще не доказывает, что сценарий удобен. Долгое выполнение не обязательно означает плохой дизайн. А фраза участника «все понятно» не гарантирует, что он действительно смог бы самостоятельно воспользоваться функцией.
В этой статье разберем анализ результатов тестирования Figma-прототипов именно с этой позиции. Материал будет полезен UX/UI-дизайнерам, UX-исследователям, продакт-менеджерам и продуктовым командам, которым необходимо не просто собрать обратную связь, а превратить результаты исследования в обоснованные решения по интерфейсу.
Я буду смотреть на задачу с позиции специалиста Тестографа, который занимается анализом данных и консультированием клиентов по методологии опросов. Поэтому отдельное внимание уделим связи между тем, что пользователь сделал в прототипе, что он сказал после выполнения задания и какой вывод из этих данных действительно можно сделать.
До начала анализа результатов полезно определить единицу исследования. Формулировка «мы тестируем интерфейс» слишком широкая: один и тот же прототип может быть понятным с точки зрения структуры, но создавать сложности в конкретном сценарии. Пользователь может успешно выполнить задачу, неправильно понимая назначение отдельных элементов. Или, наоборот, хорошо ориентироваться в интерфейсе, но не завершить сценарий из-за одного неочевидного шага.
Поэтому при работе с результатами я разделяю несколько исследовательских задач: успешность прохождения сценария, понятность навигации, соответствие интерфейса ожиданиям пользователя, восприятие информации и субъективную оценку взаимодействия.
Успешность пользовательского сценария
Самый очевидный вопрос — смог ли человек выполнить поставленную задачу. Например, найти определенный тариф, изменить способ доставки, добавить участника в проект или завершить оформление заказа.
Однако здесь важно не ограничиваться результатом «выполнил / не выполнил». Два пользователя могут успешно закончить один сценарий совершенно по-разному. Первый сразу понимает структуру интерфейса и последовательно проходит необходимые шаги. Второй открывает несколько неподходящих разделов, возвращается назад, пробует разные элементы и в итоге случайно находит правильный путь.
Формально оба участника справились. С точки зрения UX это два разных результата.
Поэтому успешность лучше рассматривать вместе с самим маршрутом пользователя: какие действия он совершал, где отклонялся от предполагаемого сценария и насколько уверенно принимал решения.
Понятность навигации и элементов интерфейса
Отдельная задача — проверить, совпадает ли логика интерфейса с ожиданиями аудитории. Пользователь еще не знает, какую структуру придумала продуктовая команда. Он ориентируется на предыдущий опыт, названия разделов, визуальную иерархию и собственное представление о том, где должна находиться нужная функция.
Например, дизайнер размещает настройку уведомлений внутри раздела «Профиль», а большинство участников исследования сначала ищут ее в «Настройках». Это не обязательно означает, что выбранное решение ошибочно. Но повторяющееся поведение становится сигналом: информационная архитектура продукта может расходиться с ментальной моделью пользователей.
На практике такие наблюдения часто оказываются полезнее общего вопроса «Было ли вам удобно?». Человек способен поставить интерфейсу высокую оценку и одновременно несколько раз искать функцию не там, где она находится.
Ожидания от действий
При анализе прототипа важно смотреть не только на то, куда нажал участник, но и на то, чего он ожидал после нажатия.
Допустим, пользователь выбирает кнопку «Продолжить». Для дизайнера следующий экран очевиден, поскольку он знает логику продукта. Участник исследования может ожидать совершенно другого результата: сохранения данных, перехода к оплате или появления дополнительного подтверждения.
Если фактический переход не совпадает с ожиданием, проблема может находиться не в расположении кнопки, а в ее названии, контексте или последовательности экранов.
Именно здесь особенно полезны короткие уточняющие вопросы после выполнения задания. Через онлайн-опрос в Тестографе можно попросить участника оценить понятность конкретного шага или объяснить, какого результата он ожидал. Главное — задавать такие вопросы после действия, а не заранее подсказывать человеку, на что следует обратить внимание.
Восприятие контента
Прототип тестирует не только кнопки и переходы. Текст внутри интерфейса также влияет на результат.
Название функции может быть технически правильным, но непонятным аудитории. Подсказка может содержать всю необходимую информацию, но оставаться незамеченной. Описание тарифа — выглядеть понятным для команды и при этом не помогать пользователю выбрать подходящий вариант.
Поэтому ошибку в сценарии нельзя автоматически считать навигационной. Иногда человек нажал не туда не потому, что нужная кнопка плохо расположена, а потому, что неправильно понял ее название.
При анализе я стараюсь разделять эти причины. Иначе команда рискует переделать визуальную структуру там, где достаточно изменить формулировку.
Субъективный пользовательский опыт
Еще один слой исследования — то, как сам участник оценивает взаимодействие. После выполнения задания можно спросить, насколько сложным оно показалось, насколько человек уверен, что выполнил его правильно, какой этап вызвал наибольшие затруднения.
Такие ответы особенно полезны в сочетании с наблюдаемым поведением.
Представим, что участник прошел сценарий без ошибок за короткое время, но оценил задачу как сложную и сообщил, что сомневался на последнем шаге. Поведенческие данные говорят: сценарий работает. Субъективные данные добавляют важную деталь: пользователю не хватает уверенности.
В другом случае человек может долго искать нужный раздел, совершить несколько неверных действий, а после завершения сказать, что «в целом все было понятно». Если анализировать только его итоговую оценку, проблема останется незамеченной.
Поэтому я не рекомендую пытаться получить из исследования один универсальный показатель «удобства прототипа». Полезнее рассматривать несколько связанных уровней:
Так появляется возможность понять не просто то, справился ли человек, а почему он справился или не справился и какая часть интерфейса повлияла на результат.
И уже после определения этих исследовательских задач можно переходить к метрикам. Иначе команда сначала собирает десятки показателей, а затем пытается придумать, какие продуктовые выводы из них можно получить. В хорошем исследовании последовательность обратная: сначала вопрос и гипотеза, затем подходящие данные и только после этого — их количественный и качественный анализ.
Качество анализа во многом определяется еще до того, как первый участник откроет Figma-прототип. Если команда запускает исследование без заранее сформулированных гипотез и правил фиксации результатов, после тестирования обычно остается много разрозненных наблюдений: комментарии пользователей, время прохождения, заметки исследователя и оценки по шкалам. Информации много, но связать ее с конкретными решениями сложно.
Поэтому я рекомендую заранее определить, какие данные понадобятся для проверки каждой гипотезы.
Допустим, команда предполагает, что пользователи без подсказки найдут функцию экспорта отчета. Тогда недостаточно просто спросить после теста: «Было ли легко найти экспорт?». Нужно зафиксировать, нашел ли участник функцию самостоятельно, куда он перешел сначала, совершал ли ошибочные действия и сколько попыток потребовалось.
Если же гипотеза касается понятности нового названия функции, важнее будет не скорость выполнения, а то, какое действие пользователь ожидает от элемента и как объясняет его назначение своими словами.
Связываем гипотезу с наблюдаемым поведением
Перед исследованием я обычно формулирую гипотезу таким образом, чтобы ее можно было сопоставить с конкретным поведением.
Вместо «новое меню стало удобнее» лучше проверить: «пользователь сможет найти историю заказов без подсказки». Вместо «новый экран оплаты понятен» — «пользователь правильно определит следующий шаг и будет уверен, что заказ еще не оплачен».
Такая конкретизация сразу показывает, что необходимо фиксировать во время теста.
Для каждого задания полезно заранее определить ожидаемый путь, критерий успешного завершения, критические ошибки и дополнительные действия, которые могут указывать на затруднение. При этом ожидаемый путь не нужно воспринимать как единственно правильный. Если участники регулярно находят более короткий или более естественный маршрут, это тоже результат исследования.
Не собирайте данные просто потому, что их можно собрать
В UX-тестировании легко получить десятки показателей. Но количество данных не делает исследование качественнее.
Если команда измеряет время каждого перехода, количество кликов, успешность, субъективную сложность, удовлетворенность, уверенность, намерение использовать продукт и еще несколько общих показателей, часть информации почти наверняка останется без применения.
Я придерживаюсь простого принципа: у каждого собираемого показателя должен быть ответ на вопрос «Как этот результат повлияет на наш вывод?».
Если никакого решения в зависимости от показателя принято не будет, возможно, его не стоит включать в исследование.
Особенно это касается небольших тестов прототипов. Дополнительный вопрос кажется безобидным, но каждый новый пункт увеличивает продолжительность исследования и переключает внимание участника с естественного взаимодействия на постоянную оценку интерфейса.
Когда задавать вопросы участнику
Вопросы лучше привязывать к исследовательскому сценарию, а не размещать все в конце.
После важного задания можно попросить оценить его сложность или уверенность в результате. Если необходимо понять ожидание от конкретного элемента, вопрос имеет смысл задать сразу после соответствующего действия, пока участник помнит ход своих рассуждений.
При этом вопросы не должны раскрывать исследовательскую гипотезу заранее.
Например, если мы хотим проверить заметность нового фильтра, не стоит перед выполнением сценария спрашивать: «Насколько понятным вам кажется фильтр в верхней части страницы?». После такой формулировки участник уже знает, куда смотреть, и его дальнейшее поведение становится менее естественным.
Для сбора ответов после работы с прототипом можно создать анкету в Тестографе. В ней удобно разделить вопросы по заданиям: сначала участник выполняет действие в прототипе, затем оценивает сложность или объясняет принятое решение. Такой подход позволяет впоследствии сопоставлять ответы не с прототипом вообще, а с конкретными этапами сценария.
Подготовьте правила интерпретации заранее
Еще одна полезная практика — до запуска определить, что команда будет считать успешным результатом.
Представим, что проверяется оформление заказа. Участник выбрал товар, дошел до оплаты, но дважды возвращался на предыдущий экран, потому что не понимал, сохранился ли адрес доставки. Считать такое прохождение успешным?
Однозначного ответа нет. Он зависит от цели исследования. Поэтому критерии лучше согласовать заранее, а не после получения результатов.
Можно разделять прохождения на успешные без затруднений, успешные с затруднениями и неуспешные. Отдельно фиксировать критические ошибки — действия, из-за которых пользователь не может закончить сценарий или получает принципиально неправильный результат.
Это уменьшает риск подстроить критерии под уже увиденные данные.
Оставляйте место для неожиданного поведения
Предварительная структура анализа необходима, но она не должна превращать исследование в поиск только тех проблем, которые команда предполагала заранее.
Пользователи могут столкнуться с затруднением там, где дизайнеры вообще не ожидали его увидеть. Например, тест посвящен новой форме регистрации, но несколько участников не могут понять, зарегистрированы ли они после последнего шага. Формально это находится за пределами первоначальной гипотезы, однако повторяющееся наблюдение нельзя игнорировать.
Поэтому я разделяю данные на две части: показатели, необходимые для проверки заранее сформулированных гипотез, и новые наблюдения, появившиеся непосредственно во время исследования.
Такой подход сохраняет структуру анализа, но не заставляет данные соответствовать первоначальным ожиданиям команды.
В результате еще до запуска тестирования у нас должна появиться понятная цепочка: гипотеза → пользовательское задание → наблюдаемое поведение → дополнительные вопросы → критерий интерпретации.
Тогда после завершения исследования не приходится начинать анализ с вопроса «Что интересного есть в этих данных?». Вместо этого мы последовательно проверяем гипотезы и одновременно смотрим, какие неожиданные закономерности обнаружило реальное поведение пользователей.
После того как исследовательские вопросы сформулированы и критерии прохождения определены, можно переходить к количественным показателям. В тестировании Figma-прототипов они помогают увидеть масштаб проблемы и сравнить результаты между заданиями или версиями интерфейса. Но я стараюсь рассматривать метрики как способ описания поведения, а не как самостоятельный вердикт о качестве дизайна.
Одна из основных метрик — Task Success Rate, доля участников, которые успешно выполнили конкретное задание. Если из 12 человек девять дошли до нужного результата в соответствии с заданными критериями, показатель успешности составляет 75%.
Сам процент интерпретировать рано. Нужно посмотреть, что происходило внутри этих 75%. Если почти все успешные участники сначала выбирали неправильный раздел, а затем находили нужную функцию со второй или третьей попытки, перед нами потенциальная UX-проблема, которую итоговый процент скрывает.
По этой причине для прототипов мне нравится разделение результатов как минимум на три состояния: успешное выполнение без заметных затруднений, выполнение с затруднениями и невыполнение задания. Это дает более реалистичную картину, чем бинарное «справился / не справился».
Время выполнения задания
Время кажется очень объективной характеристикой: чем быстрее пользователь справился, тем удобнее интерфейс. На практике такая интерпретация работает далеко не всегда.
Пользователь может быстро выполнить задачу, потому что уже знаком с похожим продуктом. Другой участник внимательно читает каждый экран и поэтому действует медленнее, хотя никаких проблем с интерфейсом у него нет. Наконец, в искусственной ситуации исследования человек часто ведет себя иначе, чем при реальном использовании продукта.
Поэтому время полезнее рассматривать сравнительно. Например, один этап стабильно занимает у участников значительно больше времени, чем соседние. Или после изменения прототипа прохождение конкретного сценария стало заметно короче при сохранении высокой успешности.
Особенно внимательно стоит относиться к единичным экстремальным значениям. Один участник мог отвлечься, долго комментировать интерфейс вслух или неправильно понять инструкцию. Среднее значение из-за этого изменится, хотя сам интерфейс здесь ни при чем.
Ошибки и лишние действия
Количество ошибок часто дает более содержательную информацию, чем общее время прохождения.
К ошибкам можно относить переход в неправильный раздел, выбор элемента, который не ведет к решению задачи, неверное заполнение поля или действие, после которого приходится возвращаться назад. Но еще до анализа важно определить, что именно команда считает ошибкой.
Не каждое дополнительное действие является проблемой. Если пользователь выбирает другой, но логичный маршрут и успешно достигает результата, возможно, перед нами альтернативный сценарий, а не ошибка.
Особенно важны повторяющиеся действия. Когда один человек нажал не туда, это может быть случайностью. Если несколько независимых участников выбирают один и тот же неправильный элемент, стоит проверить, почему именно он кажется им подходящим.
Например, четыре участника из восьми пытаются изменить адрес доставки через «Профиль», хотя функция находится внутри текущего заказа. В таком случае полезно исследовать не только нужную кнопку, но и саму логику размещения функции.
Отказ от выполнения
Отдельно я фиксирую ситуации, когда участник прекращает попытки и сообщает, что не знает, что делать дальше.
Такой результат нельзя объединять с обычной ошибкой. Ошибку пользователь способен заметить и исправить. Отказ чаще говорит о том, что интерфейс не дает достаточных ориентиров для продолжения сценария либо участник совершенно иначе понимает структуру продукта.
Важно записать точку, в которой произошел отказ. Формулировка «не смог оформить заказ» слишком общая. Гораздо полезнее знать, что пользователь выбрал товар и способ доставки, но после перехода к итоговому экрану не понял, какой элемент запускает оплату.
Тогда у команды появляется конкретный участок интерфейса для следующей итерации.
Субъективная сложность и уверенность
Поведенческие метрики желательно дополнить короткой самооценкой участника. После выполнения задания можно попросить его оценить, насколько легко или сложно было достичь результата и насколько он уверен, что выполнил задачу правильно.
Такие вопросы удобно включать в опрос после UX-тестирования в Тестографе. При этом я рекомендую использовать одинаковые шкалы для однотипных заданий. Тогда ответы проще сопоставлять между сценариями.
Особенно интересны расхождения между поведением и самооценкой.
Если человек быстро и без ошибок завершает сценарий, но остается не уверен в результате, возможно, интерфейсу не хватает подтверждения выполненного действия. Если участник совершает несколько ошибок, но считает задание простым, вероятно, эти ошибки не воспринимаются им как существенные препятствия.
Именно такие расхождения часто становятся отправной точкой для более глубокого анализа.
Почему метрики нужно читать вместе
Представим два варианта одного сценария.
В первом прототипе 90% участников выполняют задание, но многие делают несколько лишних переходов и невысоко оценивают уверенность в результате. Во втором успешность составляет 85%, зато большинство справившихся идет по прямому маршруту и хорошо понимает результат своих действий.
Нельзя автоматически объявить первый вариант победителем только из-за более высокого Task Success Rate. Сначала нужно выяснить причины различий и оценить их в контексте исследовательской задачи.
Это особенно важно при небольших выборках, характерных для UX-тестов. Если в исследовании участвуют пять человек, один неуспешный сценарий сразу меняет показатель успешности на 20 процентных пунктов. Запись «80% пользователей справились» выглядит статистически убедительнее, чем фактическая ситуация «справились четыре человека из пяти», хотя речь идет об одних данных.
Поэтому в отчетах по небольшим исследованиям я предпочитаю показывать и абсолютные значения. Они помогают команде не приписывать процентам точность, которой у исследования на самом деле нет.
В итоге базовые метрики должны отвечать не на вопрос «насколько хороший у нас интерфейс», а на более конкретные вопросы: сколько участников достигли результата, каким способом они это сделали, сколько препятствий встретили и насколько уверенно чувствовали себя в процессе.
После этого можно переходить от отдельных показателей к самому интересному уровню анализа — пользовательским маршрутам и повторяющимся ошибкам.
После подсчета базовых метрик я перехожу к пользовательским путям. Именно здесь обычно становится понятно, почему участники получили те или иные результаты. Процент успешного выполнения показывает итог, а последовательность действий позволяет восстановить логику, которая к нему привела.
Для каждого задания полезно иметь ожидаемый маршрут — последовательность действий, которую команда заложила в прототип. Затем этот маршрут сопоставляется с фактическими действиями участников. Задача при этом не в том, чтобы найти любое отклонение от «правильного» пути, а в том, чтобы понять причины и последствия таких отклонений.
Представим, что пользователю нужно изменить способ доставки. Команда предполагает путь «Корзина → Доставка → Способ доставки». Однако часть участников сначала открывает профиль, ищет там адреса и настройки, возвращается в корзину и только после этого находит нужный раздел.
Задание в итоге выполнено, поэтому Task Success Rate не покажет проблему. Пользовательский путь — покажет.
Не каждое отклонение является ошибкой
Одна из распространенных ошибок при анализе — считать правильным только тот маршрут, который предусмотрела команда.
В реальном интерфейсе одна задача иногда может решаться несколькими способами. Если пользователь выбирает альтернативный путь, понимает происходящее и без затруднений получает нужный результат, это не обязательно проблема. Более того, такой маршрут способен подсказать команде более естественную для аудитории структуру продукта.
Поэтому при разборе действий я смотрю не только на соответствие задуманному сценарию, но и на три признака: достиг ли человек цели, понимал ли последствия своих действий и возникали ли у него препятствия.
Если все три условия выполняются, альтернативный маршрут стоит изучить, а не автоматически записывать в ошибки.
Где искать системные проблемы
Гораздо важнее повторяющиеся отклонения. Если несколько участников независимо друг от друга пытаются нажать на один и тот же элемент, ищут функцию в одинаковом разделе или останавливаются на одном экране, появляется основание предположить системную проблему.
Допустим, пять участников видят карточку тарифа и нажимают на ее название, ожидая открыть подробное описание, но интерактивной является только небольшая кнопка «Подробнее». Вопрос здесь уже не в невнимательности конкретного человека. Интерфейс сформировал ожидание, которое не соответствует доступному действию.
Я рекомендую фиксировать подобные случаи максимально конкретно. Не «пользователи не понимают тарифы», а «участники пытаются открыть описание нажатием на название или карточку тарифа, однако эти области не интерактивны».
Вторая формулировка гораздо полезнее для дизайнера: она описывает наблюдаемое поведение, а не предполагаемую причину.
Возвраты и повторные действия
Отдельного внимания заслуживают возвраты назад, повторные клики и переключения между одними и теми же экранами.
Единичный возврат может ничего не означать. Но последовательность «экран A → экран B → экран A → экран B» часто указывает на неопределенность. Пользователь сравнивает информацию, пытается найти недостающие данные или не понимает, какое состояние интерфейса является актуальным.
Повторный клик тоже не всегда означает ошибку. В Figma-прототипе некоторые реакции интерфейса отличаются от полноценного продукта. Поэтому нужно отделять ограничения самого прототипа от проблем проектируемого UX.
Это принципиальное различие. Если участник нажимает кнопку второй раз, потому что прототип недостаточно явно имитирует загрузку, переделывать будущий интерфейс на основании такого наблюдения преждевременно. Если же он повторяет действие потому, что не заметил подтверждения успешной операции, проблема может сохраниться и в готовом продукте.
«Случайно успешные» сценарии
Еще одна категория, которую я отдельно отмечаю при анализе, — успешное прохождение без понимания логики интерфейса.
Например, участник говорит: «Не знаю, наверное, нажму сюда», выбирает правильный элемент и выполняет задачу. В итоговых данных это может выглядеть как успех. Но повторное выполнение аналогичного сценария уже не гарантировано.
Такие случаи особенно хорошо обнаруживаются, если поведенческие данные дополнены комментариями участников или вопросами после задания. Можно спросить, почему человек выбрал именно этот элемент или насколько он был уверен в своем действии.
Если пользователь правильно действует и способен объяснить логику выбора, это сильнее подтверждает понятность интерфейса, чем правильное действие само по себе.
От наблюдения — к формулировке проблемы
При подготовке результатов исследования я стараюсь отделять наблюдение от интерпретации.
Например:
Такая последовательность защищает команду от слишком быстрых выводов. Исследование показывает поведение и помогает сформулировать вероятную причину, но редко диктует единственный вариант дизайна.
Особенно опасно превращать комментарий одного участника непосредственно в задачу на разработку. Фраза «я бы перенес эту кнопку наверх» — это мнение пользователя о решении. Для исследователя важнее другое: почему человеку понадобилось искать кнопку и что помешало обнаружить ее в текущем месте.
Именно поэтому анализ пользовательских путей полезно проводить вместе с ответами участников. Поведение показывает, где возникло затруднение, а качественная обратная связь помогает понять, что пользователь ожидал увидеть в этот момент. Следующий этап анализа — правильно соединить эти два источника данных.
Поведение в Figma-прототипе показывает, что сделал пользователь, но не всегда объясняет, почему он поступил именно так. Поэтому после выполнения сценария я обычно добавляю несколько вопросов. Они помогают восстановить ожидания участника, оценить его уверенность и проверить, совпадает ли наше объяснение ошибки с тем, как ситуацию воспринимал сам пользователь.
Здесь есть важное ограничение: ответы респондентов нельзя рассматривать как точную запись мыслительного процесса. После выполнения задания человек уже знает результат и может рационализировать собственное поведение. Поэтому комментарии лучше использовать вместе с наблюдениями, а не вместо них.
Сопоставляем слова с поведением
Представим, что участник потратил много времени на поиск настройки, несколько раз возвращался на предыдущий экран, но после задания оценил интерфейс на 9 из 10 и написал: «Все понятно».
Если смотреть только на оценку, оснований для изменений почти нет. Если только на поведение — можно решить, что сценарий серьезно затруднен. В действительности эти данные описывают разные стороны опыта.
Возможно, пользователь действительно считает интерфейс в целом понятным, а поиск конкретной настройки не воспринимает как существенную проблему. А возможно, высокая оценка появилась потому, что человек не хочет критиковать продукт или воспринимает вопрос как просьбу поставить общую оценку дизайну.
Поэтому я обращаю особое внимание на расхождения между наблюдаемым поведением и ответами. Именно они часто требуют дополнительной проверки.
Закрытые вопросы помогают сравнивать
Шкалы и вопросы с готовыми вариантами ответа удобны, когда нужно сопоставить несколько заданий или участников. Например, после каждого сценария можно одинаково измерять субъективную сложность или уверенность в результате.
Главное — сохранять одинаковую логику шкалы. Если в одном вопросе 1 означает «очень легко», а в другом — «очень сложно», вероятность ошибок при заполнении и последующем анализе возрастает.
Не стоит перегружать исследование шкалами. Для тестирования прототипа обычно полезнее несколько показателей, непосредственно связанных с гипотезами, чем длинная анкета с общей оценкой каждого элемента.
Открытые ответы объясняют контекст
Открытые вопросы нужны там, где заранее неизвестно, какие причины окажутся важными.
Вместо просьбы «Предложите, как улучшить этот экран» я предпочитаю вопросы о пользовательском опыте: «Что на этом этапе вызвало затруднение?» или «Какого результата вы ожидали после этого действия?».
Разница существенная. Пользователь хорошо описывает собственные ожидания и проблемы, но не обязан уметь проектировать интерфейсы. Когда участник предлагает добавить кнопку, изменить меню или перенести блок, это полезный сигнал, но не готовое проектное решение.
Наша задача — найти потребность, которая стоит за предложением.
Например, комментарий «добавьте кнопку “Назад” сверху» может означать, что пользователь не понимает текущую навигацию. А просьба «показывайте это во всплывающем окне» может говорить о нежелании терять контекст текущего экрана.
Как работать с большим количеством комментариев
Если участников и открытых вопросов становится много, читать ответы последовательно и выбирать «самые интересные» недостаточно. Такой подход легко приводит к смещению: яркие или эмоциональные формулировки запоминаются лучше, хотя встречаться могут всего один раз.
Я использую тематическое кодирование. Ответам присваиваются смысловые категории: например, «непонятное название», «не заметил элемент», «ожидал другое действие», «не хватило информации», «сомнение после завершения».
Один комментарий может относиться сразу к нескольким категориям.
После кодирования уже можно посмотреть, какие темы повторяются и с какими пользовательскими сценариями они связаны. Если ответы собирались через Тестограф, удобно выгрузить результаты и анализировать закрытые показатели вместе с текстовыми комментариями, сохраняя связь с конкретным респондентом и заданием.
При этом частота упоминаний — не единственный критерий важности. Если проблема встретилась один раз, но полностью заблокировала выполнение критического сценария, она может требовать большего внимания, чем часто встречающийся незначительный комментарий о формулировке.
Не превращайте пожелания пользователей в техническое задание
Одна из самых полезных привычек в анализе UX-тестирования — отделять проблему от предложенного пользователем решения.
Если четыре участника говорят, что хотят видеть большую кнопку, общий вывод не обязательно должен звучать как «увеличить кнопку». Возможно, проблема заключается в слабом визуальном приоритете действия, неудачном расположении или непонятной подписи.
В отчете я бы сначала зафиксировал наблюдение: пользователи не замечают основное действие или замечают его поздно. Затем добавил подтверждающие данные — поведение, комментарии и оценки. И только после этого команда может обсуждать варианты изменения дизайна.
Так ответы участников перестают быть набором цитат и превращаются в еще один источник исследовательских данных.
Самые надежные выводы обычно появляются там, где сходятся несколько сигналов: пользователь совершает ошибку, его маршрут показывает затруднение, а комментарий объясняет ожидание, которое привело к этому действию. Если такая комбинация повторяется у нескольких участников, оснований считать проблему системной становится значительно больше.
Но даже повторяющиеся результаты могут выглядеть совершенно по-разному в разных группах пользователей. Поэтому следующим шагом стоит проверить, не скрывает ли общий результат различия между сегментами аудитории.
После общего анализа результатов полезно проверить, одинаково ли ведут себя разные группы участников. Средний показатель способен создавать впечатление, что сценарий работает приемлемо, хотя для одной части аудитории он оказывается значительно сложнее.
Представим, что 8 из 10 участников успешно выполнили задание. Сам по себе результат выглядит достаточно однородным. Но после сегментации выясняется, что все пять пользователей, уже знакомых с продуктом, справились без затруднений, а среди пяти новых пользователей успешно завершили сценарий только трое.
Теперь интерпретация меняется. Возможно, интерфейс понятен тем, кто уже знает его структуру, но требует дополнительного обучения от новой аудитории. Для продукта, который активно привлекает новых клиентов, это принципиально важное различие.
Сегмент должен иметь отношение к гипотезе
Делить участников на группы просто потому, что в анкете собраны соответствующие данные, не стоит. Чем больше вариантов сегментации мы проверяем, тем выше вероятность найти случайные различия и принять их за закономерность.
Я использую сегментацию прежде всего тогда, когда есть разумное предположение, почему определенная характеристика способна влиять на прохождение сценария.
Для одного исследования это может быть опыт использования продукта, для другого — частота выполнения аналогичной задачи или тип устройства. Если тестируется профессиональный сервис, имеет смысл сравнить начинающих и опытных специалистов. Если проверяется мобильный сценарий, потенциально важным фактором может стать привычный способ взаимодействия с подобными сервисами.
Сегмент должен помогать объяснить поведение, а не просто дробить выборку.
Осторожнее с маленькими группами
UX-тестирования часто проводятся на небольших выборках, поэтому сегментация быстро приводит к очень малому количеству наблюдений.
Допустим, в исследовании участвовали восемь человек, а после разделения получилось три новых и пять опытных пользователей. Если один из трех новых участников не справился с заданием, формально можно написать, что успешность в этом сегменте составила около 67%. Но такая точность создает ложное ощущение надежной статистики.
В подобных ситуациях я предпочитаю описывать фактический результат: «два из трех новых пользователей справились с заданием». А главное — смотреть, повторялось ли само затруднение и была ли у участников общая причина ошибки.
При малой выборке сегментация прежде всего помогает обнаруживать гипотезы для следующего исследования, а не доказывать устойчивые различия между группами.
Сравниваем не только успешность
Разница между сегментами может проявляться даже тогда, когда итоговый Task Success Rate практически одинаков.
Например, новые и опытные пользователи одинаково успешно находят нужную функцию. Но опытные сразу переходят в необходимый раздел, а новые сначала изучают меню, возвращаются назад и пробуют несколько вариантов.
С точки зрения конечного результата различий почти нет. С точки зрения пользовательского опыта они заметны.
Поэтому при сегментации я сопоставляю не только факт выполнения задания, но и маршруты, характер ошибок, количество возвратов, субъективную сложность и уверенность.
Иногда именно эта комбинация показывает, что интерфейс опирается на знания, которых у новой аудитории еще нет.
Не объясняйте различие характеристикой пользователя слишком быстро
Если одна группа справилась хуже другой, это еще не означает, что причина найдена.
Например, пользователи мобильных устройств показали более низкую успешность. Можно предположить, что проблема связана с размером экрана. Но возможно, именно в этой группе оказалось больше людей без опыта использования подобных продуктов.
Поэтому формулировка «мобильные пользователи хуже понимают сценарий» будет слишком сильной. Корректнее зафиксировать наблюдаемое различие и проверить его на следующей выборке или дополнительными данными.
В анализе прототипов важно различать сигнал и доказанную закономерность. Небольшое исследование отлично обнаруживает проблемные места и помогает сформировать гипотезы, но далеко не каждое различие позволяет делать вывод обо всей пользовательской аудитории.
В результате сегментация должна отвечать на практический вопрос: для кого именно возникает обнаруженная проблема и есть ли основания проектировать интерфейс с учетом этого различия.
Когда общие показатели, пользовательские пути, комментарии и сегменты рассмотрены вместе, можно переходить к главной части анализа — превращению наблюдений в UX-выводы и определению того, какие проблемы действительно стоит исправлять в следующей версии прототипа.
После анализа метрик, пользовательских путей, ошибок, комментариев и различий между сегментами возникает главный практический вопрос: что именно менять в прототипе?
На этом этапе легко перейти от наблюдения непосредственно к решению. Пользователь не заметил кнопку — сделаем ее больше. Не понял название раздела — переименуем. Долго выбирал тариф — сократим количество вариантов. Но данные тестирования не всегда подтверждают именно такое решение. Они прежде всего показывают проблему, а способ ее устранения еще предстоит определить.
В работе с результатами я использую последовательность:
Она помогает сохранить связь между выводом и исходными данными.
Допустим, несколько участников после оформления заказа продолжают искать кнопку подтверждения. Это наблюдение. Повторение проблемы у разных пользователей и их комментарии становятся подтверждением. Затем появляется интерпретация: текущий экран недостаточно ясно сообщает, что действие уже завершено. И только после этого команда обсуждает решение — изменить сообщение, визуальное состояние, структуру экрана или другой элемент интерфейса.
Ищите сочетание нескольких сигналов
Не все обнаруженные проблемы одинаково надежно подтверждены. Один комментарий участника и повторяющееся затруднение у большинства пользователей имеют разный вес.
Сильным сигналом я считаю ситуацию, когда несколько типов данных указывают в одну сторону. Например, участники долго выполняют один этап, совершают похожие ошибочные действия, низко оценивают уверенность и в открытых ответах описывают одинаковое ожидание.
В таком случае проблема подтверждается сразу поведенческими и субъективными данными.
Но количество упоминаний не должно быть единственным критерием. Редкая ошибка может иметь критические последствия. Если один пользователь случайно удаляет введенные данные и не может восстановить их, такой сценарий заслуживает внимания даже при отсутствии повторений.
Оценивайте частоту вместе с серьезностью
Для приоритизации я смотрю как минимум на два параметра: насколько часто возникает проблема и насколько сильно она мешает достижению пользовательской цели.
Незначительная проблема может встречаться почти у всех: например, участники не сразу замечают второстепенную подсказку, но продолжают работу без дополнительных действий.
Критическая проблема может проявиться у меньшего числа людей: пользователь неверно понимает стоимость заказа, не может завершить оплату или совершает действие с необратимыми последствиями.
Поэтому вывод «исправляем то, что встретилось чаще всего» может привести к неправильному порядку работы.
Дополнительно стоит учитывать значение самого сценария для продукта. Ошибка в редко используемой вспомогательной функции и ошибка в регистрации или оплате могут иметь совершенно разный продуктовый приоритет.
Формулируйте вывод так, чтобы была видна его основа
Формулировка «экран непонятный» практически бесполезна для следующей итерации дизайна. Непонятно, какой элемент создает проблему, для кого она возникает и чем подтверждается.
Гораздо содержательнее написать: «Новые пользователи ожидают найти управление уведомлениями в общих настройках и сначала переходят туда; из-за этого поиск функции требует дополнительных действий».
Такой вывод описывает аудиторию, ожидание и наблюдаемое последствие. Команда получает материал для обсуждения нескольких решений, а не готовую команду «перенести кнопку».
Я также стараюсь избегать формулировок вроде «пользователям не нравится» там, где исследование на самом деле обнаружило проблему с выполнением задачи. Симпатия к дизайну и способность использовать интерфейс — разные характеристики.
Не исправляйте каждый комментарий
После UX-тестирования может появиться длинный список пожеланий: увеличить текст, изменить цвет, добавить кнопку, переставить блок, сделать еще один фильтр. Если превратить каждое пожелание в отдельную задачу, следующая версия прототипа быстро потеряет целостность.
Лучше группировать наблюдения вокруг пользовательских проблем.
Например, предложения «сделать кнопку ярче», «поднять ее выше» и «добавить такую же кнопку в меню» могут относиться к одной проблеме — участники не находят основное действие в нужный момент.
В таком виде данные становятся полезнее для дизайнера: исследование фиксирует проблему, а команда сохраняет возможность выбрать наиболее подходящее решение.
Определите, что нужно проверить повторно
Не каждое изменение после тестирования требует нового большого исследования. Небольшие очевидные исправления можно проверить в рамках следующей итерации вместе с другими задачами. Но если изменение затрагивает навигацию, последовательность ключевого сценария или устраняет критическую проблему, повторная проверка особенно полезна.
Здесь важно не ставить перед новым тестом вопрос «стало ли лучше?». Лучше снова сформулировать наблюдаемое условие: находят ли пользователи функцию без подсказки, понимают ли результат действия, проходят ли сценарий без возвратов в проблемной точке.
Так итерации становятся сопоставимыми.
В итоге хороший результат анализа — это не длинный перечень замечаний, а несколько обоснованных UX-проблем с понятным приоритетом. Для каждой из них команда должна видеть, что произошло, у кого это произошло, какими данными подтверждается вывод, насколько проблема мешает сценарию и что необходимо проверить после изменения дизайна.
Так тестирование перестает быть этапом, после которого дизайнер получает набор субъективных комментариев. Оно становится частью продуктового цикла: гипотеза приводит к прототипу, прототип — к наблюдениям, наблюдения — к изменениям, а изменения — к следующей проверке.
Анализ тестирования Figma-прототипа заканчивается не тогда, когда подсчитан процент успешных прохождений и собраны комментарии участников. Его результат — понятное объяснение того, где пользовательский сценарий работает, где возникают затруднения и какие данные позволяют нам сделать такой вывод.
В своей работе я стараюсь не оценивать прототип одной общей характеристикой — «удобный» или «неудобный». Для продуктовой команды такая оценка почти ничего не дает. Намного полезнее знать, что новые пользователи не находят определенную функцию, несколько участников одинаково интерпретируют название раздела или люди успешно завершают действие, но после него остаются не уверены в результате.
Именно поэтому количественные показатели необходимо рассматривать вместе с пользовательскими маршрутами и обратной связью. Метрики помогают увидеть масштаб, наблюдение за действиями — определить точку возникновения проблемы, а ответы участников — разобраться в их ожиданиях. Если эти источники подтверждают друг друга, вывод становится значительно надежнее.
При этом важно помнить об ограничениях тестирования прототипа. Figma позволяет воспроизвести логику будущего продукта, но не полностью повторяет условия его реального использования. Поэтому исследование прототипа хорошо отвечает на вопросы о понятности сценариев, навигации, ожиданиях и отдельных интерфейсных решениях, но не должно становиться основанием для слишком широких выводов о поведении всей аудитории после запуска продукта.
Хороший итог исследования я бы сформулировал не как список правок, а как набор приоритизированных проблем. Для каждой должно быть понятно, какое поведение мы наблюдали, насколько оно повторяется, чем мешает пользователю и какую гипотезу необходимо проверить после изменения интерфейса.
Такой подход особенно полезен при итерационной работе. После первой проверки команда меняет проблемный участок прототипа, затем повторно тестирует ключевой сценарий и смотрит, исчезло ли исходное затруднение — и не появились ли новые проблемы в соседних шагах.
В результате тестирование становится не формальной проверкой готового дизайна, а инструментом принятия решений еще до разработки. И чем точнее организован анализ, тем меньше вероятность исправлять интерфейс на основании отдельных мнений, случайных действий или красивых, но мало что объясняющих процентов.
Для сбора обратной связи после взаимодействия с прототипом можно использовать Тестограф: объединять шкальные и открытые вопросы, получать ответы участников и затем сопоставлять их с наблюдаемым поведением в пользовательском сценарии.
Главный принцип, который я рекомендую сохранить после прочтения статьи, прост: не начинайте анализ с вопроса «какие цифры мы получили?». Начинайте с вопроса «что мы хотели проверить и какие наблюдения действительно отвечают на этот вопрос?».
Тогда результаты тестирования Figma-прототипа превращаются из набора метрик и комментариев в аргументированную основу для следующей версии продукта.