Интервью с пользователями по рабочему прототипу за 48 часов

Что вы можете узнать из интервью за 48 часов

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

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

За 48 часов вы надёжно обнаружите, где люди запинаются или возвращаются назад, какие метки их сбивают с толку, что они пробуют сначала (и что игнорируют), чего не хватает, чтобы они доверились потоку, и какие моменты создают сомнения — например цены, разрешения или сохранение прогресса.

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

Определите одну цель обучения перед тем, как назначать участников. Простой формат работает хорошо: «Может ли впервые пришедший пользователь выполнить X менее чем за Y минут без помощи?» Если вы делаете простой CRM, это может быть: «Может ли новый пользователь добавить контакт, пометить его и снова найти?»

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

Установите узкую цель (чтобы интервью были сосредоточенными)

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

Напишите одно предложение-цель, например: «Может ли впервые пришедший фриланс‑дизайнер создать счёт и отправить его менее чем за 3 минуты без помощи?» Это предложение говорит, кто пользователь, что он должен сделать и что значит «хорошо».

Выберите наблюдаемый сигнал успеха

Решите, что будете измерять, до того как начнёте разговаривать с кем‑то. Держите это просто и видимо во время сессии. Для большинства команд это смесь скорости (время на выполнение), трения (как часто они застревают или спрашивают «что дальше?»), проблем навигации (колебание, повторное чтение, возвраты) и сигналов доверия (беспокойство о платеже, приватности или ошибках).

Затем напишите 3–5 вопросов, на которые вы должны ответить к концу раунда. Примеры:

• Где люди ожидают начать этот поток?
• Какой экран вызывает первую реальную путаницу?
• Какая формулировка заставляет их сомневаться?
• Что они пробуют, что прототип не поддерживает?
• Что заставило бы их сказать «да, я бы пользовался этим»?

Установите правило остановки

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

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

Расписание на 48 часов (просто и реалистично)

Вы можете провести полезные интервью с рабочим прототипом за два дня, если отнесётесь к этому как к короткому спринту: рекрутинг, подготовка, проведение и синтез, пока детали ещё свежие. Цель — 3–5 сессий. Три — минимум, чтобы заметить самые большие проблемы. Пять обычно показывает паттерны.

Реалистичный план выглядит так:

• Часы 0–4: Напишите одно‑предложение‑цель, выберите 2–4 задачи, подготовьте короткое приглашение и начните рекрутинг.
• Часы 4–12: Забронируйте слоты, подтвердите соответствие, получите согласие и быстро проверьте прототип, чтобы явные баги не испортили сессию.
• Часы 12–24: Проведите две сессии. Сразу после каждой напишите пятиминутное резюме: что они пробовали, где медлили, чего ожидали.
• Часы 24–36: Проведите еще одну‑три сессии. Держите скрипт и настройки одинаковыми, чтобы результаты были сопоставимы.
• Часы 36–48: Синтезируйте. Сгруппируйте заметки по темам, выберите три главные проблемы и превратите их в запросы на разработку.

Если рекрутинг идёт медленно, не ждите. Сократите объём и расширьте доступность. Предложите больше временных слотов (включая раннее утро или вечер), сократите сессии до 15 минут или рекрутируйте из ближайшего круга, который всё ещё соответствует целевой группе.

Чтобы всё было организовано, создайте простую систему папок до первого звонка:

• 01_Recruiting
• 02_Recordings
• 03_Notes
• 04_Synthesis
• 05_Tickets

Называйте файлы вроде P01_2026-01-16_Record.mp4 и P01_Notes.md. Эта небольшая привычка упрощает последующий просмотр тестирования удобства прототипа.

Быстрый рекрутинг без лишних размышлений

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

Начните с самых быстрых источников, затем расширяйте круг. Сначала приглашайте тех, кто уже просил продукт (клиенты, пробные пользователи, список ожидания), затем загляните в недавние беседы (тут сообщения в поддержку, запросы на демонстрацию, ответы на e‑mail). Если нужно больше людей, ищите сообщества, где обсуждается проблема, просите рекомендации «друзей друзей» (не их мнения) и связывайтесь с бывшими коллегами или клиентами с похожим рабочим процессом.

Держите приглашение коротким и конкретным. Уточните, что это не коммерческий звонок, что вы тестируете продукт, а не человека. Укажите, что вы делаете и для кого, что вы просите (20 минут по видео или голосу), что они будут делать (попробуют 2–3 задачи на прототипе) и небольшое спасибо — подарочная карта, бесплатный месяц или пожертвование. Предложите два варианта времени сегодня или завтра.

Если вы сделали внутренний CRM‑прототип в Koder.ai, приглашайте и тех, кто пользуется «хаотичными таблицами», и тех, кто уже использует CRM. Такая смесь поможет избежать отзывов только от продвинутых пользователей. И не полагайтесь исключительно на близких друзей — они будут стараться быть вежливыми.

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

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

Скрининг, расписание и согласие в одном потоке

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

Лёгкий скрининг — всего три вопроса:

• Что вы сейчас используете, чтобы решать эту задачу (или как вы её делаете иначе)?
• Расскажите о последнем разе, когда вы пытались это сделать. Что произошло?
• Что из перечисленного лучше всего вас описывает: [ваши целевые роли], и почему?

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

Для расписания держите интервалы плотными: 30‑минутные сессии с 15‑минутным буфером. Буфер — это время, чтобы написать аккуратные заметки, назвать записи и восстановить прототип. Если ставить звонки подряд, заметки становятся невнятными, и паттерны теряются.

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

Отправьте простое пред‑письмо с временем, ожидаемой длительностью, повесткой (5 минут вступление, 20 минут задач, 5 минут завершение) и что им нужно (ноутбук или телефон, логин при необходимости, тихое место). Это предотвратит сюрпризы вроде «я подключился с телефона», которые срывают тестирование прототипа.

Подготовьте прототип, чтобы сессии не срывались

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

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

Сделайте контент правдоподобным. Замените lorem ipsum на реалистичный текст и данные, чтобы пользователи реагировали естественно. Если тестируете CRM‑поток, покажите 6–10 контактов с именами, компаниями и парой заметок. Если тестируете оформление заказа — реальные цены и варианты доставки. Фальшивый, но конкретный контент лучше общего.

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

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

Выберите инструменты захвата до начала общения. Записывайте звонок, если можно, и держите простой шаблон заметок с тремя колонками: Задача, Наблюдения (что произошло) и Цитаты (точные слова). Если вы используете Koder.ai, сделайте снимок (snapshot) до первой сессии — так легче откатиться, если что‑то случайно поменяется в течение дня.

Пишите скрипты задач, которые дают чёткие сигналы

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

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

Простой скрипт, который можно переиспользовать

Используйте ту же структуру в каждой сессии, чтобы результаты были сравнимы:

• Вступление (1 мин): «Мы тестируем продукт, а не вас. Пожалуйста, проговаривайте вслух.»
• Разминка (2 мин): «Что, по‑вашему, должен помогать делать этот продукт?»
• Задачи (20–25 мин): 2–4 задачи, по одной за раз.
• Завершение (3 мин): краткая оценка и одно пожелание по улучшению.

Пишите формулировки задач так, чтобы они не раскрывали имя кнопки или точный путь. Плохой пример: «Нажмите Snapshots и выполните откат.» Лучше: «Вы допустили ошибку и хотите вернуться к вчерашней версии. Покажите, что бы вы сделали.»

После каждой задачи задавайте один короткий вопрос. До клика: «С чего вы бы начали?» После: «Почему вы выбрали этот путь?» Если участник застрял, спросите «Что вы сейчас ищете?» вместо «Вы видели меню?»

Если вы собрали прототип в Koder.ai, держите задачи привязанными к результатам (создать приложение, экспортировать исходный код, установить кастомный домен), а не к терминологии платформы. Так ваши заметки проще превратить в задания для разработки.

Проведите сессии и поддерживайте их последовательность

Начинайте каждую сессию одинаково. Это снижает напряжение и делает результаты проще для сравнения.

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

Давайте по одной задаче за раз и держите молчание. Ваша основная задача — наблюдать, где они медлят, и задавать короткие нейтральные вопросы вроде «О чём вы думаете?» и «Что вы ожидали увидеть?» Избегайте обучения, похвалы или защиты прототипа.

Когда они застряли, подтолкните, прежде чем спасать. Хороший толчок опирается на их цель, а не на интерфейс: «Что вы попробовали бы дальше?» или «Где вы бы это искали?» Если участник действительно заблокирован более минуты, переходите к следующей задаче и отметьте это как проблему высокой серьёзности. Удерживайте себя от правки прототипа во время звонка — зафиксируйте проблему и продолжайте.

Запросы на функционал полезны, но не вступайте в дебаты. Отложите их с коротким вопросом: «Какую проблему это решит для вас?» Затем возвращайтесь к текущей задаче.

Закрывайте сессию последовательно. Спросите, что им понравилось, что раздражало, заплатили бы они и сколько, и можно ли связаться с ними после обновления.

Фиксируйте заметки так, чтобы их было легко синтезировать

Хорошие заметки — не «всё, что произошло». Это маленькие, последовательные единицы, которые можно потом сортировать. Если вы поддерживаете одинаковую структуру во всех сессиях, паттерны проявятся после третьего интервью.

Используйте один общий документ для всех

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

• Отметка времени (мм:сс) и ID участника
• Номер задачи и экран, на котором они были
• Что они попробовали, что ожидали и что произошло
• Одна цитата (только если это важно)
• Теги: серьёзность (high/med/low) + тип

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

Фиксируйте доказательства, а не мнения

Когда что‑то идёт не так, запишите это одной простой фразой, которую коллега поймёт без контекста. Описывайте момент, а не своё толкование.

Пример: “T2 06:14: Нажал «Сохранить», ожидал подтверждения, но ничего не произошло, и он спросил, сработало ли это.”

Добавляйте цитату, когда она усиливает точку, особенно по вопросам доверия или путаницы («Не уверен, что это безопасно» или «С чего мне начать?»). Цитаты упрощают приоритизацию, потому что показывают влияние.

Держите теги простыми для быстрой фильтрации:

• Серьёзность: high (блокирует задачу), med (замедляет), low (надоедливое)
• Тип: confusion, trust, missing, bug

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

Правило напоследок: если заметку нельзя превратить в заголовок тикета, перепишите её, пока не получится.

Превратите отзывы в точные запросы на разработку

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

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

Используйте один согласованный формат запроса, чтобы все проблемы были сопоставимы:

• Проблема: чего пользователь не смог сделать (одно предложение)
• Доказательство: точное наблюдение или цитата + где это произошло
• Влияние: почему это важно (время, путаница, отток, неверные данные)
• Предложенное изменение: что менять в UI или потоке
• Критерий приёма: как вы узнаете, что это исправлено в следующем тесте

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

Затем решите по каждой проблеме: правка сейчас, ретест, или отложить. Простой метод ранжирования — присвоить влияние на пользователя, усилия, уверенность (повторялось ли это?) и следующее действие (разработать, повторно протестировать, отложить).

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

Пример: пять интервью, превратившиеся в пять действующих тикетов

Не‑технический основатель собирает простой CRM‑онбординг в Koder.ai, а на следующий день проводит интервью. Цель узкая: может ли sales‑представитель довести до «первой созданной сделки» без помощи.

Рекрутинг быстрый: он пишет в своей сети и нескольких локальных sales‑сообществах, предлагает небольшую подарочную карту. Пять продавцов бронируют 20‑минутные слоты в один день.

Каждая сессия использует одни и те же три задачи, прочитанные дословно:

• Добавить небольшой список контактов (CSV или вставка)
• Создать первую сделку для одного контакта и перевести её на следующий этап
• Назначить напоминание на завтра на 9:00

За пять сессий фиксируются повторяющиеся проблемы и несколько блокеров. Двое не могут найти, где импортировать. Трое думают, что «Напоминание» — это настройка уведомлений, а не follow‑up.

К концу дня наблюдения превращаются в запросы на разработку, которые можно реализовать сразу:

• Добавить кнопку «Импорт контактов» в пустом состоянии. Критерий приёма: видна на первом экране; поддерживает загрузку CSV и вставку.
• Переименовать «Напоминание» в «Follow‑up» повсеместно. Критерий приёма: метка обновлена на кнопке, в модальном окне и в сообщении подтверждения.
• Автоматически создать дефолтную воронку с тремя стадиями. Критерий приёма: в новом аккаунте есть «New, Contacted, Won»; пользователь может отредактировать позже.
• Добавить поясняющий текст в форме создания сделки. Критерий приёма: одна строка под «Название сделки» с примером; снижает пустые отправки.
• Показывать баннер успеха с подсказкой следующего шага после каждой задачи. Критерий приёма: после импорта предложить «Создать первую сделку»; после создания сделки — предложить «Назначить follow‑up».

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

Частые ловушки, которые портят интервью

Большинство плохих результатов интервью вызывают несколько мелких ошибок, а не сам прототип.

Ловушки, которые делают отзывы лучше, чем есть

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

Попытка протестить слишком многое в одной сессии даёт поверхностные комментарии и слабые сигналы. Выберите 2–3 ключевых потока.

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

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

Простая проверка реальности: если участник говорит «Вроде норм», но ищет следующую кнопку 90 секунд, его действия — это данные. Комплимент — шум.

Ловушки при интерпретации результатов

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

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

Быстрый чек‑лист и следующие шаги

Перед первым звонком зафиксируйте основы:

• Цель раунда (одно предложение)
• Профиль целевого пользователя (для кого и для кого не)
• Вопросы скрининга + план рекрутинга
• Скрипт задач (2–4 задачи) + один дополнительный вопрос на задачу
• План сброса прототипа (свежее состояние, тестовые данные)
• Метод записи (и резервный) и текст согласия
• Шаблон заметок (проблемы, цитаты, серьёзность, доказательства)

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

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

Итог в тот же день (20 минут)

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

Затем запланируйте ретест в течение 72 часов после релиза правок. Даже три быстрые сессии подтвердят, сработало ли изменение.

Если вы итератируете в Koder.ai (koder.ai), Planning Mode может помочь переписать выводы как ограниченные задачи («Изменить X, чтобы пользователь мог сделать Y без Z»), а снимки (snapshots) облегчают попытки правок без потери стабильной версии.