«Магнит» — это не только продукты съедобные, но и продукты цифровые: мобильные приложения, веб-сервисы. Команда пользовательского опыта старается делать их лучше: для этого есть исследователи, которые проводят исследования внутренних (для сотрудников) и внешних (для клиентов) продуктов, и CJE — эксперты по клиентскому опыту, которые строят карты клиентских путей на основе данных исследований и обратной связи.
Наша работа — находить и помогать решать проблемы пользователей. Но мы сами, в свою очередь, сталкиваемся с проблемами при выполнении этой задачи. Об этих проблемах и о том, как мы их решаем, расскажем в статье.
Как выглядит путь исследователя
Давайте пойдём по шагам. Сначала посмотрим, из каких шагов состоит путь, затем обсудим, какие проблемы появляются на каждом этапе и как мы их решаем.
Итак, путь исследователя состоит из следующих шагов:
Собираем обратную связь от пользователей, генерируем гипотезы.
С помощью исследований проверяем гипотезы, формируем список проблем.
Оцифровываем проблемы: понимаем, для какого количества пользователей они актуальны.
Передаём проблемы в бэклоги команд.
Помогаем проектировать решение.
Оцениваем решение.
А теперь перейдём к проблемам.
Проблема 1: Трудно быстро найти фидбек от пользователя по определённой фиче
Раньше у нас не было единой базы с обращениями клиентов из всех каналов: вместо этого — разрозненные отчеты, дашборды, UX-проблемы в отчётах поддержки были перемешаны с багами, операционными вопросами. Поэтому, например, если продакту нужно было узнать мнение пользователя о фиче, поиск информации занимал много времени.
Решение
Мы стали собирать обратную связь в AirTable. Берём цитаты из сторов, контактного центра, соцсетей, интервью, опросов, тегируем удобным способом, далее распределяем по командам и презентуем.
Теперь продакт, который хотел бы найти фидбек по фиче, может справиться с задачей меньше чем за минуту: он может сам найти обратную связь по любому продукту либо это по запросу быстро сделаем мы. Получается, что мы продолжаем держать руку на пульсе по всем вопросам, которые исходят от пользователя, и ребятам это помогает приоритизировать бэклоги.
Правда, тут есть особенность: тегирование — ручная монотонная работа. Аналитику и теги должен делать человек, глубоко погруженный в механики лояльности и фичи приложения: нужно быть в контексте вопроса, потому что пользователь может не знать, с чем именно столкнулся, в чём на самом деле проблема. Например, он ищет «соус», но поиск никак не находит кетчуп или майонез. Пользователь будет думать и жаловаться в отзывах, что у нас плохо работает поиск, но на самом деле он выбрал не тот формат магазина и ищет соусы в «Магнит Косметик», где их просто нет. То есть на самом деле проблема в том, что пользователю непонятно, какой формат магазина выбран.
Сейчас мы с поддержкой прорабатываем систему тегирования, чтобы можно было просматривать не все отзывы, а только те, которые касаются UX-проблем, — это должно облегчить нашу работу.
Проблема 2: Сложно рекрутировать клиентов
Вторая проблема возникает на этапе рекрута: сложно «достучаться» до респондентов. Люди не доверяют звонкам с незнакомых номеров, письмам с незнакомых адресов, игнорируют рассылки от компании.
Бывает так:
Решение
Держать контактный центр в курсе всех исследований. Люди обращаются в службу поддержки, чтобы уточнить, не мошенники ли с ними связались. Поэтому в контактном центре должны знать, какие исследования проводятся, кто может звонить или отправлять письма покупателям.
Сразу обзванивать пользователей по проблеме. Связываться нужно с теми пользователями, которые столкнулись с проблемой не более трёх дней назад. Дальше людям уже трудно понять, кто вы и что от них хотите.
Найти правильный скрипт для обзвонов. У нас была гипотеза: если подробно рассказать, что мы не мошенники и точно звоним из «Магнита», это внушит людям доверие. Гипотеза не оправдалась: люди вешали трубки, не дослушав до конца.
Лучшим вариантом оказалась самая короткая вводная: «Здравствуйте, меня зовут Мария, я звоню из Магнит Аптеки. Уделите пару минут?» Он давал наилучшую конверсию.
Проблема 3: Сложно рекрутировать сотрудников
Помимо клиентских, есть много внутренних продуктов: в них мы сталкиваемся со сложностями с рекрутом некоторых специальностей с высокой текучкой. Например, курьеров.
Часто эти люди не заинтересованы в том, чтобы участвовать в исследованиях. У нас есть стандартное вознаграждение: начисляем бонусы на карту «Магнит». Если человек с «Магнитом» ненадолго, у него может даже не быть этой карты. Соответственно, нам нечего ему предложить, он не очень заинтересован.
Решение
Проводить короткие исследования, не требующие сильного вовлечения со стороны респондента и большого количества времени. Это короткие опросы, постоянно закрепленные ссылки на форму обратной связи в рабочих чатах.
Опрашивать лояльных сотрудников: у нас есть чаты, в которых состоят «долгожители» — сотрудники, долго работающие с нами. Мы составляем опросы, публикуем в чатах — это помогает быстро проверять гипотезы.
А также проводим исследования на внешних респондентах, панельные интервью, рекрут сотрудников других компаний и так далее.
Проблема 4: Команда не доверяет результатам
Итак, мы успешно зарекрутили респондентов, провели исследование. Наступает время рассказать о результатах команде. К сожалению, бывает, что команда результатам не доверяет.
Так происходит, например, потому, что у членов команды не было похожего опыта, который мы принесли. Или ребята долго и упорно делают фичу, а пользователь ею недоволен: это фрустрирует. Некоторые могут делить пользователей на «хороших» и «плохих»: например, что одни пользуются продуктом правильно, другие — неправильно, и в этом кроется проблема.
Решение
Вовлекать команду на всех этапах. При составлении гайда исследования зовём команду на все встречи, интервью, юзабилити-тесты и так далее. Отрезвляюще работают иллюстрации в отчетах: матерные цитаты пользователей, нарезки из видео. Бывает, что команда помнит про проблему или исследование просто потому, что она запомнила очень колоритную цитату.
Давать метрики. Хорошо работают сравнения метрик после обновлений: обращения в КЦ, замеры CSI.
Обучать команды. Мы проводим митапы, воркшопы, User Days, когда вся команда, включая аналитиков, дизайнеров, разработчиков, выступает в роли исследователей и напрямую общается с реальными клиентами, знакомится с их потребностями и слушает обратную связь о продукте.
Проблема 5: сложно ориентироваться в проблемах большого продукта
Мы провели исследование, собрали огромное количество информации. Дальше надо её правильно обработать: у нас довольно большие, сложные продукты, в которых сложно ориентироваться и не терять информацию.
Участники команды обычно знают об особенностях механик своего продукта, при этом не знают, как функциональность работает у других команд. Поэтому, когда вносят изменения, могут что-то не учесть и плохо повлиять на участки, которые вне их зоны ответственности.
Был недавно такой кейс. Незадолго до доработки функциональности любимых категорий для PWA (Progressive Web Application, адаптации сайта в виде мобильного приложения) в программе лояльности появились любимые категории, которые действуют только для участников клубов — это отдельная механика. Широкого информирования не было, поэтому команда об этом не знала. Получилось так, что в PWA-версии можно было только выбрать категорию, а вступить в клуб — нет, из-за чего пользователь не получал бонусы за выбранную категорию. Но эту проблему быстро заметили и добавили задачу по решению в бэклог.
Решение
Строить CJM. У нас есть подробные карты для двух типов покупателей: покупатели офлайн-магазина и покупатели доставки. Также мы строим CJM сезонных акций. У нас очень сложные механики и большое количество каналов взаимодействия, за которые отвечают разные команды, — их нужно синхронизировать. Если не прорабатывать CJM, все запутаются: и мы, и пользователи.
Мы описываем путь, который происходит с пользователем. Разбиваем его на крупные этапы, внутри описываем шаги покупателя: в каких каналах есть точки контакта с пользователем, какие задачи и ожидания у него могут быть в этих точках и какой опыт он в итоге получает — что хорошо и удобно, а где сталкивается с проблемами. Сюда же выносим скриншоты экранов приложения или фотографии того, что есть в офлайне.
Получается большая карта. Минусы очевидны: она сложная, поначалу в ней трудно ориентироваться. Поэтому нужно вовлекать команды, чтобы они знали этот инструмент и умели с ним работать.
Проблема 5: Проблему не будут решать без количественных данных
Следующий этап — оцифровка проблем. Когда мы приносим проблемы командам, они увлечённо слушают, кивают. Но верят только количественным данным: без них не будут приоритизировать проблемы.
Чтобы получить количественные данные по гипотезе у аналитиков, нужно доказать, что задача действительно важная и стоит тратить на неё время. Дело в том, что ресурс аналитиков ограничен и бэклог забит достаточно сильно, поэтому встать с задачей бывает непросто. Приходится долго ждать, пока запрос возьмут в работу. Поэтому, когда нужно получить хоть какую-то количественную оценку быстрее, мы ищем альтернативные способы.
Решение
Сами проводим все возможные количественные исследования. Если провести такое исследование нет времени и возможности, есть «костыльное» решение: мы смотрим на количество исследований, в котором встречали эту проблему, и говорим, что она регулярно повторяется.
Есть ещё два других жизнеспособных решения: подсчет комментариев в нашей базе AirTable и анализ количества обращений в контактный центр.
Проблема 6: Сложно понять, кто должен решать проблему
Следующий этап после оцифровки проблем — передать их в бэклоги команд. У нас большой и сложный продукт, много команд. Есть проблемы, которые находятся на стыке зон ответственности, попадают между этими зонами или лежат вообще за периметром продукта. Также могут быть конфликты между командами в понимании того, чья это проблема, потому что решать проблему можно разными способами. В зависимости от решения это должна будет делать одна или другая команда.
Решение
Регулярные синки с продактами. В нашем пространстве Miro есть таблички, которые представляют собой аналог канбан-доски с задачами: мы перемещаем задачу в соответствии с её статусом. Для этого мы регулярно проводим синки с продактами.
В команды прилетает много задач от бизнеса, и не все они помогают решать пользовательские проблемы. Мы транслируем голос клиента команде, подсвечиваем наиболее критичные проблемы, которые важно взять в работу. Помогаем реализовывать инициативы так, чтобы они решали задачи бизнеса и отвечали потребностям пользователя.
Проблема 7: Нет времени тестировать решения
Проблему в бэклоги команд передали — теперь нужно помочь спроектировать решение. Основная проблема заключается в том, что нет времени это решение протестировать: результаты нужны ещё вчера, разработка на низком старте, у исследователей другие задачи в работе.
Решение
Чаты с лояльными пользователями для быстрой проверки гипотез. Это, конечно, не большое полноценное исследование, но быстро проверить что-то вполне можно.
Обучение команды. Нашим дизайнерам нравится проводить коридорные исследования. Мы составили для них большой гайд и помогаем на всех этапах — от рекрута до анализа результатов. Это снимает часть нагрузки с исследователя и вовлекает команду в процесс, помогает ей встать на место пользователя, погрузиться в контекст.
Конечно, бывает такое, что фича или процесс выкатились в прод, не будучи протестированными никем из исследователей. Тогда приходится проверять их силами наших экспертов либо проводить тестирование уже на проде и передавать обратную связь командам.
Проблема 8: Непонятно, как влияют изменения на поведение пользователей
Завершающий этап: узнать, как пользователи реагируют на изменения. Плюс это важно для стейкхолдеров: им не всегда очевидно, зачем тратиться на улучшения, когда здесь и сейчас они не приносят денег.
Решение
Регулярно замеряем NPS и CSI. Это даёт возможность мониторить, как на пользователей влияют изменения, которые мы проводим. Как они относятся к отдельным фичам и продукту в целом. Если метрики резко падают, это повод бить тревогу и смотреть, почему это происходит.
Если растут — значит мы движемся в верном направлении, опыт пользователя становится лучше, а, как мы знаем, улучшая опыт, компания в итоге зарабатывает больше, потому что лояльные пользователи тратят больше.
Ищем корреляции между UX и бизнес-метриками. Ежеквартально отслеживаем эту связь: например, удовлетворённые пользователи чаще ходят в магазины, их средний чек выше, они чаще заходят в приложение.
Что всё это даёт
Мы, как исследователи, понимаем зону роста компании с точки зрения UX. Передаём бизнесу и продукту клиентские проблемы, решение которых может помочь пользователям стать счастливее, а компании, соответственно, больше зарабатывать. Поэтому от инвестиций в исследования выигрывает как пользователь, так и компания.
