От хаоса к порядку: как в UX-исследованиях Авито организовали системную работу с фидбеком пользователей
Привет! Я Юлия Шефтелевич, UX-исследователь в Авито Авто. Чтобы улучшать опыт покупателей, наши команды постоянно собирают обратную связь от пользователей из разных источников: обращений в службу поддержки, отзывов в магазинах приложений, результатов UX-исследований.
Раньше у нас не было единого хранилища для всех пользовательских цитат, поэтому команды обрабатывали обращения хаотично. Но мы придумали решение — в статье расскажу, как мы организовали единое хранилище пользовательского фидбэка в Jira за 5 шагов.
Увидели, что есть проблема с хранением и обработкой обратной связи от пользователей
В Авито Авто мы собираем и обрабатываем всё, что пользователи пишут о сценариях покупки и продажи автомобилей на Авито. В каждой команде есть человек, который собирает цитаты в одном месте, чтобы потом обрабатывать их и смотреть, что взять в работу. Таких каналов у нас 6:
🙋 Обращения в поддержку от продавцов и покупателей.
🙋 Отзывы в магазинах приложений.
🙋 Отзывы в рамках программы Eat your dog food. Всем новым сотрудникам предлагаем продать или купить что-то на Авито, а потом поделиться опытом и написать, что можно улучшить. В нашем случае изучаем всё, что связано с автомобилями.
🙋 Частотные запросы из ежемесячных замеров удовлетворённости пользователей CSAT и CES. Читаем все комментарии, разбиваем частотные запросы на кластеры, и смотрим, что сильнее всего снижает оценку пользователей. Повторяющиеся комментарии берём на дополнительное изучение.
🙋 Контекстные опросы и маркетинговые исследования, например, о бренде Авито и конкурентном окружении.
🙋 Инсайты из UX-исследований.
Раньше продакт-менеджеры из моей команды хранили обратную связь из всех этих источников по-своему: кто-то вёл таблицу в Excel, кто-то визуализировал сигналы в Miro, кто-то использовал Notion и придумывал там свою систему тегов.
Это приводило к проблемам:
❌ Файлов Excel, Miro и Notion становилось много, из-за этого было сложно находить нужную информацию.
❌ Коллеги из разных отделов не знали о существовании хранилищ друг друга. Это могло привести к тому, что одни и те же пользовательские сигналы попадали в разные таблицы и получали разных ответственных.
❌ Владельцы файлов не всегда актуализировали статусы по проработке сигналов, а это удлиняло процесс.
❌ Данные могли теряться, когда сотрудники увольнялись или переходили в другие команды внутри Авито.
Чтобы упростить работу с задачами и систематизировать хранение пользовательского фидбэка, мы решили свести всё в общий сервис.
Стали искать подходящие инструменты. Выбирали между Airtable, Confluence и Jira
Не стали работать в Airtable. В Авито им никто не пользуется, и нам пришлось бы учить каждого менеджера, как работать с этим инструментом. На это уйдёт много времени. К тому же пространство в Airtable платное, и пришлось бы дополнительно оплачивать всем доступы.
Confluence тоже не подошёл. Это пространство мы в Авито используем как базу знаний. В Confluence у нас хранятся, например, результаты аналитических, маркетинговых и UX-исследований.
Но у платформы есть минус — здесь неудобно отслеживать статус задач и ответственных. Поэтому мы стали искать дальше.
Остановились на Jira. Наши продуктовые команды уже ведут задачи в этом таск-трекере, поэтому все сотрудники умели им пользоваться.
Расскажу, как за 5 шагов мы организовали работу в Jira, чтобы всем было удобно.
1. Написали интрукцию, как заводить тикеты, и подготовили шаблон
Мы хотели сделать тикеты понятными для любого сотрудника, который заходит в наш бэклог: менеджера, исследователя, сотрудника поддержки и других. Поэтому написали инструкцию, по которой нужно заполнять тикет для новых задач.
В тикете мы кратко обозначаем суть проблемы, её предположительные причины, и добавляем цитаты из разных источников. Прямая речь пользователей помогает лучше погрузиться в суть ситуации и понять, в чём боль или пожелание человека.
2. Придумали эпики и теги для быстрой навигации по задачам
Структуру нашего тикета мы дополнили эпиками. Они соответствуют этапам пользовательского сценария — к примеру, «Этап общения с продавцом».
Помимо эпиков, ориентироваться в структуре помогают Теги. Они подсказывают, к какой категории транспорта и элементу интерфейса относится запрос. Любой продакт-менеджер может отфильтровать обращения по тегам и найти то, что относится к его зоне ответственности в продукте.
3. Ввели статусы задач
Одно из главных преимуществ Jira для нас — возможность отслеживать статус задачи. Ничего нового мы изобретать не стали и ввели статусы, которые используем во всех командных задачах: «Бэклог», «В работе», «Сделано» или «Не будем это делать».
Сначала новые тикеты заводила только я, а теперь мне помогает менеджер. Он вносит в Jira обращения из службы поддержки и тем самым разгружает меня.
4. Создали свою систему оценки критичности обращений
Чтобы оценить критичность запроса, мы смотрим, как часто люди жалуются на проблему, как сильно она мешает проходить сценарии в продукте. А также считаем все каналы, из которых получили подобный запрос.
Например, если мы многократно слышали о проблеме на пользовательских интервью, то ставим 3 балла. Если тот же запрос приходил от людей, когда мы проводили опросы — добавляем ещё 7 баллов. Потом суммируем баллы и получаем общую сумму критичности. Максимальная оценка — 10 баллов.
5. Организовали ежемесячные встречи для обсуждения задач
На встречах мы с продакт-менеджерами и коллегами из поддержки обсуждаем, какие сигналы поступили за месяц. Думаем об их причинах и планируем дальнейшие шаги.
Ещё одна важная функция встречи — закрепить за обращением ответственного менеджера. Благодаря этому задачи не остаются без внимания, а процесс работы становится прозрачнее — исследователю проще разобраться, сколько задач уже закрыли, а сколько запросов пока в работе.
Продакт-менеджеры регулярно проверяют статусы и следят за исполнением задач. А ещё добавляют к ним наблюдателей, так что менеджеры со смежными зонами ответственности остаются в курсе того, что делают коллеги.
Еще раз кратко: как мы организовали бэклог задач в Jira
👉 Придумали шаблон для всех типов пользовательского фидбэка. Так что сотрудникам не нужно каждый раз думать, как описать задачу, что упомянуть, а что не стоит. Все обращения выглядят одинаково и в них удобно ориентироваться.
👉 Ввели систему тегов и эпиков: они помогают быстро понять, к какой части продукта относится проблема и на каком этапе пользовательского пути она возникла.
👉 Добавили статусы, чтобы понимать, что происходит с запросом.
👉 Разработали систему для оценки критичности заявок.
👉 Организовали ежемесячные встречи, чтобы отслеживать статус текущих задач, обсуждать сигналы, которые поступили за месяц, и планировать работу.