Вы настолько хорошо настроили сбор фидбека, что где-нибудь в облачном документе у вас теперь есть пара тысяч отзывов о продукте. UX Feedback рассказывает, как не впасть в прокрастинацию, а превратить их все в золотые инсайты.
Мы часто замечаем, что люди не понимают, как работать с фидбеком. Мы его собрали, категоризировали – а дальше? Прочитать и успокоиться? Испугаться и написать заявление по собственному желанию? Каждый дельный, на ваш взгляд, отзыв отправить в разработку?
На самом деле, вот, что важно понять в первую очередь: любой фидбек – это сигнал. Бесполезных отзывов не существует. Они всегда являются возможностью улучшить любой продукт. Но брать каждый комментарий и бежать исправлять всё в нём написанное, в большинстве случаев, – плохая затея.
И ещё кое-что. Кто должен работать с фидбеком? В нашем идеальном представлении – ресёрчер, потому что он, как кажется, ближе всего к пользователям: проводит исследования и общается с ними на их же языке. Но на самом деле фидбек может использовать любой сотрудник. Прекрасный пример этого PayPal, в котором около 9 тысяч человек так или иначе взаимодействуют с обратной связью от пользователей.
Вернёмся к нашей главной проблеме – ЧТО делать с фидбеком?
Этап 0. Самоопределение
Итак, допустим, вы собрали фидбек из трёх каналов: на сайте, в социальных сетях и из колл-центров. У вас тысяча отзывов. Вспомните, как долго в компаниях порой закрываются даже самые простые проблемы. Это время исчисляется днями и неделями, что, в принципе, не звучит так уж ужасно. А если проблем тысяча?.. Да и «горшочек» ведь не перестаёт варить – пользователи продолжают писать о том, что вызывает трудности (или даже недоумение) и мешает использовать продукт.
Поэтому фидбек вы обрабатываете и определяете ему категории – с ними работать определённо проще, а тысячи мелких проблем сужаются до десятка более глобальных. И вот она, эта страшная черта, за которой простирается неизвестность – дальше-то что?
А дальше нужно расставить приоритеты – расположить эти категории по степени важности:
- решение каких проблем ближе всего к деньгам
или - решение каких проблем приведёт к повышению лояльности (не секрет, что недовольный клиент может не только уйти к конкурентам, но и распространить негатив о компании среди друзей и родственников).
И начать исследование расследование. Представим себя детективами из нетфликсовских сериалов.
Этап 1. Место преступления
Мы получаем рапорт об убийстве – конверсия в покупку заколота ножом… Ладно, согласны, не будем перебарщивать с метафорами. Кажется, мы не настолько в них хороши.
Представим ситуацию: вы ресёрчер, у вас в команде есть несколько разработчиков и продуктовый дизайнер. Вы берёте категорию «Оформление заказа», поскольку там больше всего отзывов и она, очевидно, ближе всего к деньгам. И замечаете в одном из комментариев описание неприятного бага: «Добавляю товар в корзину, и там у него повышается цена». Сразу же шлёте его разработчикам, успокаиваетесь, а через пару часов получаете ответ: «Ну я задачу закрыл, как я найду, что за товар он имел в виду?». А компания уже потеряла как минимум одного клиента, который в неудомении ушёл искать более приятную цену. Сколько их ещё?!
Или, читая отзывы в категории «Кредитная заявка», видите всеобщее недовольство интерфейсом. А всем ли понятно, как прикреплять документы к анкете и где посмотреть полные условия кредита? Вы отправляете эти отзывы в сыром виде дизайнерам и только усугубляете ситуацию. Коллеги, получив из комментариев пользователей неполную картину, додумывают за ними и перерабатывают интерфейс по своему усмотрению. Как им кажется, они решили проблему.
А в результате оказывается, что в процентном соотношении количество недовольных пользователей не превышало даже статистическую погрешность, а с «додумываниями» новый интерфейс стал по-настоящему неудобным для большинства потенциальных клиентов.
Что случилось в обеих ситуациях? Да просто, как правило, не в компетенциях разработчиков или дизайнеров додумывать что-то за пользователями. Помните, нетфликсовский детектив здесь вы?
Разработчик должен починить конкретный баг с изменением цены, и ему нужна информация, что это был за товар, при каких условиях поменялась цена, с какого устройства и браузера произошла ошибка. Дизайнеру же должен понимать, какую конкретно проблему с интерфейсом ему нужно решить – почему он может быть неудобным большому числу пользователей (и вообще, действительно ли он неудобен).
Поэтому прежде, чем сваливать на голову коллегам ворох улик с места преступления, придётся провести на их основе собственное расследование.
Этап 2. Кофе и пончики
В большинстве своём люди по-разному выражают мысли о схожей проблеме. И это одна из основных причин, почему работать с каждым отдельным отзывом – плохая идея. Что значит: «Непонятный интерфейс»? Не видны какие-то элементы, нельзя перейти на какую-то страницу напрямую, не работают фильтры или поиск? В этом вам и предстоит разобраться. Выяснить, о чём этот отзыв, что пользователь имел в виду, что мотивировало его так написать.
Вооружившись связкой с инструментами веб-аналитики, пообщавшись с пользователями лично, мы должны сформировать полноценный отчёт о проблеме. И уже после этого передавать его в руки людей, которые её решат.
Вернёмся к нашим двум примерам. Как поступить в случае с багом? Нам нужно его воспроизвести. Для начала выяснить, что же за товар вызывает такую проблему. По Client ID в отзыве мы находим сессию пользователя в Google Analytics. Отчёт «Электронная торговля» позволяет посмотреть, какие конкретно товары были добавлены в корзину. После этого соберём список страниц, которые он посещал до этого.
Теперь посмотрим мета-данные из отзыва – на каких устройстве, OS, браузере произошла ошибка. Обладая всеми этими данными, мы уже можем воспроизвести баг в пользовательских условиях, а значит с большой вероятностью его отловить. И вот этот отчёт уже можно отправлять в разработку, им останется только починить поломку, ничего не додумывая за пользователями.
В случае с интерфейсом фронт работ схож. Нам нужно понять пользовательский путь, который привёл к недовольству. В этом помогает вебвизор Яндекс.Метрики, в котором можно просмотреть записи сессий всех пользователей, оставивших отзыв. Обладая этой информацией и мета-данными, вы сможете собственнолично пройтись по этому же пути и понять, что могло помешать респонденту.
Но учитывая специфику вебвизора и большой простор для гипотез, надо понимать, что такое воспроизведение проблемы намного сложнее примера с багом. Вам, возможно, придётся прочитать и свести воедино 10-20-30 отзывов, чтобы понять «узкие» места в интерфейсе. Или даже провести юзабилити-исследование и серии интервью с пользователями.
Но все эти усилия не пройдут даром. Получив от вас полноценное «расследование» с выводами и пожеланиями, дизайнер сможет улучшить продукт и сделать его действительно удобным для большинства пользователей.
Этап 3. Слава и почёт
Гора отзывов – не самое страшное, с чем вы столкнётесь на пути в мир пользовательского фидбека. По крайней мере, при грамотном подходе вскоре вы будете достаточно быстро его обрабатывать. Страшнее – непонимание и поспешные решения. Удобно ведь, когда вам на блюдечке «приносят» инсайты, можно сразу отдавать их в работу.
А то и хуже – если фидбек не понятен или решение проблемы кажется слишком сложным, его ведь можно просто пропустить мимо ушей…
По нашему опыту, любой фидбек является звонком о реальных проблемах. А решение любой из них – потенциал к росту прибыли и лояльности среди ваших клиентов.
Поэтому работать с ним жизненно необходимо. И даже самые непонятные, на первый взгляд, отзывы могут стать важными инсайтами для улучшения продукта. Надо лишь иногда сдувать пыль со своего детективного плаща.
