Казалось бы, ваши копирайтеры хорошо постарались и изложили на сайте всю возможную информацию о продукте и его использовании, которая может интересовать потребителя. Но в техподдержку продолжает поступать большое количество звонков по самым рутинным вопросам, ответы на которые точно есть в разделе «Помощь». Возможно, пользователи просто заблудились в дебрях информационной архитектуры сайта компании.
Как выявить «узкие места» и с помощью методики ранжирования требований вывести посетителя из этого информационного лабиринта, расскажем в статье.
Проблема, задачи и выбор методики решения
Заказчик из банковской сферы обратился к нам с проблемой: его клиенты при возникновении вопросов не приходят в соответствующий раздел сайта, а обращаются в лучшем случае – на горячую линию техподдержки, в худшем – ко внешним источникам. В итоге колл-центр загружен вопросами, которые должен был решить соответствующий раздел сайта. А пользователи, не находя там ответов на свои вопросы, вынуждены покинуть сайт и искать решение вовне, иногда попадая в неблагонадежные руки. Стоит ли говорить, что это ведёт заказчика к потере потенциальных клиентов?
Перед бизнесом встали следующие задачи:
- задержать клиента на сайте,
- увеличить конверсию (долю посетителей сайта, воспользовавшихся банковским продуктом),
- предотвратить мошенничество и обращение клиентов ко внешним источникам,
- уменьшить количество звонков в техническую поддержку сайта, тем самым сократить нагрузку на специалистов,
- повысить лояльность клиента за счет решения его вопросов и обеспечить повторное посещение сайта.
Для решения поставленных задач мы применили подход ранжирования требований. Подробнее о нем можно прочитать в своде знаний для бизнес-аналитиков BABOK.
Для использования этой методики у нас было всё необходимое:
- Набор пользовательских кейсов, который определили в соответствии с полученной информацией о посетителях сайта и их действиях. Он был необходим для кластеризации персонажей.
- Набор данных по сайту (метрики о полезности статей, о количестве переходов, о переходах по формам, а также SEO-метрики). По ним можно было судить о проблемах клиентов и строить гипотезы.
Нам потребовалось выполнить следующие действия:
- составить Customer Journey Map и выявить узкие места,
- кластеризовать персонажей, т.е.определить группы пользователей,
- выявить основные требования пользователей, т.е. проблемы, которые у них возникают при взаимодействии с UI сайта, определить их вес и проранжировать,
- предложить пути решения.
Итак, обо всем по порядку.
Составление Customer Journey Map и выявление узких мест
Для визуализации клиентского опыта пользования сайтом и выявления узких мест составили Customer Journey Map.
На основании имеющихся на входе метрик и информации по обращениям в службу технической поддержки мы определили три основных «точки входа» пользователя.
- Звонок в контакт-центр (КЦ).
- Поиск в Google.
- Поиск ответа на сайте.
Схема позволила нам выделить следующие узкие места:
- Текущая информационная архитектура контента на сайте сложная и нелинейная. На основе обратной связи мы установили, что пользователи, пытаясь найти ответ, начинают ходить по разным разделам и могут потеряться.
- Информационная перегруженность сайта заказчика пугает пользователя. Он приходит с проблемой, но видит, что сначала ему придется разобраться в интерфейсе. А это прибавляет ситуации напряженности. Главная страница раздела “Помощь” охватывает большое количество контента и предлагает посетителю совершить множество действий. Но её цель – успокоить пользователя, дать понять, что его проблему решить легко, и предложить выполнить всего одно или два действия.
- На странице помощи с формой составления обращения отсутствовали какие-либо инструкции. Пользователи отмечали, что им непонятно, что нужно делать.
- При неудачном совершении операции на сайте клиенты не получали информации о том, что именно пошло не так, и инструкции, что делать в этом случае. Таким образом, нарушен принцип UX-writing (компактно, понятно, полезно) – пользователь остается наедине с нерешенной проблемой и сообщением «Ошибка платежа, платеж отклонен».
Кластеризация персонажей
На основании уже имеющихся данных мы выделили следующие группы пользователей:
- Потенциальный клиент: еще не пользуется продуктами банка, но интересуется ими.
- Неактивный клиент: использует продукты банка очень редко.
- Активный клиент: широко использует продукты банка в повседневной жизни и для бизнеса.
В вашем случае персонажей может быть больше, но в той ситуации нам было достаточно трех. Если их получается много, и вы не знаете, какие группы исключить, можно построить дендрограммы. Если достаточно очевидно, что один персонаж может поглотить другого, можно обойтись без схем.
Для решения этого кейса нам не требовалось описание персонажей. Но, как правило, чтобы дальше работать над целевой аудиторией, на каждого из них нужно составить карточку, обрисовать портрет (место работы, возраст, привычки и т.п.). К тому же, это может быть полезным при проработке отдельных процессов и улучшении UX сайта.
Выявление основных проблем пользователей при взаимодействии с UI сайта
На основе данных метрик и обращений в техподдержку мы составили таблицу.
Обращения проранжировали по фразам, несущим смысловую нагрузку. Учитывались только данные по тем пользователям, которые перед звонком в техподдержку пытались найти ответ на свой вопрос на сайте, но не смогли из-за его сложной структуры или отсутствия релевантного контента.
Больше всего обращений пользователей содержали слова «Перевод», «Карты», «Оплата», «Пополнение». Реже встречались «Идентификация», «Информация о банке». Практически не встречались «Авторизация», «Регистрация», «Безопасность». Это говорило о том, что с данным разделом всё в порядке, и пользователь знаком с ним.
Данные по SЕО-метрикам, переходам по статьям и формам также оказались полезными для анализа. С учетом имеющихся сведений мы сделали вывод, что в поисковых запросах люди в основном искали следующее: «Что это», «(наименование банка) – это», «Что такое (наименование банка)». По ним они и переходили на соответствующую статью на сайте.
И если взглянуть на данные метрик переходов по статьям, становится понятно, что пользователи не обращались за помощью по запросам, на которые больше всего информации представлено на главной странице банка. В нашем случае: «Идентификация», «Регистрация», «Мобильное приложение».
После анализа данных у нас появились основные поведенческие переменные. Под этим термином мы подразумеваем то или иное требование пользователя, т.е. потребность, за удовлетворением которой он приходил на сайт заказчика. Далее мы работали именно с ними.
На следующем шаге нам нужно было определить вес каждой поведенческой переменной с точки зрения определенных ранее персонажей (в нашем случае использовалась шкала от 0 до 3). Этот показатель обозначает, насколько та или иная переменная значима для конкретной группы пользователей. Например, для сегмента «Активный клиент» авторизация более важна, чем для «Потенциального клиента», так как у активного есть потребность в регулярном использовании данной фичи, а у потенциального нет.
Расчет веса требования пользователя (от 0 до 3)
Коэффициент ценности группы показывает, насколько важна та или иная группа пользователей с точки зрения бизнеса, какой вклад она вносит. Этот показатель мы распределили на основании гипотезы:
- потенциальный клиент вносит средний вклад;
- неактивный клиент – самый минимальный вклад;
- активный клиент – основной вклад.
Далее переменные были умножены по каждому сегменту (Вес требования х Коэффициент ценности). Результат мы суммировали по горизонтали. После выполнения несложных математических действий у нас получилась следующая картина.
Расчет ценности группы (от 0 до 3)
Разработка рекомендаций для клиента
Метрики и полученные данные позволили нам сделать вывод о том, что больше всего пользователей волнуют следующие вопросы:
- пополнение,
- оплата,
- перевод,
- карты и информация о банке (продуктах банка).
Полученные результаты позволили:
- Сформировать структуру раздела «Помощь» из трех уровней: категории, тематики, статьи.
- На основе запросов пользователей определить тематики и статьи.
- Обозначить порядок верхнего уровня (категорий) и состав тематик по каждой категории. При формировании категорий мы учли, что при просмотре страницы фокус внимания направлен на центральную часть, а затем перемещается слева-направо.
- Описать состав каждой категории.
При проработке структуры разделов учли, что у бизнеса могут быть свои требования и ограничения. В нашем случае было необходимо сохранить блоки «Безопасность» (требование законодательных актов) и «Идентификация» (приоритет услуги с точки зрения бизнеса).
Итоговая структура раздела «Помощь» приняла следующий вид:
- Пополнение и платежи.
- Карты.
- Информация о счёте.
- Безопасность.
- Идентификация.
- Другие продукты.
По итогам проекта заказчик отметил, что поставленные цели были достигнуты: сократилось количество обращений в техподдержку и возросла удовлетворённость клиентов продуктом, пользователи получили возможность быстро и без усилий находить на сайте ответы на актуальные для них вопросы.
В ходе работы с этим клиентом мы применяли и другие виды исследований UX. Подробнее можете прочитать в наших прошлых статьях. Например, о принципах UI/UX или о том, как подготовить UX-интервью.
А 11 декабря с 12:00 (по мск) приглашаем вас присоединиться к секции Analytics & Design на Big Stream. Наши эксперты расскажут, какой аналитик нужен сегодня в разработке и как собрать качественные требования в формате онлайн, как найти свой продукт (идеи, стратегии и методологии запуска), а также развенчают 7 мифов о работе веб-дизайнера и др. Приходите, будет интересно и полезно.