1. Введение
Представьте, что команда разрабатывает личный кабинет для какого-либо сервиса: образовательной платформы, интернет-магазина, банка, оператора связи или SaaS-продукта.
Команда обсуждает будущий интерфейс и приходит к вполне логичным идеям:
«Пользователям наверняка нужен удобный дашборд».
«Нужно вывести историю операций на главный экран».
«Люди часто заходят посмотреть свой статус».
«Наверное, стоит добавить уведомления».
На первый взгляд всё звучит разумно. Проблема в одном: пока мы не поговорили с пользователями и не изучили их реальное поведение, перед нами не факты, а гипотезы.
Можно несколько недель проектировать удобную историю операций, а затем обнаружить, что большинство пользователей открывает её раз в полгода. Можно потратить ресурсы на персонализированный дашборд и выяснить, что пользователь входит в кабинет только ради одной кнопки «Оплатить». А можно считать какую-то функцию второстепенной, хотя именно ради неё люди регулярно возвращаются в продукт.
Поэтому одна из важных компетенций продуктового дизайнера, маркетолога, аналитика и менеджера — способность отделять собственные представления о пользователе от его реального поведения.
Один из способов сделать это — Customer Development, или CustDev.
В этой лекции мы разберём, как превращать предположения о пользователях в проверяемые гипотезы, как готовить интервью, какие вопросы действительно дают полезную информацию, почему некоторые популярные вопросы практически бесполезны и как фиксировать результаты так, чтобы после пяти интервью у команды появились данные, а не пять страниц случайных заметок.
На практике мы применим весь процесс к знакомому объекту — личному кабинету цифрового сервиса.
2. Основная идея Customer Development
Customer Development можно перевести как «развитие через изучение клиента». Это подход, при котором команда не принимает собственные предположения о пользователях за истину, а систематически проверяет их через контакт с реальными людьми и наблюдение за их поведением.
Главная мысль здесь очень простая:
мы не спрашиваем пользователя, правильная ли у нас идея. Мы изучаем его жизнь, задачи и поведение, чтобы понять, существует ли проблема, для которой наша идея может быть решением.
Это принципиальная разница.
Представим, что мы хотим добавить в личный кабинет большой блок со статистикой активности.
Можно спросить:
«Было бы вам удобно видеть статистику своей активности на главной странице?»
Человек вполне может ответить:
«Да, было бы удобно».
Команда запишет: «Пользователю нужна статистика».
Но мы практически ничего не узнали.
Пользователь мог ответить из вежливости. Он мог представить идеальную ситуацию. Он мог действительно считать функцию полезной, но никогда ей не пользоваться.
Гораздо полезнее исследовать существующее поведение:
«Вспомните последний раз, когда вы заходили в личный кабинет. Зачем вы туда заходили?»
А затем:
«Что вы сделали первым?»
«Удалось сразу найти нужную функцию?»
«Какая информация вам понадобилась?»
«Когда до этого вы заходили в кабинет?»
Теперь мы изучаем не мнение человека о придуманной функции, а фактическое поведение.
Именно этот переход от предположений к фактам является центральной идеей CustDev.
3. Что такое гипотеза
До исследования у команды почти всегда существуют представления о пользователях.
Например:
«Людям сложно найти историю платежей».
«Пользователи регулярно проверяют баланс».
«Большинство пользователей входит в личный кабинет с телефона».
«Пользователям важно быстро скачать документы».
«Люди редко пользуются настройками профиля».
Все эти утверждения могут оказаться правдой. Но пока у нас нет подтверждения, это гипотезы.
Гипотеза — это предположение о пользователе, его проблеме, поведении, мотивации или потребности, которое можно проверить с помощью исследования.
Хорошая гипотеза должна быть проверяемой.
Например:
Слабая формулировка:
«Личный кабинет неудобный».
Непонятно, что именно проверять. Что означает «неудобный»? Для кого? В какой ситуации?
Лучше:
«Пользователям сложно находить историю платежей в личном кабинете».
Теперь появляется конкретный объект исследования.
Ещё точнее:
«Пользователи, которые заходят в личный кабинет для проверки предыдущих платежей, не сразу находят историю операций и вынуждены искать её в нескольких разделах».
Такую гипотезу уже можно исследовать.
4. Какие гипотезы можно проверять
В Customer Development полезно разделять гипотезы по смыслу.
Гипотеза о проблеме
Мы предполагаем, что у человека существует определённая трудность.
Например:
«Пользователям сложно находить документы по предыдущим заказам».
Здесь нам нужно понять не то, нравится ли человеку наше решение, а существует ли проблема вообще.
Гипотеза о поведении
Она описывает то, что пользователь делает.
Например:
«Большинство пользователей открывает личный кабинет только тогда, когда необходимо выполнить конкретное действие».
Мы можем исследовать частоту входов, причины входа и действия после авторизации.
Гипотеза о потребности
Здесь предполагается, что человеку важен определённый результат.
Например:
«Пользователю важно сразу после входа понимать текущее состояние своего аккаунта».
Гипотеза о существующем решении
Очень важная категория.
Если проблема действительно существует, пользователь часто уже каким-то образом её решает.
Например, если нужные документы сложно искать в кабинете, человек может сохранять их на компьютер, пересылать себе в Telegram, делать скриншоты или искать письма в электронной почте.
Такие обходные решения называются workarounds — обходными способами выполнения задачи.
Наличие workaround часто является сильным сигналом проблемы: человек уже тратит усилия, чтобы её решить.
Гипотеза о ценности
Мы предполагаем, какой результат особенно важен человеку.
Например:
«Для пользователя скорость выполнения операции важнее количества функций в личном кабинете».
Это уже помогает принимать продуктовые решения.
5. От гипотезы к исследовательскому вопросу
Гипотезу нельзя просто прочитать пользователю.
Если наша гипотеза звучит так:
«Пользователям сложно находить историю платежей»,
не стоит спрашивать:
«Вам сложно находить историю платежей?»
Мы фактически подсказываем человеку проблему.
Вместо этого гипотезу необходимо превратить в набор нейтральных исследовательских вопросов.
Например:
«Когда вы в последний раз заходили в личный кабинет?»
«Что вам тогда было нужно?»
«Расскажите, как вы это искали».
«Что происходило дальше?»
«Удалось найти нужную информацию сразу?»
«Бывали случаи, когда найти её не получалось?»
Так интервьюер постепенно восстанавливает реальную ситуацию.
Это напоминает работу детектива: нас интересует последовательность событий, а не только оценка человека.
6. Customer Interview и Problem Interview
В продуктовой практике можно встретить разные форматы исследовательских интервью.
Customer Interview — широкое интервью с пользователем или потенциальным клиентом. Мы исследуем его контекст, задачи, привычки, мотивацию, критерии выбора и проблемы.
Problem Interview — интервью, сфокусированное на конкретной проблемной области.
Например, если мы исследуем личный кабинет образовательной платформы, Customer Interview может охватывать весь опыт взаимодействия с платформой.
Problem Interview будет значительно уже:
как человек контролирует обучение;
где смотрит прогресс;
какую информацию ищет;
что происходит, когда не может её найти;
какие альтернативные способы использует.
Для учебной практики мы будем использовать смешанный формат: сначала разберём общий контекст использования личных кабинетов, затем сфокусируемся на конкретных задачах и проблемах.
7. Как выбирать респондентов
Респондент — человек, с которым проводится исследование.
Одна из распространённых ошибок — считать, что поговорить можно вообще с кем угодно.
Если мы проектируем профессиональный сервис для бухгалтеров, мнение человека, который никогда не занимается бухгалтерией, мало поможет понять рабочие процессы бухгалтера.
Поэтому выбор респондентов связан с исследовательской задачей.
Но в нашей учебной практике задача другая: научиться самой механике интервью.
Поэтому студент может опросить знакомого, родственника, одногруппника или коллегу. Главное условие — человек должен пользоваться каким-нибудь сервисом с личным кабинетом.
Например:
банком;
маркетплейсом;
оператором связи;
образовательной платформой;
государственным сервисом;
сервисом доставки;
онлайн-магазином;
SaaS-сервисом.
В реальном продукте требования к выборке будут значительно строже.
8. Как строится интервью
Хорошее интервью не выглядит как допрос по анкете.
У интервью должна быть логика.
Обычно разговор движется от общего контекста к конкретным ситуациям.
Сначала человеку дают освоиться:
«Какими сервисами с личным кабинетом вы регулярно пользуетесь?»
Затем исследуют частоту и контекст:
«Каким из них вы пользовались последним?»
«Когда это было?»
После этого переходят к конкретному эпизоду:
«Зачем вы туда зашли?»
«Что сделали после входа?»
«Что происходило дальше?»
И постепенно углубляются:
«Получилось найти нужное сразу?»
«На каком моменте возникла сложность?»
«Что вы сделали?»
«Как решили проблему?»
Такая структура позволяет человеку вспоминать реальную историю, а не конструировать теоретический ответ.
9. Почему прошлое поведение важнее будущих намерений
Один из фундаментальных принципов хорошего интервью:
спрашивайте о том, что человек делал, а не только о том, что он собирается делать.
Сравним два вопроса.
Первый:
«Вы бы пользовались функцией быстрого доступа к документам?»
Второй:
«Когда вам последний раз понадобился документ из личного кабинета? Как вы его нашли?»
Первый исследует воображаемое будущее.
Второй — произошедшее событие.
Человек плохо прогнозирует собственное будущее поведение. Мы можем искренне планировать заниматься спортом четыре раза в неделю, читать по книге каждую неделю или регулярно проверять аналитику проекта — и при этом не делать этого.
Поэтому обещание пользователя ещё не означает реальный спрос.
В интервью особенно ценны конкретные маркеры:
«вчера»;
«на прошлой неделе»;
«примерно три раза за месяц»;
«я сначала открыл…»;
«не нашёл и написал в поддержку»;
«пришлось искать письмо»;
«я обычно делаю скриншот».
Это следы реального поведения.
10. Открытые и закрытые вопросы
Закрытый вопрос предполагает ограниченный ответ.
«Вы часто пользуетесь личным кабинетом?»
Человек отвечает:
«Да».
Информации практически нет.
Открытый вопрос заставляет описывать опыт:
«Расскажите, в каких ситуациях вы обычно заходите в личный кабинет».
Теперь можно узнать несколько сценариев, частоту использования и контекст.
Это не означает, что закрытые вопросы запрещены. Они могут использоваться для уточнения факта:
«Это произошло один раз или повторялось?»
Проблема возникает, когда всё интервью состоит из вопросов, на которые можно ответить «да» или «нет».
11. Probing — как углублять ответ
Очень часто первый ответ человека оказывается поверхностным.
Интервьюер спрашивает:
«Как вам личный кабинет?»
Пользователь отвечает:
«Нормальный».
Если просто перейти к следующему вопросу, исследование почти ничего не даст.
Здесь нужны probing questions — уточняющие, углубляющие вопросы.
Например:
«Что именно вы имеете в виду под "нормальный"?»
«Можете привести пример?»
«Когда это произошло последний раз?»
«Что вы сделали дальше?»
«Почему решили поступить именно так?»
«Что было самым неудобным?»
«Как вы решили эту проблему?»
«Как часто такое происходит?»
Очень сильный вопрос:
«Расскажите про последний раз, когда это произошло».
Он переводит разговор из области общих рассуждений в конкретную ситуацию.
12. Анти-паттерны интервью
Анти-паттерн — это распространённый способ действия, который кажется правильным, но приводит к плохому результату.
В Customer Development их особенно много.
Ошибка 1. «Вам нравится наш продукт?»
Проблема в том, что исследование превращается в сбор комплиментов.
Человек может сказать «да», но это ничего не говорит о его поведении.
Лучше исследовать:
«Какие задачи вы решаете с помощью подобных сервисов?»
Ошибка 2. «Вы бы пользовались такой функцией?»
Это вопрос о гипотетическом будущем.
Пользователь ничем не рискует, отвечая «да».
Лучше:
«Когда вам последний раз понадобилось решить такую задачу?»
Ошибка 3. Наводящий вопрос
«Вам ведь было бы удобнее видеть все документы на одном экране?»
Вопрос уже содержит желаемый ответ.
Лучше:
«Как вы сейчас находите нужные документы?»
Ошибка 4. Продажа вместо исследования
Интервьюер начинает объяснять:
«У нас будет очень удобная система, где всё автоматически сортируется…»
После этого пользователь уже обсуждает вашу концепцию, а не собственный опыт.
Сначала нужно понять проблему. Решение можно показывать позже, если это входит в исследовательский план.
Ошибка 5. Слишком общий вопрос
«Какие проблемы возникают у вас в личных кабинетах?»
Человеку приходится вспоминать сразу весь опыт.
Лучше двигаться через конкретный эпизод:
«Какой личный кабинет вы открывали последним?»
«Зачем?»
«Что делали?»
«Что было неудобно?»
Ошибка 6. Несколько вопросов одновременно
«Как часто вы заходите, что там смотрите и насколько вам удобно находить документы?»
Респондент может ответить только на последнюю часть.
Один вопрос должен исследовать одну мысль.
Ошибка 7. Подтверждение собственной идеи
Иногда интервьюер бессознательно начинает искать доказательства своей гипотезы.
Он подробно записывает:
«Да, документы искать сложно».
Но игнорирует:
«Вообще мне документы нужны примерно раз в год».
Хотя второй факт может быть значительно важнее первого.
Цель исследования — не доказать гипотезу, а понять, выдерживает ли она столкновение с реальностью.
13. Не интервьюируйте пользователя как эксперта по продукту
Есть ещё одна важная ошибка.
Команда спрашивает:
«Что нам добавить в личный кабинет?»
И пользователь отвечает:
«Сделайте чат».
Это не означает, что необходимо делать чат.
Пользователь хорошо знает собственные проблемы, но не обязан быть продуктовым дизайнером.
Поэтому нам важнее выяснить:
Почему ему понадобился чат?
Возможно, настоящая проблема звучит так:
«Когда статус заказа непонятен, пользователь не знает, где получить объяснение».
Чат — только одно из возможных решений.
Другими решениями могут быть понятный статус заказа, уведомление, FAQ, история изменений или кнопка связи с поддержкой.
Исследователь ищет проблему и контекст, а команда позже проектирует решение.
14. Что важно исследовать в личном кабинете
Теперь применим метод к нашей практической теме.
Предположим, мы хотим понять, как люди используют личные кабинеты различных сервисов.
Нас могут интересовать четыре слоя.
Первый — частота и контекст использования.
Как часто человек входит? Что становится триггером входа?
Второй — задачи.
Зачем пользователь приходит?
Оплатить? Скачать документ? Проверить статус? Изменить данные? Посмотреть историю?
Третий — поведение.
Куда он нажимает? Что ищет первым? Какими разделами пользуется?
Четвёртый — проблемы и обходные пути.
Что сложно найти? Где человек ошибается? Когда обращается в поддержку? Что сохраняет вне личного кабинета?
Из этих наблюдений постепенно формируется понимание реальных требований к продукту.
15. Пример подготовки исследования
Допустим, студент говорит:
«Мне кажется, люди редко используют главную страницу личного кабинета и сразу переходят в нужный раздел».
Это хорошая исходная гипотеза.
Запишем:
Гипотеза: пользователи заходят в личный кабинет ради конкретной задачи и используют главную страницу преимущественно как точку перехода.
Теперь нельзя спрашивать:
«Вы ведь обычно сразу переходите в нужный раздел?»
Нужно построить исследовательские вопросы.
Например:
«Вспомните последний раз, когда вы заходили в личный кабинет».
«Что вам было нужно?»
«Что вы увидели после входа?»
«Что сделали первым?»
«На какие разделы заходили?»
«Что из информации на главной странице вам пригодилось?»
«Было ли что-то, на что вы вообще не обращали внимания?»
После нескольких интервью можно сравнить ответы.
16. Фиксация данных
Провести хорошее интервью недостаточно.
Если результаты неправильно зафиксированы, через несколько дней команда будет помнить только отдельные яркие фразы.
Поэтому исследователь разделяет наблюдение и интерпретацию.
Например, респондент говорит:
«Я обычно захожу только посмотреть, пришёл ли платёж».
Это факт интервью.
А запись:
«Пользователю нужен финансовый дашборд»
— уже интерпретация.
Между ними огромная разница.
Фиксировать полезно минимум пять типов информации:
Что фиксируем | Пример |
|---|---|
Контекст | Пользуется сервисом 2 года |
Ситуация | Заходил вчера после уведомления |
Задача | Хотел проверить статус платежа |
Поведение | Открыл «Историю операций» |
Проблема | Не понял значение одного из статусов |
Workaround | Открыл письмо, чтобы проверить детали |
Цитата | «Я никогда не понимаю, что значит "обрабатывается"» |
Отдельной колонкой можно добавить интерпретацию исследователя, но нельзя смешивать её с фактом.
Например:
Факт: пользователь трижды пытался найти документ через разные разделы.
Интерпретация: возможно, название или расположение раздела не соответствует ментальной модели пользователя.
Вторая формулировка является гипотезой исследователя и требует дополнительной проверки.
17. Не путайте единичный ответ с закономерностью
После одного интервью легко сказать:
«Пользователям нужен быстрый доступ к платежам».
Но мы поговорили только с одним человеком.
Корректнее:
«В интервью №1 пользователь регулярно заходил ради проверки платежей».
После нескольких интервью можно искать повторяющиеся паттерны.
Например:
Респондент | Основная задача | Частота | Проблема |
|---|---|---|---|
1 | Проверка платежа | 2–3 раза/мес. | Непонятный статус |
2 | Скачать документ | 1 раз/мес. | Сложно найти |
3 | Проверить заказ | 1–2 раза/нед. | Нет проблемы |
4 | Проверка платежа | 1 раз/нед. | Непонятный статус |
5 | Проверка платежа | 2 раза/мес. | Сложно найти историю |
Теперь появляются повторения.
Мы ещё не можем объявлять их универсальной истиной, но уже можем сформулировать более сильные гипотезы для следующего этапа исследования.
18. Что считать сильным сигналом
Не все ответы одинаково ценны.
Сравните:
«Наверное, такая функция была бы полезной».
и
«На прошлой неделе мне пришлось писать в поддержку, потому что я не смог это найти».
Второй сигнал значительно сильнее.
Особенно интересны ситуации, когда проблема:
повторяется — человек сталкивается с ней регулярно;
имеет последствия — он теряет время, деньги или не может закончить задачу;
заставляет искать обходное решение — Excel, заметки, скриншоты, сообщения самому себе;
приводит к действиям — обращению в поддержку, поиску инструкции, отказу от операции;
вызывает заметные затраты — времени, денег, внимания.
Чем больше реального поведения стоит за проблемой, тем серьёзнее к ней стоит относиться.
19. Что делать после интервью
CustDev не заканчивается словами:
«Спасибо за интервью».
После разговора начинается аналитическая работа.
Сначала нужно привести записи к единому формату.
Затем выделить наблюдения:
ситуация → задача → действие → проблема → решение → результат.
После нескольких интервью наблюдения сравниваются.
Мы ищем повторения:
Какие задачи возникают чаще?
Какие функции действительно используются?
Какие разделы игнорируются?
Какие проблемы повторяются?
Какие обходные решения используют люди?
Что для них критично?
После этого возвращаемся к первоначальным гипотезам.
Каждую можно пометить:
подтверждается;
частично подтверждается;
не подтверждается;
недостаточно данных.
Последний вариант особенно важен.
Исследование не обязано закончиться однозначным «да» или «нет».
20. Ограничения Customer Development
Интервью — мощный метод, но не универсальный.
Человек может неточно помнить события.
Он может рационализировать собственное поведение и объяснять его иначе, чем действовал на самом деле.
Респондент может говорить одно и делать другое.
Кроме того, интервью плохо отвечает на вопросы масштаба.
Если четыре человека из пяти сказали, что регулярно проверяют историю операций, это ещё не означает, что 80% всех пользователей продукта делают то же самое.
Для оценки масштаба понадобятся количественные методы: продуктовая аналитика, опросы, данные поведения.
Поэтому интервью особенно хорошо отвечает на вопросы:
почему?
как?
в какой ситуации?
что происходило?
А аналитика лучше помогает отвечать:
сколько?
как часто?
какая доля пользователей?
где происходит наибольший отток?
Сильное продуктовоe исследование часто сочетает оба подхода.
21. Работа с инструментами
Для учебной работы достаточно трёх типов инструментов.
Google Docs или Notion удобно использовать для гайда интервью: цели, гипотез, основных и уточняющих вопросов.
Google Sheets или Excel полезны для фиксации результатов нескольких интервью. Каждая строка может представлять наблюдение или респондента, а колонки — контекст, задачу, частоту, проблему, workaround и цитату.
Miro или FigJam пригодятся после нескольких интервью для кластеризации наблюдений. Похожие факты можно объединять и искать повторяющиеся паттерны.
ChatGPT можно использовать как помощника: проверить, нет ли в гайде наводящих вопросов, предложить нейтральные переформулировки или помочь сгруппировать уже собранные наблюдения. Но ИИ не должен придумывать отсутствующие данные респондентов. Если человек ничего не сказал о частоте использования функции, нельзя автоматически достраивать этот факт.
22. Главный принцип хорошего CustDev
После всей лекции можно оставить одну рабочую формулу:
Гипотеза → вопрос → реальный опыт → факт → паттерн → решение.
Не:
идея → спросить, нравится ли → получить «да» → начать разработку.
Хороший исследователь старается не услышать подтверждение своей идеи.
Он старается получить достаточно качественные данные, чтобы команда могла принять более обоснованное решение.
И иногда лучший результат Customer Development — обнаружить, что первоначальная идея была неправильной.
Это не провал исследования.
Это и есть его ценность.
Практическое задание на занятии
«Исследуем личный кабинет»
Цель
Пройти подготовительный цикл Customer Development:
предположение → гипотеза → исследовательская задача → гайд → вопросы → подготовка интервью.
После занятия у каждого студента должен быть готов сценарий, по которому можно провести настоящее интервью.
Шаг 1. Выберите объект исследования
Выберите любой знакомый вам сервис с личным кабинетом.
Например: банк, маркетплейс, оператор связи, образовательная платформа, интернет-магазин, сервис доставки или другой цифровой продукт.
Не нужно проектировать новый кабинет. Мы исследуем существующее поведение человека.
Шаг 2. Сформулируйте исследовательскую цель
Пример:
«Понять, в каких ситуациях пользователи заходят в личный кабинет, какие задачи там решают, какими функциями пользуются и какие сложности возникают».
Шаг 3. Сформулируйте 3–5 гипотез
Например:
«Пользователи заходят в личный кабинет преимущественно ради конкретной задачи».
«Большая часть функций используется редко».
«Есть несколько функций, ради которых пользователь возвращается регулярно».
«Некоторые задачи пользователи решают вне личного кабинета».
«Частота использования разных функций сильно различается».
Важно: гипотезы не нужно доказывать. Их нужно проверять.
Шаг 4. Определите, кого будете интервьюировать
Найдите знакомого, родственника, друга или коллегу, который действительно пользуется выбранным типом сервиса.
Для учебного упражнения строгий рекрутинг не требуется.
Шаг 5. Подготовьте гайд интервью
Разделите интервью на пять смысловых частей:
Контекст → Последний опыт → Функции и поведение → Проблемы → Альтернативы и завершение.
Не превращайте его в анкету, которую необходимо прочитать слово в слово.
Шаг 6. Подготовьте 10–15 основных вопросов
Пример стартового набора:
Какими сервисами с личным кабинетом вы регулярно пользуетесь?
Какой личный кабинет вы открывали последним?
Когда это было?
Зачем вы туда заходили?
Расскажите, что вы сделали после входа.
Какие функции вы используете чаще всего?
В каких ситуациях они вам нужны?
Какие функции используете редко или вообще не используете?
Вспомните последний случай, когда в кабинете было сложно выполнить нужную задачу. Что произошло?
Что вы сделали дальше?
Приходилось ли решать задачу каким-нибудь другим способом?
Есть ли информация, которую вы регулярно ищете после входа?
Что для вас особенно важно увидеть или сделать быстро?
Были ли случаи, когда вы не смогли закончить задачу?
Что произошло после этого?
Шаг 7. Добавьте probing-вопросы
Подготовьте минимум пять универсальных уточнений:
«Можете привести конкретный пример?»
«Когда это произошло последний раз?»
«Что вы сделали дальше?»
«Почему именно так?»
«Как часто это происходит?»
«Что было самым сложным?»
«Как вы решили эту проблему?»
Шаг 8. Проведите проверку на анти-паттерны
Найдите в собственном гайде:
наводящие вопросы;
вопросы о гипотетическом будущем;
вопросы «нравится / не нравится»;
вопросы, содержащие предлагаемое решение;
двойные вопросы;
слишком общие вопросы;
вопросы, на которые достаточно ответить «да/нет».
Каждый найденный вопрос перепишите.
Шаг 9. Подготовьте таблицу фиксации
Создайте структуру:
Респондент | Контекст | Частота использования | Задача | Используемая функция | Ситуация | Действие | Проблема | Workaround | Результат | Цитата | Интерпретация
Важно разделять факт и интерпретацию.
Результат практики
К концу пары у студента должны быть:
3–5 проверяемых гипотез + цель исследования + описание респондента + готовый гайд + 10–15 вопросов + probing-вопросы + таблица фиксации результатов.
Домашнее задание
«Первое Customer Development интервью»
Цель
Проверить подготовленный гайд не на преподавателе и не на воображаемом пользователе, а в настоящем разговоре.
Минимальный вариант
Проведите одно интервью со знакомым человеком, который пользуется сервисом с личным кабинетом.
Продолжительность интервью — ориентировочно 15–25 минут.
После интервью заполните подготовленную таблицу.
Для каждой исходной гипотезы поставьте один статус:
подтверждается / частично подтверждается / не подтверждается / недостаточно данных.
Для каждого вывода приведите наблюдение, на котором он основан.
Плохо:
«Пользователям неудобна навигация».
Хорошо:
«Респондент хотел скачать чек, сначала открыл "Профиль", затем "Платежи", вернулся назад и только после этого нашёл чек в "Истории заказов"».
Расширенный вариант
Проведите 3 интервью.
После этого сравните результаты и найдите повторяющиеся паттерны.
Не объединяйте разные ответы искусственно. Отдельно отметьте:
что повторилось у нескольких людей;
что встретилось только один раз;
какие исходные гипотезы получили поддержку;
какие не подтвердились;
какие новые гипотезы появились после интервью.
Формат сдачи
Один документ или ссылка на рабочее пространство, содержащие:
цель исследования;
исходные гипотезы;
гайд интервью;
список вопросов;
таблицу результатов;
ключевые наблюдения;
статус каждой гипотезы;
3–5 выводов после исследования.
Критерии проверки
Работа считается сильной, если гипотезы действительно можно проверить, а вопросы не подсказывают желаемый ответ.
Особое внимание при проверке стоит уделить четырём вещам.
Качество гипотез. Вместо абстрактного «пользователям неудобно» студент формулирует конкретное предположение о поведении, задаче или проблеме.
Качество вопросов. Вопросы преимущественно открытые, опираются на конкретный прошлый опыт и позволяют восстановить ситуацию.
Качество интервью. Студент использует уточнения, не спорит с респондентом, не продаёт ему решение и не пытается любой ценой подтвердить гипотезу.
Качество данных. Факты отделены от интерпретаций. Выводы можно связать с конкретными наблюдениями из интервью.
Главный критерий можно сформулировать так:
может ли другой человек посмотреть на собранные данные и понять, откуда появился вывод?
Если да — исследование зафиксировано хорошо.
Итоги лекции
Customer Development начинается не с вопроса пользователю, а с признания того, что у команды существуют предположения.
Мы превращаем эти предположения в гипотезы. Затем формулируем исследовательские вопросы, которые не раскрывают пользователю желаемый ответ. Во время интервью изучаем конкретные ситуации и прошлое поведение, задаём уточняющие вопросы и ищем реальные действия, проблемы и обходные решения.
После интервью мы не собираем понравившиеся цитаты, а структурируем наблюдения, отделяем факты от интерпретаций и сравниваем данные нескольких респондентов.
Поэтому хороший CustDev — это не:
«Я спросил пользователя, понравилась ли ему идея».
Это последовательный процесс:
«У меня было предположение → я определил, какие факты могут его подтвердить или опровергнуть → поговорил с пользователем о реальном опыте → зафиксировал наблюдения → сравнил результаты → обновил своё понимание проблемы».
Именно этому процессу и посвящена практическая часть занятия.
