Прототип может выглядеть логичным внутри команды и при этом рассыпаться уже на первых пользовательских тестах. Человек не замечает нужную кнопку, возвращается на предыдущий экран, выбирает неожиданный маршрут или вообще прекращает сценарий. Обычно в этот момент хочется сказать, что проблема находится на конкретном экране. На практике этого недостаточно.
Я работаю с анализом данных и методологией опросов в Тестографе и в исследованиях стараюсь смотреть на такие ситуации шире. Точка потери — это не только место, где пользователь закрыл прототип или перестал двигаться дальше. Ею может быть любой момент, после которого человек теряет уверенность в своих действиях: начинает перебирать элементы интерфейса, возвращается назад, выбирает обходной путь или достигает цели случайно.
Поэтому сами по себе клики дают лишь часть картины. Два участника могут нажать одну и ту же кнопку, но один сделает это сразу и осознанно, а второй — после нескольких попыток, сомнений и неверных переходов. Формально оба успешно прошли шаг. С точки зрения пользовательского опыта это два совершенно разных результата.
В этой статье разберем, как искать такие точки еще на этапе прототипа. Материал будет полезен UX/UI-дизайнерам, продуктовым менеджерам, исследователям и командам, которые проверяют новые пользовательские сценарии до разработки. Основной акцент сделаем не на поиске «плохих экранов», а на выявлении моментов, где ожидание пользователя перестает совпадать с логикой интерфейса.
Именно это расхождение чаще всего и становится источником будущих проблем. Пользователь ожидает увидеть одно, интерфейс предлагает другое, а команда замечает последствия только по кликам, отказам или комментариям после теста. Если научиться фиксировать сам момент такого расхождения, прототипирование превращается из проверки отдельных экранов в полноценный инструмент диагностики пользовательского пути.
Когда мы говорим о потере пользователя, легко представить самый очевидный сценарий: участник не смог выполнить задание и прекратил тест. Но в работе с прототипами такие случаи — лишь верхушка проблемы. Гораздо чаще человек продолжает взаимодействие, хотя уже потерял понимание того, что происходит и куда двигаться дальше.
Например, пользователь хочет изменить адрес доставки. Он открывает профиль, возвращается на главный экран, заходит в раздел заказов, снова возвращается в профиль и только после этого находит нужную настройку. Задача выполнена, поэтому по формальному показателю успешности результат можно записать в успешные. Однако сам маршрут показывает серьезное расхождение между структурой интерфейса и представлением пользователя о том, где должна находиться нужная функция.
Поэтому я бы относил к точкам потери несколько типов поведения:
При этом не каждое необычное действие говорит о UX-проблеме. В интерактивных прототипах часть ошибок возникает из-за ограничений самого макета: не все элементы кликабельны, отсутствуют промежуточные состояния, не работает привычный жест или предусмотрен только один из нескольких естественных маршрутов. Такие случаи важно отделять от ситуаций, когда участник действительно неправильно понимает интерфейс.
Есть еще одна особенность, которую мы учитываем при анализе исследований: точка, где проблема проявилась, и точка, где она возникла, могут находиться на разных экранах.
Допустим, пользователь останавливается на экране подтверждения заказа, потому что не понимает итоговую стоимость. Кажется, что исправлять нужно именно этот экран. Но во время разбора выясняется, что еще двумя шагами раньше человек неправильно понял принцип применения скидки. На последнем экране проблема только стала заметной. Если изменить исключительно экран подтверждения, причина затруднения останется.
Поэтому перед тестированием полезно определить не просто набор экранов, а ожидаемый пользовательский сценарий: какую задачу получает участник, какие решения ему предстоит принять и какие действия будут свидетельствовать о понимании интерфейса. Дополнительную обратную связь после прохождения сценария можно собирать с помощью онлайн-опросов Тестографа, сопоставляя ответы участников с наблюдаемым поведением.
Для анализа я использую простое правило: точку потери стоит искать там, где пользователю впервые приходится действовать вопреки собственному ожиданию. Остановка, неправильный клик или возврат назад — это уже следствие. Исследовательская задача состоит в том, чтобы восстановить момент, когда логика человека и логика прототипа впервые разошлись.
Качество анализа во многом определяется еще до того, как первый участник откроет прототип. Если дать человеку слишком общее задание, а затем просто наблюдать за кликами, после теста можно получить много заметок, но мало данных для принятия решений. Поэтому сначала я рекомендую определить, какой именно сценарий мы проверяем и что в нем считаем успешным прохождением.
Начинать лучше с задачи пользователя, а не с интерфейса. Формулировка «Найдите кнопку изменения тарифа и выберите новый тариф» уже подсказывает структуру продукта. Более полезное задание звучит ближе к реальной ситуации: «Вы поняли, что текущих возможностей тарифа вам недостаточно. Попробуйте перейти на подходящий вариант». Во втором случае участнику приходится самостоятельно определить, где искать нужную функцию. Именно здесь и проявляется соответствие интерфейса ожиданиям человека.
До тестирования я обычно разбиваю предполагаемый маршрут на критические шаги. Для каждого определяю ожидаемое действие и признаки затруднения. Например, если пользователь должен оформить доставку, критическими точками могут стать выбор способа получения, ввод адреса, проверка стоимости и подтверждение заказа. Если участники регулярно теряются на одном из этих переходов, появляется основание изучать его подробнее.
При этом важно не превращать ожидаемый маршрут в единственно правильный. Пользователь может найти более короткий или просто другой способ выполнить задачу. Если этот путь предусмотрен логикой продукта и не вызывает затруднений, считать его ошибкой не нужно. Цель теста — проверить, может ли человек решить задачу, а не подтвердить предположения команды о том, как именно он обязан это сделать.
Отдельно стоит проверить формулировки заданий. Одна из распространенных методологических ошибок — случайно подсказать участнику название раздела, кнопки или функции, которую мы хотим протестировать. Если в интерфейсе есть раздел «Управление подпиской», не стоит просить человека «перейти в управление подпиской». Иначе мы проверяем способность найти уже названный элемент, а не понятность навигации.
После каждого важного сценария полезно собирать короткую обратную связь. Для этого можно использовать Тестограф: например, попросить участника оценить сложность выполнения задачи, уверенность в результате, а затем объяснить возникшие затруднения открытым ответом. Такой опрос не заменяет наблюдение за прохождением прототипа, но помогает понять, как сам пользователь воспринимал ситуацию.
Главное на этапе подготовки — заранее решить, какие сигналы мы будем интерпретировать. Тогда во время исследования мы не просто отмечаем, что «участник долго думал», а можем сопоставить его поведение с конкретным шагом сценария, ожидаемым действием и последующим объяснением. Это значительно упрощает поиск настоящих точек потери и снижает риск объяснять результаты уже после теста удобной для команды гипотезой.
Точка потери редко выглядит как однозначный отказ. Чаще пользователь продолжает взаимодействовать с прототипом, но его поведение меняется: уверенные действия сменяются поиском, проверкой гипотез и возвратами. Именно этот переход особенно интересен для исследования.
Первый заметный сигнал — увеличение времени на конкретном шаге. Но само по себе время нельзя считать доказательством проблемы. Человек может задержаться, потому что внимательно сравнивает несколько вариантов или читает важную информацию. Поэтому я смотрю не на продолжительность паузы отдельно, а на то, что происходит до и после нее.
На возможную точку потери обычно указывает сочетание нескольких признаков:
Особенно полезно анализировать повторные клики. Если человек несколько раз нажимает на элемент, который не предполагает действие, проблема может заключаться не в отсутствии функции, а в визуальном обещании интерфейса. Карточка, заголовок или иконка выглядят кликабельными, поэтому пользователь ожидает соответствующей реакции.
Есть и менее очевидный сценарий — ложный успех. Участник достигает финального экрана, и показатель выполнения задачи формально составляет 100%. Однако при наблюдении видно, что правильный путь был найден методом перебора. Если оценивать только факт завершения сценария, такой результат легко принять за подтверждение удачного UX.
В проектах, где я консультирую по методологии исследования, я рекомендую после критических этапов сопоставлять три слоя данных: что пользователь сделал, сколько усилий потребовалось для действия и как он сам объясняет свой выбор. Например, быстрый правильный клик в сочетании с низкой уверенностью тоже заслуживает внимания. Возможно, человек угадал, а не понял интерфейс.
Здесь полезна короткая оценка сразу после выполнения задачи: «Насколько вы были уверены, что выбрали правильное действие?» или «Насколько легко было понять, что делать дальше?». Ответы можно собирать через формы и опросы Тестографа и затем сопоставлять их с наблюдениями по каждому сценарию.
При этом единичный необычный клик еще не повод переделывать интерфейс. Намного важнее повторяемость. Если несколько участников с разным опытом начинают сомневаться примерно в одной точке, используют похожие обходные маршруты или одинаково интерпретируют элемент не так, как предполагала команда, мы получаем паттерн.
Поэтому при анализе я стараюсь не ставить диагноз отдельному действию. Пауза, возврат или неправильный клик — это сигнал, который требует контекста. Настоящая точка потери обнаруживается тогда, когда мы можем связать наблюдаемое поведение с конкретным ожиданием пользователя и увидеть, что это расхождение повторяется у других участников.
После тестирования легко получить список вроде: «не нашел кнопку», «вернулся назад», «долго выбирал», «перешел не туда». Для первичной фиксации наблюдений этого достаточно, но для изменения прототипа — нет. Такие записи описывают последствия, а команде необходимо понять причину.
В своей работе я использую разбор «шаг назад». Если участник совершил ошибочное действие, мы возвращаемся не к самому клику, а к моменту непосредственно перед ним. Что человек видел? Какую задачу пытался решить? Какой результат ожидал получить? На основании какого элемента интерфейса сформировал это ожидание?
Допустим, участник нажал «Назад» на этапе оформления заказа. Можно решить, что ему непонятен текущий экран. Но при разборе оказывается, что он вернулся, чтобы проверить, применился ли промокод. Тогда причина находится раньше: предыдущий экран не дал достаточно понятного подтверждения применения скидки. Кнопка «Назад» лишь помогла обнаружить проблему.
Большинство таких расхождений можно свести к нескольким источникам:
При этом вопрос «Что здесь было непонятно?» часто дает слабые результаты. Он заставляет участника уже после события рационализировать собственное поведение. Человек может ответить: «Все понятно», хотя минуту назад несколько раз возвращался на предыдущий экран.
Полезнее задавать вопросы, привязанные к конкретному решению: «Что вы ожидали увидеть после этого действия?», «Почему выбрали именно этот раздел?», «Что на экране подсказало вам следующий шаг?». Такие формулировки помогают восстановить логику участника, а не получить общую оценку интерфейса.
Если исследование проводится без постоянного присутствия модератора, подобные вопросы можно встроить в отдельный опрос через Тестограф. Важно размещать их после конкретного сценария, пока участник еще помнит ход своих решений. При этом вопросов не должно быть слишком много: если останавливать человека после каждого клика, мы сами изменим естественное взаимодействие с прототипом.
В результате вместо записи «пользователь не нашел функцию» должна появиться более содержательная гипотеза: например, «пользователь искал изменение адреса в настройках профиля, потому что воспринимал адрес как данные аккаунта, тогда как прототип разместил его внутри конкретного заказа».
С такой формулировкой уже можно работать. Она показывает не только место сбоя, но и расхождение двух моделей — пользовательской и продуктовой. Именно это позволяет изменить прототип осмысленно, а не просто сделать очередную кнопку крупнее.
Наблюдение показывает, что сделал пользователь, но не всегда объясняет, почему он поступил именно так. Опрос, наоборот, позволяет получить объяснение, но это объяснение может расходиться с реальным поведением. Поэтому при тестировании прототипа я стараюсь не выбирать между этими источниками, а сопоставлять их.
Представим, что участник успешно оформил заказ за ожидаемое время и не совершил заметных ошибок. Если после сценария он оценивает свою уверенность на 2 балла из 5, результат уже нельзя считать однозначно успешным. Возможно, интерфейс позволил выполнить задачу, но не дал человеку достаточно обратной связи, чтобы убедиться в результате.
Встречается и обратная ситуация. Пользователь говорит, что сценарий был простым, хотя во время теста несколько раз возвращался назад и проверял разные разделы. Это не означает, что участник отвечает неправильно. После достижения цели первоначальные затруднения могут восприниматься как несущественные. Для исследователя же они остаются важными данными.
Поэтому после ключевого сценария я рекомендую ограничиваться несколькими вопросами:
Для количественной оценки удобно использовать одинаковую шкалу для всех участников. Например, просить оценить уверенность от 1 до 5. Такие ответы позволяют сравнивать разные версии прототипа и находить сценарии, в которых формальная успешность высокая, а субъективная уверенность остается низкой.
Открытый вопрос решает другую задачу. Он дает возможность увидеть формулировки самого пользователя. В работе с исследованиями я считаю это особенно полезным: участник может описать функцию или раздел совсем не теми словами, которыми пользуется продуктовая команда. Иногда именно эта разница объясняет, почему навигация или название кнопки работают хуже ожидаемого.
При этом не стоит спрашивать: «Как бы вы переделали этот экран?» Пользователь хорошо описывает собственные ожидания и затруднения, но не обязан проектировать решение. Ответ «я бы добавил большую кнопку» еще не означает, что именно большая кнопка устранит причину проблемы. Для команды ценнее понять, какую информацию человек искал и почему существующий интерфейс не помог ее обнаружить.
Для сбора таких данных можно использовать Тестограф, сочетая шкальные и открытые вопросы в одном исследовании. Тогда для каждого сценария мы получаем не просто комментарии участников, а сопоставимый набор данных: успешность прохождения, наблюдаемое поведение, субъективную сложность, уверенность и объяснение возникших затруднений.
Самые интересные точки находятся именно в расхождениях между этими показателями. Быстро выполнил задачу, но не уверен в результате. Сказал, что все просто, но трижды возвращался назад. Не дошел до цели, хотя был уверен, что успешно завершил сценарий. Такие противоречия дают исследователю больше информации, чем отдельно взятый показатель времени или ответ на вопрос.
В результате опрос становится не самостоятельной оценкой интерфейса, а дополнительным слоем диагностики. Поведение показывает место возможного сбоя, а ответы помогают восстановить ожидание пользователя. Вместе они позволяют гораздо точнее определить, где именно начинается потеря и что команда должна проверить в следующей версии прототипа.
После нескольких тестов список проблем обычно получается длиннее, чем команда рассчитывала. Один участник не заметил фильтр, несколько человек неправильно поняли название раздела, кто-то вернулся назад при оформлении, а еще один не смог завершить основной сценарий. Исправлять все одновременно — плохая стратегия: становится сложно понять, какое изменение действительно улучшило прототип.
Частота проблемы кажется самым очевидным критерием приоритета. Если четыре участника столкнулись с затруднением, а один — с другой проблемой, первая автоматически выглядит важнее. Но на небольших UX-тестах такой подход может привести к неверным выводам.
Я рекомендую оценивать точку потери минимум по трем параметрам:
Например, пять участников могут не сразу заметить дополнительный фильтр, но через несколько секунд самостоятельно его находят и продолжают работу. Другой проблемой сталкивается только один человек, зато из-за нее он подтверждает заказ с неверными параметрами и уверен, что сделал все правильно. Вторая проблема встречается реже, но ее последствия значительно серьезнее.
Особого внимания требуют невидимые потери. Это ситуации, когда пользователь не понимает, что допустил ошибку. Если человек остановился, проблема хотя бы становится заметной. Гораздо опаснее сценарий, в котором он успешно доходит до финала, но получает не тот результат, который ожидал. В реальном продукте такие ошибки могут приводить к повторным обращениям, отменам или недоверию к интерфейсу.
При анализе результатов небольших исследований важно не превращать несколько наблюдений в статистику масштаба всей аудитории. Если трое из пяти участников не нашли функцию, корректнее говорить, что мы обнаружили повторяющийся паттерн, требующий проверки, а не утверждать, что «60% пользователей не могут найти функцию». Для оценки распространенности проблемы потребуется исследование с подходящей выборкой.
Поэтому после качественного тестирования я формулирую вывод как гипотезу: какое ожидание пользователя нарушается, насколько это мешает выполнить задачу и какое изменение должно уменьшить затруднение. Уже после этого можно решить, достаточно ли исправить прототип и провести повторный UX-тест или требуется количественная проверка.
Если нужно проверить гипотезу на более широкой аудитории, можно собрать ответы через онлайн-опрос в Тестографе. Здесь важно разделять задачи методов: несколько наблюдаемых UX-сессий помогают обнаружить и объяснить проблему, а количественный опрос — оценить, насколько определенное мнение, ожидание или затруднение распространено в выбранной аудитории.
В итоге приоритет должен определяться не количеством заметок напротив конкретного экрана, а риском для пользовательской задачи. В первую очередь стоит разбирать точки, где человек не может продолжить путь, получает неверный результат или даже не замечает собственной ошибки. Именно такие проблемы способны превратить внешне успешный сценарий в реальную потерю пользователя после запуска продукта.
Исправленная точка потери еще не означает исправленный сценарий. После изменения навигации, текста или расположения элементов пользователь действительно может перестать ошибаться в прежнем месте, но начать испытывать затруднение на следующем шаге. Поэтому после заметных изменений прототип желательно тестировать повторно.
Задача такого теста — не доказать, что новая версия стала лучше, а проверить конкретную гипотезу. Например: «Если сделать результат применения промокода заметнее, пользователи перестанут возвращаться на предыдущий экран для проверки скидки». Такая формулировка сразу определяет, за каким поведением нужно наблюдать.
При сравнении версий я стараюсь сохранять одинаковую структуру задания и сопоставимые условия. Иначе сложно понять, связано изменение результата с новым интерфейсом или с тем, что во втором тесте участники получили более понятную инструкцию.
При этом повторно приглашать тех же людей для проверки того же сценария нужно с осторожностью. Они уже знают структуру прототипа, помнят расположение элементов и могут пройти путь быстрее благодаря обучению. Если задача исследования — проверить, насколько интерфейс понятен при первом знакомстве, предпочтительнее привлечь новых участников с похожими характеристиками.
Сравнивать стоит не один показатель, а несколько сигналов:
Время здесь особенно легко интерпретировать неправильно. Если новая версия проходится на десять секунд быстрее, это еще не доказывает улучшение. Намного важнее понять, исчезло ли конкретное поведение, ради которого вносилось изменение. Если раньше участники регулярно открывали неправильный раздел, а после изменения сразу выбирают ожидаемый путь, это гораздо содержательнее простой разницы во времени.
После прохождения обновленного сценария полезно повторить те же вопросы, которые задавались при тестировании предыдущей версии. Сопоставимые формулировки позволяют увидеть, изменилось ли не только поведение, но и восприятие интерфейса. Для таких замеров можно создать анкету в Тестографе и использовать единую структуру вопросов для разных итераций прототипа.
Отдельно я рекомендую проверять участок сразу после исправленной точки. Допустим, команда упростила выбор способа доставки и пользователи начали проходить этот этап без ошибок. Но из-за новой структуры следующий экран теперь воспринимается иначе, и затруднение перемещается на подтверждение заказа. Если исследователь смотрит только на исправленный элемент, такую миграцию проблемы легко пропустить.
Поэтому повторный тест лучше воспринимать как проверку всего короткого сценария, а не отдельного экрана. Мы хотим увидеть не просто исчезновение старой ошибки, а восстановление понятного пользовательского пути.
Хороший результат выглядит так: участнику стало проще принять правильное решение, уменьшилось количество поисковых действий, а уверенность после выполнения задачи выросла. Если эти изменения повторяются у новых участников, у команды появляется гораздо больше оснований считать, что гипотеза сработала. После этого можно переходить к следующей точке потери и повторять цикл проверки.
Поиск точек потери в прототипе полезнее воспринимать не как составление списка UX-ошибок, а как восстановление пользовательского пути. Для каждого проблемного момента нам важно понять последовательность: что человек хотел сделать, чего ожидал от интерфейса, что увидел, какое действие выбрал и в какой момент его представление перестало совпадать с логикой продукта.
Так постепенно вместо набора замечаний «не увидел кнопку» или «перешел не туда» появляется карта потерь. На ней можно отметить критические шаги сценария, наблюдаемое поведение, предполагаемую причину затруднения и последствия для основной задачи. Такая структура помогает команде обсуждать не вкусовые предпочтения в интерфейсе, а конкретные пользовательские проблемы.
В работе с исследованиями я придерживаюсь простой последовательности:
При необходимости наблюдения можно дополнять количественными и качественными ответами, собранными через Тестограф. Особенно полезно сохранять одинаковые вопросы между итерациями: так проще увидеть, меняется ли уверенность пользователей, воспринимаемая сложность и понимание результата после изменений прототипа.
Главный вывод здесь довольно практичный: не исправляйте место, где пользователь остановился, пока не поняли, где он начал теряться. Эти две точки часто не совпадают. Ошибка может проявиться на финальном экране, хотя неверное ожидание сформировалось несколькими шагами раньше.
Если выстроить исследование вокруг этого принципа, прототип перестает быть только способом показать будущий интерфейс. Он становится инструментом, с помощью которого можно обнаружить проблемную логику до разработки, проверить причины затруднений и последовательно улучшить сценарий еще до того, как с этими проблемами столкнутся реальные пользователи.