Как записи сессий заставляют бизнес исправлять не ту проблему

Чтобы понять, почему посетители не доходят до целевого действия на сайте, команды часто смотрят записи пользовательских сессий. Они позволяют увидеть, как конкретный человек взаимодействовал со страницей: куда нажимал, что прокручивал, на каком этапе остановился или ушёл.

Такие записи хорошо показывают, что произошло. Проблема начинается, когда команда пытается по тем же действиям сразу определить, почему это произошло.

Например, на сайт приходит трафик, однако пользователи редко отправляют форму заявки. Записи сессий показывают похожий сценарий. Человек начинает заполнять поля, доходит до номера телефона и закрывает страницу.

Причина кажется понятной. Посетитель опасается разговора с менеджером.

Команда рассматривает несколько решений. Можно сделать телефон необязательным, сократить форму или предложить переписку в мессенджере. Любой из вариантов способен улучшить результат. При этом запись сессии ещё не подтверждает, что отказ связан со звонком.

Поле могло некорректно работать на конкретном устройстве. Иногда пользователь не понимает допустимый формат номера. В других случаях его останавливает неизвестность после отправки формы. Он не знает, кто свяжется с ним и как будет развиваться разговор.

Например, специалисты UsabilityLab отмечают, что пользователи привыкли вводить номер телефона в разных форматах. Если форма не помогает понять ожидаемый формат, ошибка на этом этапе сама может стать препятствием для продолжения сценария.

Источник:
UsabilityLab — Юзабилити-проблемы форм ввода в банковских приложениях

Команда видит момент отказа и получает несколько возможных объяснений. Ошибка возникает, когда одно из них принимают за установленную причину и сразу превращают в задачу для дизайнера, разработчика или маркетолога.

Этому особенно легко поверить именно потому, что запись выглядит намного конкретнее обычной аналитики.

Почему запись легко принять за объяснение

Воронка показывает этап, на котором теряются пользователи. Запись сессии позволяет рассмотреть отдельное посещение почти покадрово. На экране видны прокрутки, клики, переходы между страницами и заполнение форм.

Такая детализация создаёт ощущение, что поведение человека уже расшифровано.

Например, Вебвизор Яндекс Метрики записывает содержимое страницы, которое видел посетитель, и его действия во время визита. Это позволяет найти конкретный момент затруднения. Но последовательность действий сама по себе ещё не объясняет мотив человека.

Источник:
Яндекс Метрика — Вебвизор

Представим, что пользователь несколько раз переключается между тарифами, возвращается к предыдущему варианту, снова читает описания и закрывает страницу.

Команда связывает уход с высокой ценой. Возникает идея добавить скидку, специальное предложение или подробное обоснование стоимости.

У происходящего может быть другое объяснение. Возможно, тарифы трудно сравнить. Один пакет описан через функции, второй через преимущества, третий через ограничения. Пользователю приходится удерживать в памяти несколько длинных описаний, чтобы найти различия.

Он покидает страницу раньше, чем успевает оценить стоимость предложения. Скидка уменьшит цену, но процесс выбора останется таким же сложным.

Запись допускает обе интерпретации. Сам инструмент не определяет, какая из них точнее.

При этом дополнительная проверка нужна не всегда. Иногда проблема действительно видна непосредственно в интерфейсе.

Когда запись уже даёт достаточно оснований для изменения

Не каждое наблюдение требует отдельного пользовательского исследования.

К первой категории относятся и некоторые менее очевидные интерфейсные затруднения. Например, элемент регулярно принимают за кнопку, важное действие остаётся незамеченным или пользователи несколько раз возвращаются к одному и тому же блоку навигации.

Если паттерн повторяется, команда может проверить, связан ли он с устройством интерфейса, и обосновать локальное изменение без полноценного исследования мотивов.

Но когда возможные объяснения связаны с ожиданиями, доверием или восприятием ценности, наблюдаемого действия недостаточно. Можно увидеть, что человек не отправил форму, но нельзя с полной уверенностью определить, испугался ли он звонка, не понял следующий шаг, не увидел достаточной пользы или решил вернуться позже.

По похожему принципу уход со страницы тарифов ещё не доказывает недовольство ценой, а возвращение к первому экрану само по себе не подтверждает слабый заголовок.

Записи помогают находить явные интерфейсные барьеры и места, требующие дополнительной диагностики. Необходимость следующего исследования зависит от того, можно ли связать повторяющееся поведение с конкретным препятствием без догадки о мыслях пользователя.

Риск возникает, когда такую границу команда не проводит и интерпретация сразу становится основанием для работы.

Как правдоподобная версия превращается в расходы

У команды редко есть время на подробное исследование каждой просадки. Бизнесу нужен план, специалистам требуется конкретная задача, проект должен двигаться дальше.

Фраза «форма слишком длинная» сразу подсказывает решение. Поля можно убрать, переставить или объединить.

Признание неопределённости усложняет следующий шаг. Придётся проверить техническую часть, изучить другие записи, посмотреть обращения клиентов и рассмотреть несколько причин.

На интерпретацию влияют проблемы, которые компания уже обсуждает. Сомнения в качестве рекламы заставляют связывать короткие сессии с нецелевым трафиком. Руководство беспокоится о цене, и выход со страницы тарифов начинает восприниматься как подтверждение высокой стоимости. Запланированный редизайн делает затруднения пользователей дополнительным аргументом в пользу полной переделки интерфейса.

Здесь полезно разделять количественные и качественные данные. Первые помогают увидеть масштаб и повторяемость проблемы, вторые — разобраться в причинах поведения. Поэтому способ проверки зависит от конкретной гипотезы, а одного наблюдаемого события не всегда достаточно для вывода.

Источник:
Яндекс Практикум — Количественные и качественные UX-исследования

Выбранное объяснение определяет дальнейшую работу. Подозрения в качестве трафика направляют внимание маркетинга на рекламные кампании. Версия о высокой стоимости приводит к пересмотру предложения. Проблемы формы переходят к дизайнеру и разработчику.

Каждое решение выглядит рационально, поскольку соответствует поставленному диагнозу.

Команда готовит макеты, реализует изменения и ждёт результата. Показатели почти не меняются, поэтому появляется новая версия. К уже сокращённой форме добавляют всплывающее окно, затем запускают другую рекламу или предлагают скидку.

Исходный барьер всё это время может оставаться нетронутым.

Особенно дорого обходятся масштабные решения. Полный редизайн способен улучшить внешний вид сайта и сохранить старую проблему в конкретном сценарии. Новая версия становится современнее и аккуратнее, а пользователь по-прежнему останавливается на том же шаге.

До начала работы стоит проверить проблемный участок и логику, с помощью которой команда назначила ему причину.

Как проверить гипотезу до доработки

Работу лучше начать с точной фиксации наблюдаемого поведения.

Дальнейшая проверка состоит из четырёх этапов.

Часть гипотез можно проверить технически или по дополнительным данным. Но когда вопрос касается ожиданий и мотивов человека, наблюдения за интерфейсом может быть недостаточно.

Когда нужен пользовательский тест

Запись сессии показывает действия человека без комментариев. Во время пользовательского теста участник получает реалистичную задачу и проговаривает свои ожидания по ходу работы.

Например, его просят выбрать подходящий тариф и отправить запрос на консультацию.

Наблюдатель не подсказывает маршрут. Он следит за тем, где участник сомневается, какие элементы считает интерактивными, какую информацию пытается найти и чего ждёт после нажатия кнопки.

Так обнаруживаются причины, которые невозможно уверенно восстановить по движениям курсора. Участник может опасаться, что форма сразу запросит данные карты. Другой человек не видит разницы между пакетами. Третий откладывает заявку, поскольку не знает, кто и когда ему позвонит.

Метод «мыслей вслух» позволяет связать действия участника с тем, как он понимает интерфейс и чего ожидает в конкретный момент.

Источник:
UsabilityLab — Метод «мыслей вслух»

Несколько тестов не дают статистически полной картины аудитории. Они помогают обнаружить барьеры и объяснения, которые команда могла не рассмотреть.

На практике вывод обычно строится не на одном методе, а на сочетании записей, данных воронки, технической проверки и пользовательских сигналов.

Когда пользователи регулярно останавливаются в одном месте, а логичные доработки не влияют на результат, следующую реализацию стоит отложить до проверки исходной гипотезы. Это снижает риск потратить ресурсы на решение, которое выглядит убедительно внутри команды, но не меняет пользовательский опыт.

Что делать после проверки гипотезы

Проверка гипотезы помогает определить реальный масштаб задачи до того, как команда начнёт тратить ресурсы на реализацию.

Иногда проблема находится в отдельном поле, состоянии кнопки, названии раздела или другом локальном элементе. Тогда нет смысла пересобирать весь пользовательский сценарий.

В других случаях несколько затруднений связаны между собой: пользователю сложно найти нужную информацию, сравнить варианты или понять следующий шаг. Тогда локальных исправлений может быть недостаточно и потребуется более серьёзная переработка интерфейса.

После проверки становится понятнее, какой масштаб изменений действительно нужен. Это может быть локальная доработка интерфейса, переработка отдельного пользовательского сценария или полноценный редизайн.

Если для решения проблемы требуется проектирование и разработка, команда El Pixel может реализовать изменения нужного масштаба. Мы работаем как с отдельными элементами и пользовательскими сценариями, так и с комплексной переработкой продукта.

Читайте также:
Почему редизайн сайта стоит по-разному и как понять, за что вы платите →