Почему инструмент для сбора фидбэка сам по себе не решает проблему

Когда понимать пользователей становится сложнее, кажется вполне логичным просто начать собирать больше фидбэка. И тогда команды приходят к мысли: «Нам нужен инструмент для сбора обратной связи».

И в этом действительно есть здравый смысл.

Однако инструмент сам по себе ничего не решает. Он помогает собрать данные, но не отвечает за то, как команды будут их интерпретировать и какие решения на их основе будут принимать.

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

Больше фидбэка ➡️ ещё больше вопросов

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

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

• Комментарии могут противоречить друг другу;
• Разные пользователи фокусируются на разном;
• Приоритеты для продуктовых решений не всегда очевидны.

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

Фидбэк при этом остаётся скорее дополнительным слоем информации, а не частью процесса принятия решений.

Кейс: сотни комментариев и несколько повторяющихся проблем

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

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

И это сильно упростило дальнейшую работу с продуктом.

«У нас часто на встречи приходят кросс-команды с какими-то гипотезами. Теперь у нас появился оперативный способ помочь другим командам принять более взвешенное, оцифрованное решение»

— Олег Литовченко, руководитель отдела UX-lab в ПИК

Где ломается логика работы с фидбэком

Почти в каждой команде в какой-то момент возникает мысль: «Давайте просто начнём собирать фидбэк — и дальше станет понятнее». И это абсолютно нормальное ожидание.

Правда в том, что сам по себе фидбэк редко делает картину яснее. Он начинает помогать только тогда, когда у него есть опора — конкретный вопрос, на который вы пытаетесь ответить.

Например:

• Почему падает конверсия?
• На каком шаге пользователи теряются?
• Что мешает им дойти до ключевого действия?

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

Кейс: как понимание приходит за недели, а не за месяцы

У команды сети аптек «36,6» была довольно типичная ситуация: аналитика показывала наличие проблемы, но не объясняла, где именно она возникает и почему.

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

И дальше всё стало проще:

• Уже в первые недели команда выявила повторяющиеся паттерны;
• Стало понятно, на каком этапе сценария пользователи чаще всего сталкиваются с трудностями (например, при оплате);
• Вместо разрозненных сигналов команда смогла использовать выявленные паттерны для принятия решений.

Фидбэк при этом не стал «объёмнее». Он стал понятнее — и поэтому начал реально помогать в принятии решений.

«Буквально за один день я понял 90% проблем пользователей. Увидел огромное количество их «болей», но это даже обрадовало, потому что в этом и есть точки роста»

— Адам Машитлов, руководитель диджитал-маркетинга и аналитики в «36,6»

Инструмент — только часть истории

Инструмент действительно нужен — он помогает собирать сигналы. Но сам по себе он решает только эту задачу.

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

Если эта цепочка не выстроена, данные остаются просто данными. Их можно читать, обсуждать, даже анализировать, но на продукт они почти не влияют.

Кейс: когда фидбэк есть, а движения нет

Команда крупного девелопера ГК «Талан» собрала большой объём отзывов: фидбэк был, сигналы — тоже.

Но дальше начинались сложности:

• Было непонятно, какие из сигналов важнее;
• Разные люди по-разному интерпретировали одни и те же комментарии;
• Не было ясной связи между фидбэком и тем, что нужно менять в продукте.

В итоге обсуждений было много, а решений — заметно меньше.

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

В результате фидбэк перестал «зависать» на уровне обсуждений — он начал регулярно доходить до продуктовых решений.

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

— Илья Мубараков, диджитал-маркетолог в ГК «Талан»

Кстати, именно этот момент — переход от стадии «есть данные» к «есть решения» — мы подробно разбирали в вебинаре. Обсуждали, как устроена эта цепочка на практике, где она чаще всего ломается и как её выстроить без перегрузки команды.
→ Запись вебинара о связи фидбэка и решений

«Нет ресурса» — это не всегда про время

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

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

Например:

• Упала конверсия → чиним;
• Есть критичный баг → фиксим;
• Проседает ключевой сценарий → улучшаем.

И дальше связка получается прямая и прозрачная: сделали → получили результат. Под такие задачи почти всегда находится и время, и внимание.

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

Фидбэк перестаёт быть «чем-то дополнительным» и становится инструментом решения конкретных задач.

Кнопка или форма фидбэка — ещё не система

Идея кнопок и форм очень проста и логична: добавить их — и пользователи начнут делиться обратной связью. Но на практике всё работает чуть иначе.

Люди редко пишут просто так. Обычно это происходит в конкретный момент, когда:

• Что-то не получилось;
• Стало неудобно или непонятно;
• Опыт оказался неожиданно хорошим.

А если спросить человека не вовремя, можно получить негатив. В своей статье CEO UX Feedback Женя Прокофьев как раз разбирает этот момент. Поп-апы часто раздражают не сами по себе, а потому что появляются вне контекста и мешают текущему действию пользователя. В итоге человек реагирует не сам опрос или продукт, а на прерывание своего процесса — и это искажает сам сигнал.

Поэтому сама по себе кнопка или поп-ап — просто инструмент и возможность. Канал, который может сработать, а может и нет.

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

Как отличить систему работы с фидбэком от его сбора

Очень часто команды находятся где-то посередине: работают с фидбэком, но ощущают, что он недостаточно эффективен. При этом часто бывает сложно понять, что именно не складывается в систему.

Чтобы быстрее сориентироваться, посмотрите на ключевые различия:

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

И именно в этом месте обратная связь пользователей начинает реально влиять на продукт.

Заключение

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

И в этот момент легко перепутать направление: начать искать решение раньше, чем сформулирован запрос.

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

• Какие вопросы вы хотите решить;
• В какой точке появляется сигнал;
• Как он превращается в действие;
• Кто за это отвечает.

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

Материалы

→ Гайд «Почему подход 
к фидбэку важнее инструмента»;

→ Реальные кейсы наших клиентов;

→ Бесплатные книги и записи вебинаров.

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

Пишем о кейсах, подходах и разборах от наших экспертов. А ещё там живёт невероятно милый Котофей 🐾

Подписаться

Частые вопросы о сборе обратной связи и системах фидбэка