«Мы собирали фидбэк, делали как они просили, а они всё равно недовольны». Знакомо?

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

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

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

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

«Хотелки» и реальные нужды — в чём разница

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

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

Это и есть ключевая ошибка. Пользователь почти всегда формулирует не саму нужду, а своё представление о том, как её нужно закрыть. И если команда начинает буквально выполнять такие запросы, она очень быстро погружается в хаос. Ведь «хотелки» у разных пользователей отличаются и легко конфликтуют друг с другом, а вот реальные нужды за ними часто повторяются.

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

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

Другой пример из нашей практики. Клиент попросил, чтобы любой клик по смайлику-оценке в нашем инструментарии сразу отправлялся в личный кабинет. Тогда оставить оценку без текста было нельзя, а клиент хотел получить максимум оценок. Но пользователи часто выбирают смайлик не с первого раза: нажимают на несколько вариантов подряд. Это могло исказить статистику.

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

Как проверить, действительно ли есть нужда

Допустим, вы провели качественное исследование и выяснили (как вы думаете), что именно необходимо пользователям. Но вдруг появилось сомнение: «А действительно ли это нужно клиентам? Правильно ли мы их поняли?»

Чтобы не гадать, нужно проверять. Взять ту нужду, которую вы выделили из проведённого исследования, и заглянуть немного глубже в неё.

Однажды Netflix спросил пользователей, о чём они хотели бы узнать, прежде чем оформить подписку. В результате 46% юзеров ответили, что хотели бы ознакомиться со всеми доступными фильмами и телешоу. Команда Netflix предположила, что пользователи нуждаются в каталоге на главной странице. И что он значительно повысит шансы на подписку.

Тогда Netflix создал несколько прототипов обновлённой главной страницы и начал их тестировать. В процессе обнаружилось, что посетители сайта в основном находились в режиме полной «шоппинговой» готовности. Большинство людей искали конкретный контент и были готовы сразу же подписаться, если Netflix мог его предложить.

Оказалось, что подробный каталог пользователям на самом деле не был нужен. Они заходили на сайт, уже имея представление о том, что хотят посмотреть. Дальнейшие A/B-тесты подтвердили это, поэтому Netflix не стал внедрять каталог.

Этот пример хорошо показывает важную вещь: даже если команда, кажется, правильно услышала пользователя, это ещё не значит, что первое очевидное решение и правда будет лучшим.

Курс от «хотелок» к нуждам

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

Навигация

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

Скорость

А здесь у пользователя не получается оформить экспресс-доставку, но главный фокус не в ней. В комментарии даже есть подсказка, что с сайтом в целом всё время происходит что-то неладное. Нужда здесь — скорость. Всё должно работать очень быстро: от сайта до доставки. Время — вот самый ценный ресурс. И те люди, которым необходим «экспресс» ― особый тип клиентов. Они готовы простить многое, но не проблемы со скоростью.

Фильтрация

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

А вот ещё один пример комментария о проблемах с навигацией:

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

А вот как это правильно сделать — добавить кнопку или что-то ещё — это второй вопрос. Его уже нужно прорабатывать совместно с UX-дизайнерами.

Прозрачность статусов и действий

Автор этого отзыва, по всей видимости, потерялся в огромном количестве информации на сайте. Причём, довольно бесполезной, на его взгляд. Еще и «красивости» эти. Пользователю нужна прозрачность, чтобы было понятно, что происходит с заказом, со статусом, с оплатой и так далее.

Процесс выбора

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

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

Заключение

Работа с VoC не про то, чтобы делать всё, что просят пользователи. Если команда буквально исполняет каждую «хотелку», она почти неизбежно начинает лечить симптомы вместо причин.

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

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

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

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

Подписаться