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