Спланируйте интервью с пользователями с рабочим прототипом за 48 часов: быстро найдите участников, составьте скрипты задач, фиксируйте заметки и превратите отзывы в понятные запросы на разработку.
Рабочий прототип быстро решает большинство споров. Когда человек пытается выполнить реальную задачу, вы перестаёте гадать, что он бы сделал, и начинаете видеть, что он делает на самом деле. Поэтому интервью с рабочим прототипом выигрывают у обсуждений в чате, даже если прототип грубый.
При 3–6 сессиях вы можете узнать много, если держите область исследований узкой. Статистику вы не получите идеальную, но увидите повторяющиеся паттерны, которые можно исправить уже на этой неделе.
За 48 часов вы надёжно обнаружите, где люди запинаются или возвращаются назад, какие метки их сбивают с толку, что они пробуют сначала (и что игнорируют), чего не хватает, чтобы они доверились потоку, и какие моменты создают сомнения — например цены, разрешения или сохранение прогресса.
Этот подход избавляет от крупных исследовательских проектов, длинных опросов и бессмысленных «ловлей рыбы». Вы не пытаетесь отрисовать весь рынок. Вы пытаетесь убрать самое большое трение в одном важном потоке.
Определите одну цель обучения перед тем, как назначать участников. Простой формат работает хорошо: «Может ли впервые пришедший пользователь выполнить X менее чем за Y минут без помощи?» Если вы делаете простой CRM, это может быть: «Может ли новый пользователь добавить контакт, пометить его и снова найти?»
Если вы быстро собрали прототип в инструменте вроде Koder.ai, цель остаётся той же: выберите один поток, наблюдайте, как реальные люди его проходят, и фиксируйте именно то, что нужно изменить.
48‑часовой раунд возможен только при сокращении объёма. Выберите один конкретный тип пользователя и один сценарий, который им уже понятен. Если вы попытаетесь охватить онбординг, цены, настройки и крайние случаи в одной сессии, вы получите мнения вместо доказательств.
Напишите одно предложение-цель, например: «Может ли впервые пришедший фриланс‑дизайнер создать счёт и отправить его менее чем за 3 минуты без помощи?» Это предложение говорит, кто пользователь, что он должен сделать и что значит «хорошо».
Решите, что будете измерять, до того как начнёте разговаривать с кем‑то. Держите это просто и видимо во время сессии. Для большинства команд это смесь скорости (время на выполнение), трения (как часто они застревают или спрашивают «что дальше?»), проблем навигации (колебание, повторное чтение, возвраты) и сигналов доверия (беспокойство о платеже, приватности или ошибках).
Затем напишите 3–5 вопросов, на которые вы должны ответить к концу раунда. Примеры:
Не продолжайте интервью просто потому что можете. Решите заранее, когда остановиться, чтобы вернуться к разработке. Практичное правило: прекратить после пяти сессий или раньше, если те же две главные проблемы повторяются в трёх сессиях подряд.
Пример: если три из пяти участников не могут найти «Создать счёт», потому что оно спрятано под «Биллинг», у вас уже есть ясный запрос на разработку: переименовать метку, переместить точку входа и повторно протестировать одно изменение.
Вы можете провести полезные интервью с рабочим прототипом за два дня, если отнесётесь к этому как к короткому спринту: рекрутинг, подготовка, проведение и синтез, пока детали ещё свежие. Цель — 3–5 сессий. Три — минимум, чтобы заметить самые большие проблемы. Пять обычно показывает паттерны.
Реалистичный план выглядит так:
Если рекрутинг идёт медленно, не ждите. Сократите объём и расширьте доступность. Предложите больше временных слотов (включая раннее утро или вечер), сократите сессии до 15 минут или рекрутируйте из ближайшего круга, который всё ещё соответствует целевой группе.
Чтобы всё было организовано, создайте простую систему папок до первого звонка:
01_Recruiting02_Recordings03_Notes04_Synthesis05_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 задач достаточно, чтобы заметить паттерны, не торопясь.
Начните с названия основного сценария простыми словами (например: «Я хочу настроить первый проект и пригласить коллегу»). Затем выберите задачи, которые представляют моменты, где провал причинит наибольший вред: первичная настройка, поиск ключевой функции и выполнение одного значимого действия.
Используйте ту же структуру в каждой сессии, чтобы результаты были сравнимы:
Пишите формулировки задач так, чтобы они не раскрывали имя кнопки или точный путь. Плохой пример: «Нажмите Snapshots и выполните откат.» Лучше: «Вы допустили ошибку и хотите вернуться к вчерашней версии. Покажите, что бы вы сделали.»
После каждой задачи задавайте один короткий вопрос. До клика: «С чего вы бы начали?» После: «Почему вы выбрали этот путь?» Если участник застрял, спросите «Что вы сейчас ищете?» вместо «Вы видели меню?»
Если вы собрали прототип в Koder.ai, держите задачи привязанными к результатам (создать приложение, экспортировать исходный код, установить кастомный домен), а не к терминологии платформы. Так ваши заметки проще превратить в задания для разработки.
Начинайте каждую сессию одинаково. Это снижает напряжение и делает результаты проще для сравнения.
Откройте коротким скриптом: поблагодарите, объясните, что тестируется продукт, а не они, и что нет неправильных ответов. Попросите проговаривать мысли вслух и делиться ожиданиями перед кликом.
Давайте по одной задаче за раз и держите молчание. Ваша основная задача — наблюдать, где они медлят, и задавать короткие нейтральные вопросы вроде «О чём вы думаете?» и «Что вы ожидали увидеть?» Избегайте обучения, похвалы или защиты прототипа.
Когда они застряли, подтолкните, прежде чем спасать. Хороший толчок опирается на их цель, а не на интерфейс: «Что вы попробовали бы дальше?» или «Где вы бы это искали?» Если участник действительно заблокирован более минуты, переходите к следующей задаче и отметьте это как проблему высокой серьёзности. Удерживайте себя от правки прототипа во время звонка — зафиксируйте проблему и продолжайте.
Запросы на функционал полезны, но не вступайте в дебаты. Отложите их с коротким вопросом: «Какую проблему это решит для вас?» Затем возвращайтесь к текущей задаче.
Закрывайте сессию последовательно. Спросите, что им понравилось, что раздражало, заплатили бы они и сколько, и можно ли связаться с ними после обновления.
Хорошие заметки — не «всё, что произошло». Это маленькие, последовательные единицы, которые можно потом сортировать. Если вы поддерживаете одинаковую структуру во всех сессиях, паттерны проявятся после третьего интервью.
Выберите один документ или таблицу, в которой будут работать все наблюдатели. Создавайте одну строку на каждую попытку задачи и записывайте короткие фактические заметки в одних и тех же полях каждый раз. Простой макет:
Отметки времени помогают быстро вернуться к записям и проверить формулировку. Номера задач не дадут перепутать проблемы между потоками.
Когда что‑то идёт не так, запишите это одной простой фразой, которую коллега поймёт без контекста. Описывайте момент, а не своё толкование.
Пример: “T2 06:14: Нажал «Сохранить», ожидал подтверждения, но ничего не произошло, и он спросил, сработало ли это.”
Добавляйте цитату, когда она усиливает точку, особенно по вопросам доверия или путаницы («Не уверен, что это безопасно» или «С чего мне начать?»). Цитаты упрощают приоритизацию, потому что показывают влияние.
Держите теги простыми для быстрой фильтрации:
Если ваш прототип сделан в Koder.ai, фокусируйтесь в заметках на поведении пользователя и поведении продукта, а не на том, как прототип был сгенерирован.
Правило напоследок: если заметку нельзя превратить в заголовок тикета, перепишите её, пока не получится.
Самый быстрый способ потерять импульс — оставить отзывы в виде цитат и впечатлений. Превратите наблюдения в запросы на разработку, которые разработчик сможет выполнить без догадок.
Начните с группировки проблем по задачам, а не по людям. Если три человека затруднились при «создании аккаунта», это одна проблема с несколькими данными, а не три отдельных мнения.
Используйте один согласованный формат запроса, чтобы все проблемы были сопоставимы:
Отделяйте правки формулировок и понятности от изменений объёма. «Не понимаю, что делает эта кнопка» — часто вопрос метки или размещения. «Мне нужны экспорты, роли и утверждения» — это большее продуктное решение. Смешивание создаёт раздутые тикеты.
Затем решите по каждой проблеме: правка сейчас, ретест, или отложить. Простой метод ранжирования — присвоить влияние на пользователя, усилия, уверенность (повторялось ли это?) и следующее действие (разработать, повторно протестировать, отложить).
Если вы работаете в Koder.ai, пишите критерий приёма простым языком, чтобы можно было вставить его в чат разработки как тестируемое задание.
Не‑технический основатель собирает простой CRM‑онбординг в Koder.ai, а на следующий день проводит интервью. Цель узкая: может ли sales‑представитель довести до «первой созданной сделки» без помощи.
Рекрутинг быстрый: он пишет в своей сети и нескольких локальных sales‑сообществах, предлагает небольшую подарочную карту. Пять продавцов бронируют 20‑минутные слоты в один день.
Каждая сессия использует одни и те же три задачи, прочитанные дословно:
За пять сессий фиксируются повторяющиеся проблемы и несколько блокеров. Двое не могут найти, где импортировать. Трое думают, что «Напоминание» — это настройка уведомлений, а не follow‑up.
К концу дня наблюдения превращаются в запросы на разработку, которые можно реализовать сразу:
Вот в чём суть: последовательные задачи, повторяющиеся паттерны и тикеты, написанные так ясно, чтобы их могли реализовать в тот же день.
Большинство плохих результатов интервью вызывают несколько мелких ошибок, а не сам прототип.
Ведущие вопросы вроде «Это понятно, да?» вызывают вежливое согласие. Используйте нейтральные фразы: «Как вы думаете, что это делает?» и молчите.
Попытка протестить слишком многое в одной сессии даёт поверхностные комментарии и слабые сигналы. Выберите 2–3 ключевых потока.
Изменение скрипта в середине ломает сопоставимость. Откладывайте новые идеи в бэклог и держите задачи стабильными.
Хаотичные заметки — ещё одна тихая неудача. Если вы полагаетесь на память, вы запомните смешное, но не болезненное. Записывайте точный шаг, где они застряли, и что сделали дальше.
Простая проверка реальности: если участник говорит «Вроде норм», но ищет следующую кнопку 90 секунд, его действия — это данные. Комплимент — шум.
Один громкий отзыв не должен становиться планом. Рассматривайте сильные мнения как гипотезу, пока та же проблема не появится в нескольких сессиях.
Если вы вносите большие правки, быстро ретестируйте. Даже две коротких сессии подтвердят, что вы действительно решили проблему, а не просто сместили её.
Перед первым звонком зафиксируйте основы:
Сразу после каждой сессии делайте трёхминутную проверку, пока впечатления ещё свежи: запишите три главные проблемы и один сюрприз. Если вы не можете их назвать, ваши задачи, вероятно, слишком широки или заметки слишком расплывчаты.
В тот же день сделайте короткий итог, который превращает сырые заметки в решения. Сгруппируйте похожие проблемы, выберите, что важнее, и определите, что вы измените дальше.
Затем запланируйте ретест в течение 72 часов после релиза правок. Даже три быстрые сессии подтвердят, сработало ли изменение.
Если вы итератируете в Koder.ai (koder.ai), Planning Mode может помочь переписать выводы как ограниченные задачи («Изменить X, чтобы пользователь мог сделать Y без Z»), а снимки (snapshots) облегчают попытки правок без потери стабильной версии.
Старайтесь провести 3–5 сессий. Три обычно выявляют самые большие блокировки, а пяти часто достаточно, чтобы подтвердить повторяющиеся паттерны. Остановитесь раньше, если одни и те же две ключевые проблемы повторяются в трёх сессиях подряд, и переходите к правкам и ретесту.
Используйте одно предложение, которое называет пользователя, задачу и измеримый порог. Хороший формат: «Может ли впервые пришедший [тип пользователя] выполнить [задачу] за [время] без помощи?» Это сохраняет фокус на наблюдаемом поведении.
Выбирайте 2–4 задачи, которые представляют самые важные моменты одного потока, например настройка в первый раз и выполнение одного значимого действия. Делайте задачи ориентированными на результат — тестируете, смогут ли люди добиться цели, а не найти конкретную кнопку.
Начните с самых быстрых источников: люди, уже близкие к продукту — пробные пользователи, список ожидания, недавние обращения в поддержку или заявки на демонстрацию. Короткое приглашение, ясное уточнение, что это не продажа, и два конкретных варианта времени сегодня или завтра сокращают переписку и повышают отклик.
Задайте три коротких вопроса: что они сейчас используют для решения этой задачи (или как решают её иначе), расскажите о последнем опыте выполнения этой задачи, и какой из перечисленных ролей лучше всего их описывает (и почему). Избегайте людей, далеко от вашей целевой группы, чрезмерно вовлечённых (близкие друзья, конкуренты) и тех, кто слишком занят, чтобы сосредоточиться.
Попросите разрешение на запись, объясните, для чего будут использованы запись и заметки (улучшение продукта), и пообещайте анонимизировать цитаты при публикации. Дайте простой вариант отказаться от записи — они могут участвовать, а вы будете вести заметки вручную.
Ограничьте прототип только теми экранами, которые нужны для задач, и сделайте контент реалистичным, чтобы пользователи реагировали естественно. Создайте отдельный тестовый аккаунт и простую процедуру сброса, чтобы каждый участник начинал из одного состояния — это делает результаты сопоставимыми.
Проводите сессии одинаково: одно и то же вступление, те же задачи и по большей части молчание, пока участник работает. Задавайте нейтральные вопросы вроде «Что вы сейчас ищете?» и избегайте обучения или защиты дизайна — это скрывает реальные провалы продукта.
Описывайте коротко и последовательно: что они попробовали, что ожидали и что произошло, плюс одна цитата, если она усиливает аргумент. Добавьте простую метку по серьёзности (блокирует, замедляет, несущественно), чтобы быстро приоритизировать, пока доказательства ещё свежи.
Преобразуйте повторяющиеся проблемы в запросы на разработку с пятью частями: проблема (одно предложение), доказательство (наблюдение или цитата + где это произошло), влияние (потеря времени, путаница, отток), предлагаемое изменение (что менять в интерфейсе или потоке) и критерий приёма (как проверить в следующем тесте). Группируйте по задачам, а не по участникам, чтобы одна и та же проблема не стала пятью разными мнениями.
Сначала отметьте паттерны, затем приоритеты и конкретные следующие шаги. Сделайте небольшой список изменений, которые можно внедрить быстро и протестировать снова. Даже три короткие сессии после правок дадут быстрый ответ — работает решение или нет.