Девять лет я объяснял клиентам, почему пользователю так будет удобнее. Надо было просто спросить

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

Я проектирую и веду на дизайн-поддержке SaaS-сервисы и интернет-магазины с 2016 года. И постоянно вижу одно и то же: команда вкладывает деньги в обновление продукта или отдельного функционала, выкатывает его – и ничего не меняется. Или где-то становится лучше, а где-то хуже. Или просто черный ящик, в котором никто не знает, какой результат получили. Причем чаще всего дело не в дизайне и не во внедрении. Дело в том, что чинили не то место и попутно сломали то, что работало.

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

Ошибка 1. Считать, что аналитика отвечает на вопрос «почему»

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

Проблема в том, что это все мнения команды.

• Количественные данные отвечают на вопрос где. 

• Вебвизор и записи сессий отвечают на вопрос как – вы увидите, что человек трижды вернулся к блоку доставки и закрыл вкладку. 

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

У студий и агентств эта слепота особенно заметна на поддержке ecom-сайтов. Мы проектируем, отдаем макеты, разработчики внедряют – и дальше черный ящик. Не понятно, что сработало, а что нет. И, что важнее, неизвестно, где проблем вообще не было и трогать не следовало.

Что делать. Развести уровни данных и не требовать от каждого из них невозможного. Аналитика ищет место. Записи сессий показывают поведение. Причину дает только сам пользователь – и ее нужно спрашивать отдельным инструментом, а не выводить логически из графика.

Ошибка 2. Спрашивать пользователя, когда он уже вышел из контекста

Хорошо, скажет команда, спросим пользователей – ведь мы читали книгу «Спроси маму» (Роб Фитцпатрик). И запускает интервью через две недели после покупки или отправляет NPS-опрос на почту.

В чем тут проблема? Человек оценивает опыт не по среднему, а по самому яркому моменту и по концовке (правило пикового конца). Все остальное забывается. А конверсию убивают как раз мелкие проблемы по всему пути.

Дальше происходит худшее. Человек, вырванный из контекста, уже не помнит, где и почему ему было неудобно на сайте, – но вопрос-то ему задали, и он вежливо, охотно и подробно начинает сочинять. На выходе – красивая расшифровка, в которой нет правды.

Это не значит, что юзабилити-тесты не нужны. Мы проводим их с 2019 года внутри дизайн-спринтов, и они отвечают на свой вопрос – как человек проходит сценарий, который вы еще только проектируете. Просто инструмент дорогой и медленный: найти респондентов нужного сегмента, собрать сценарий, провести, расшифровать – недели работы и заметный бюджет. Живой сайт, на котором магазин прямо сейчас теряет заказы, ими не покроешь.

Что делать. Спрашивать пользователя в моменте взаимодействия с сайтом: в каталоге, на карточке, в корзине. Один короткий вопрос, пока человек еще внутри задачи и все помнит. Это и есть методология Voice of Customer – не «вспомните ваш последний заказ», а «что мешает оформить заказ?».

Ошибка 3. Защищать решения экспертным мнением

Любая студия или агентство предложит свой экспертный аудит. Мы тоже, и у вас наверняка аудиты тоже сильные. Но аудит, не подкрепленный слоем данных – это просто мнение.

И дальше начинается знакомое. Вы приносите решение на основе аудита, а вам отвечают: «мне кажется, кнопка тут теряется». Возразить нечем: у вас экспертиза, у клиента ощущение и он прав. Внутри продуктовой команды все то же самое, только вместо клиента – продакт.

Можно усилить ваше мнение «UX-законами». Но они будут работать как объяснение механики, а не как доказательство проблемы. Закон Хика объяснит, почему 12 равнозначных категорий на главной замедляют выбор. Эвристики Нильсена подскажут, где интерфейс нарушает ожидания. Но они не скажут, что именно ломается у ваших пользователей на вашем сайте.

Что делать. Ставить данные проекта в первый приоритет, а принципы – во второй, как усиление.

Ошибка 4. Не знать, что трогать не нужно

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

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

Клиент платит за то, чтобы стало хуже там, где было нормально

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

Что делать. Замерять усилие точечно, на каждом ключевом действии. Например: «Насколько легко вам было оформить заказ?» (метрика Customer Effort Score). Ценность здесь не в одной цифре, а в сравнении между точками: когда четыре из пяти дают хороший результат, а пятая проваливается, спорить уже не о чем. Вы знаете, что менять.

Ошибка 5. Собрать обратную связь и остановиться на этом

Самая обидная из пяти: компания сделала почти все правильно и встала на последнем шаге.

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

Данные уезжают в стол: красивые графики, за которыми ничего не меняется.

Тут я, конечно, пишу как лицо заинтересованное: этот контур мы и достроили своим продуктом – UX/UI-доработки и есть основная работа студии. Так цикл замкнулся: собрали фидбэк – починили.

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

Кто именно вносит правки – вопрос второй. У продуктовой команды со своим дизайном и исследованиями для этого все есть: контур замыкается внутри, им нужен только инструмент. Там, где такой команды нет, шаг должен взять на себя кто-то еще. Плохо не то, что его берет кто-то извне, – плохо, когда его вообще никто не берет.

Как обратная связь становится частью продукта

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

В 2025-м я спроектировал продукт и выделил MVP. Собирали втроем: я как фаундер, наш штатный UX/UI-дизайнер и компания-партнер на разработке. Сейчас у нас уже свой разработчик в команде.

Первый прототип посадили на готовый фреймворк на Django/Python и под него же делали интерфейсы. Это была ошибка. Мы подстраивались под чужие ограничения вместо того, чтобы делать так, как правильно. Потом переписали и от этой связки, слава богу, отказались.

К сентябрю 2025 года запустилась первая версия Bravo Feedback. Версия была не просто MVP, а микро-MVP: например, если один опрос стоял на трех карточках товара, нельзя было понять, с какой именно пришел ответ, и не сохранялось время ответа. Поэтому три месяца мы обкатывали ее на собственном сайте, вносили правки и никому не показывали.

Первый клиентский запуск случился с ecom-брендом канцелярии для продуктивности. Конверсия в ответ в корзине оказалась 11,3% (показы: 2 065, ответы: 233). Тот самый виджет, который, как я был уверен, все закрывают не глядя. 

Вот что отвечали пользователи:

«Кнопка доставки не нажимается, в итоге поле ПВЗ не работает»

«Быстрое удаление из корзины – долго удаляет»

«Хотелось бы заказывать частями из корзины. Не нашла как»

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

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

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

Что это дает вам, если вы в агентстве – это возможность приходить к клиенту не просто с аудитом, а с аудитом, за которым стоят слова его же пользователей. Такой аудит не обсуждают в стиле «нравится / не нравится» – рекомендации опираются на данные, а не на вкус. После внедрения ту же точку можно измерить повторно. 

Что это дает вам, если вы работаете внутри продукта – это способ приносить на встречу не «мне кажется, что форма длинная», а двадцать цитат людей, которые на этой форме встали.