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

• генераторы интерфейсов по промпту, например v0 и Lovable;
• конструкторы ботов, например PuzzleBot;
• ИИ-редакторы кода, например Claude Code, TRAE Solo;
• плагины с ИИ для IDE.

Быстрый промптинг: v0 и Lovable
Инструменты вроде v0 и Lovable рассчитаны прежде всего на one-shot-подход: пользователь описывает, что хочет получить, а система генерирует прототип за один или несколько запросов.
Их преимущества:

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

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

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

• последовательность сообщений;
• кнопки;
• ветвления;
• формы;
• простую логику взаимодействия.

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

ИИ-редакторы кода
Альтернативный вариант — использование инструментов, которые дают доступ непосредственно к коду проекта.
К ним относятся Claude Code, TRAE Solo и ИИ-плагины для IDE. Такой подход требует больше технических навыков, зато обеспечивает более полный контроль над проектом.
Преимущества:

• возможность работать с кодовой базой напрямую;
• гибкое изменение логики;
• специальные возможности для работы с ИИ-агентами;
• большая свобода при развитии прототипа.

Недостатки:

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

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

Wizard of Oz требует не только интерфейса, но и подробного плана того, как будет работать «скрытая» ручная часть сервиса.

В плане необходимо зафиксировать:

• схему работы сервиса;
• длительность и условия эксперимента;
• способ привлечения пользователей;
• необходимую разработку;
• требуемые человеческие ресурсы;
• измеряемые показатели;
• собираемую обратную связь;
• критерии успеха.

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

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

Вместо разработки алгоритма команда может:

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

При этом уже можно отслеживать реальные показатели — например open rate и click rate – и сравнивать их с существующими бенчмарками. В приведённом примере открываемость была почти 100%, а доля кликов – около 50%.
То есть технология ещё не существует, но ценность результата уже можно проверить.

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

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

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

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

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

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

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

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

При работе с пользователями необходимо заранее определить:

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

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

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

Пилот позволяет обнаружить:

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

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

До начала эксперимента нужно определить, какое поведение будет считаться признаком интереса к продукту.

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

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

Таким образом исследование должно отвечать не только на вопрос «что произошло?», но и на вопрос «какой результат подтвердит нашу гипотезу?»

Перед созданием консьержского исследования нужно сформулировать три элемента:

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

Такая формулировка превращает абстрактную идею в проверяемое предположение.

План консьержского исследования должен отвечать на несколько вопросов:

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

В отличие от Wizard of Oz, здесь важна не только оценка идеи, но и изучение того, каким должен быть будущий сервис.

У консьержа должно быть отдельное руководство.
В нём фиксируются:

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

При этом руководство не должно превращать консьержа в жёсткий алгоритм. Одна из ценностей метода заключается именно в возможности адаптироваться к потребностям конкретного человека.

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

Команда отвечает за:

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

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

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

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

• сообщения;
• анкеты;
• интервью;
• отдельные созвоны.

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

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

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

Главная ценность метода — не просто получить реакцию на идею, а понять, может ли такое решение естественно встроиться в существующее поведение человека.

До проведения нужно подготовить:

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

То есть сценарий – это не просто художественное описание будущего продукта. Он является исследовательским инструментом и должен быть связан с конкретными вопросами.

Для исследования составляется контекстный сценарий по подходу А. Купера.
Он представляет собой подробное описание идеального использования решения с учётом:

• жизненного контекста;
• деятельности пользователя;
• его целей;
• действий;
• взаимодействия с системой;
• результатов.

Сценарий может быть представлен:

• текстом;
• сторибордом.

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

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

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

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

Во время разговора важно постоянно возвращаться к реальному опыту человека:
«Было ли у вас что-то похожее?»
«Как вы действуете сейчас?»
«Что произошло бы в вашей ситуации?»
Сценарий можно адаптировать под обстоятельства конкретного участника.
Гипотетические рассуждения допустимы, но они не должны полностью вытеснять разговор о настоящем опыте.

При анализе важно смотреть не только на прямое «нравится / не нравится».

Нужно оценить:

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

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

Сначала полезно составить для себя короткое недетализированное описание идеи.

После этого его можно превратить в подробный сценарий.
При написании важно:

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

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

В групповом исследовании продуктовые идеи можно представить разными способами:

• контекстным сценарием;
• видео;
• макетами с комментариями;
• текстовым описанием;
• другим подходящим артефактом.

Главное условие – использовать одинаковый формат для всех сравниваемых идей.

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

Описание должно начинаться не с функции продукта, а с проблемы или возможности.
Логика:
проблема / возможность → предлагаемое решение.
Так участники понимают, зачем вообще существует концепция и какую ситуацию она должна менять.
Кроме того, все описания должны оставаться видимыми участникам на протяжении обсуждения, чтобы людям не приходилось запоминать каждую идею.

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

• записать;
• показать всем;
• повторять для каждой идеи в одинаковом порядке.

Участники должны выступать последовательно. Свободные комментарии и обсуждение допустимы, но не должны разрушать очередность.
Важно контролировать две противоположные ситуации:
молчаливые участники – им нужно адресно задавать вопросы;
доминирующий участник – ему нельзя позволять занимать всё время обсуждения.

Цель модерации – получить мнение всей группы, а не нескольких наиболее активных участников.

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

Нужно смотреть:

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

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

От идеи к проверяемому эксперименту
Вторая часть темы посвящена уже не столько видам прототипов, сколько тому, как превратить метод прототипирования в нормальное исследование.

Процесс можно представить так:
1. Сформулировать продуктовую гипотезу.
Понять, что именно должно быть ценным для пользователя.
↓
2. Выбрать минимально достаточный способ проверки.
Это может быть генератор интерфейса, бот, Wizard of Oz, консьерж или сценарий.
↓
3. Описать процесс.
Кто что делает, сколько длится эксперимент, где происходит взаимодействие.
↓
4. Определить критерии успеха.
Заранее решить, какое поведение подтвердит гипотезу.
↓
5. Провести пилот.
Убедиться, что исследование измеряет продуктовую идею, а не ошибки прототипа.
↓
6. Собрать поведенческие данные и обратную связь.
Важно сочетать наблюдаемое поведение с объяснениями пользователей.
↓
7. Интерпретировать результаты.
Понять не только, нравится ли людям идея, но и соответствует ли она их реальным потребностям и привычкам.