Хороший дизайн не заканчивается в Figma: как я создал свой продукт, чтобы слышать пользователей

StandApp – продуктовая дизайн-студия. Мы не делаем креативный дизайн, а отвечаем за UX/UI клиентских продуктов – это наша сильная сторона. Проектируем, сопровождаем разработку вместе с инхаус-командой клиента, ведем продукты на поддержке.

С 2019 года мы углубились в исследования. Начали с дизайн-спринтов: собирали кликабельные прототипы и тестировали их на людях из нужного сегмента. Это очень полезный слой данных: можно проверить идею до начала большой разработки, а клиент своими глазами видит, как живой человек не находит кнопку на «самом очевидном месте». Потом добавились другие методы: CJM, интервью, опросы с рассылкой по базе, большие рыночные исследования для «Самоката» и «Мегамаркета» в 2023-м.

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

Почти каждый раз, после внедрения или редизайна новых фич, разделов или запуска полноценных продуктов.

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

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

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

Делаем и знаем их ограничения.

Первое – это долго и дорого. Респондентов нужно специально искать, отобрать по сегменту, договориться, собрать сценарий, кликабельный прототип, провести, расшифровать. Недели. Даже с AI.

Второе – нужно заранее понимать, что спрашивать. То есть у тебя уже должна быть гипотеза. А если ты не знаешь, ты не знаешь и что спрашивать.

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

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

В 2024-м я как раз этим и занимался: перебирал зарубежные и российские Voice of the Customer (VoC) сервисы. Есть много классных решений, но у всех контур обрывается в одном месте: клиенту собирают фидбэк и строят дашборды – и на этом все.

На стороне сервиса может быть даже персональный менеджер, который помогает настроить опросы и дает советы: должность называется – менеджер по клиентскому успеху (customer success manager). Успех, правда, заканчивается на дашборде: клиент остается с данными на руках и вопросом «что чинить и кто будет это делать?».

Тогда я и решил достроить контур. Схема получилась такая:

Круг замкнулся. Мы даем полный сервис по UX + продукт для работы с пользовательским фидбэком.

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

В 2024 я спроектировал и выделил MVP. Для разработки привлек компанию-партнера. Сейчас у нас уже свой разработчик в команде.

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

К сентябрю 2025 года запустилась первая версия Bravo Feedback.

Был конструктор с 2 типами микро-опросов, виджет показывался на сайте в одном углу экрана – ноль кастомизации и дашборд, где собирались ответы и комментарии из варианта «другое».

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

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

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

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

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

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

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

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

Есть два варианта входа:

Дальше – подписка, если нужно наладить постоянную работу с фидбэком.

Неспешно, но планируем развивать и самостоятельный вариант: подключаете виджет сами – строкой кода или через Tag Manager и сами собираете опросы в конструкторе. Это дешевле, но и вопросы вы формулируете сами: в управляемом варианте мы как раз за это и отвечаем – что спросить, где показать и что потом делать с ответами.

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

Второе: не подгоняйте продукт под чужой фреймворк ради скорости. Мы так сэкономили на старте и заплатили переписыванием.

Третье: обкатайте на себе. Три месяца на собственном сайте – это не потерянное время, а уверенность перед первым клиентом.

Продукт сейчас – bravofeedback.ru. Если занимаетесь поддержкой ecom или работаете инхаус в b2c-продукте и упираетесь в те же грабли, пишите в telegram @stndpp, поделюсь деталями.