Инсайты от клиентов: как правильно проводить кастдев

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

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

Взаимодействие с заказчиком

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

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

Мы выстраиваем партнерские отношения, основанные на признании того, что:

• у клиента есть глубокая экспертиза в его бизнесе;
• у нас — системная экспертиза в создании IT‑продуктов внутри отрасли клиента.

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

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

Как это работает, покажем на примере интернет‑магазинадля сети строительных гипермаркетов Строй‑С. Вместе с клиентом мы обратили внимание (по данным из открытых источников и на основе его наблюдений), что в DIY‑сегменте людям важнее всего: цена, ассортимент и удобные варианты доставки. То есть всё, что связано с простым и понятным получением товара.

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

Затем мы берём эти идеи и дорабатываем их: предлагаем варианты реализации, добавляем свои инициативы и обсуждаем это вместе. Часто получается так, что и мы, и клиент приходим с похожими идеями — просто в разной форме. Тогда мы объединяем усилия и ищем наилучшее решение вместе.

Возвращаясь к кейсу из сферы DIY: в какой‑то момент — и по нашим данным, и по информации от клиента — мы зафиксировали ключевую идею: значительная часть выручки в DIY‑сегменте формируется за счет B2B‑клиентов.

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

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

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

• привлекать клиентов на свои услуги;
• как можно быстрее сдавать объекты, чтобы быстрее получать оплату;
• иметь доступ к широкому ассортименту;
• организовать быструю и удобную доставку на площадку;
• и, что особенно важно, иметь возможность дополнительно зарабатывать на том, что они рекомендуют клиентам определенные магазины.

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

Мы выявили потребности B2B‑аудитории. Затем совместили их с потребностями обычных пользователей — тех, кто заказывает ремонт, строительство или покупает строительные и отделочные материалы.

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

С другой стороны, потенциальные партнёры (специалисты, подрядчики, дизайнеры и т.д.) тоже заинтересованы — им нужны клиенты на свои услуги.

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

Механика двусторонняя:

• пользователи могут сами связываться со специалистами, предлагать им задачи;
• специалисты могут просматривать заявки и откликаться на них, предлагая свои услуги.

Таким образом, на сайте появилась своеобразная биржа специалистов (похожая, по сути, на Профи.ру, но в узкоспециализированном варианте, встроенная в экосистему клиента).

Кастдевы

Кастдевы — это качественные исследования потребностей целевой аудитории. Не количественные, а именно качественные.

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

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

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

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

Проблемное интервью как раз нужно для того, чтобы понять:

1. Есть ли у пользователей эти проблемы на самом деле?
2. Как они с ними сейчас справляются?
3. Чем их устраивает текущий способ решения, а чем не устраивает?

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

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

Мы задаём пользователям вопросы:

1. Как вы обычно получаете этот товар?
2. Устраивает ли вас текущий процесс?
3. Как бы вы хотели, чтобы это работало?

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

В проблемном интервью нельзя задавать наводящие вопросы. На примере предыдущего кейса — нельзя спрашивать у клиента магазина из сферы DIY: «А хотели бы вы, чтобы товар приезжал день в день?». Такой вопрос искажает картину: пользователь может автоматически ответить «да», даже если это не его реальная потребность. Он просто соглашается с озвученным предложением, а не говорит о своей боли.

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

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

Следующий шаг — это решенческое интервью.

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

На этом этапе мы приглашаем пользователей, рассказываем им о нашем решении (часто показываем прототип или макет) и задаём вопросы:

1. Насколько удобным и понятным им кажется предложенный подход?
2. Решает ли он ту самую проблему, которую мы обсуждали ранее?
3. Хотели бы они пользоваться таким решением?

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

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

Возвращаясь к кейсу Строй‑С: на проблемном интервью мы выяснили, что B2B‑специалисты (например, монтажники) хотят иметь возможность предоставить клиентам скидку, чтобы повысить их лояльность. Но при этом они хотят и что‑то зарабатывать с заказов, которые сами же привели в интернет‑магазин.

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

• из 5% скидки 2% пойдет клиенту;
• а 3% вернётся специалисту в виде бонусов.

Мы показываем, как это работает, и спрашиваем, действительно ли это закрывает их задачу, и есть ли что‑то, чего не хватает?

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

Чем отличаются подходы к кастдевам в зависимости от контекста

В ситуации запуска с нуля обычно используется классическая последовательность:

• проблемное интервью;
• решенческое интервью;
• формирование и проверка гипотез пользовательских проблем;
• генерация и валидация вариантов решений.

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

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

Разберём на примере Альфа‑Дом, как проводили кастдев для уже запущенного приложения и существующего функционала.

Первым этапом была проведена предварительная аналитика:

• анализ поведения пользователей внутри самого приложения;
• изучение отзывов в магазинах мобильных приложений;
• работа с внешними отзывами — в том числе на Яндексе по приложению Альфа‑Дом.

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

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

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

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

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

Как наладить взаимодействие с клиентом и пользователями, чтобы развивать продукт на основе инсайтов?

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

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