«Нам нужен MVP за 3 месяца» - с этого начинается много первых созвонов. Потом мы садимся на discovery-сессии, раскладываем сценарии, и из «быстрого старта» постепенно вылезают 4 роли, биллинг, админка, уведомления, аналитика и мобильная версия «не сейчас, но сразу учтите». После прототипа такие проекты часто теряют 20-40% первой версии, и срок в 12 недель наконец становится похож на рабочий план.
По сути, вопрос почти никогда не в том, нужен ли прототип вообще. Вопрос в другом: какую неопределенность стоит снять до кода, а какую можно оставить на первую итерацию. Это напрямую влияет и на бюджет, и на то, в каком месте команда начнет переделывать уже написанное.
Код может идти быстро, а продукт в этот момент еще не собран
Сразу идти в разработку приятно. Репозиторий создан, задачи двигаются, в Jira закрываются тикеты, команда чувствует темп. На деле это нередко просто дорогой способ думать о продукте уже в коде.
Прототип проверяет механику: кто что делает, в каком порядке, где зависает, где бросает процесс, что происходит при ошибке. Если эту логику не собрать заранее хотя бы в FigJam и Figma, проблемы всплывают позже - в API, ролях, интеграциях и повторной верстке.
У нас был B2B SaaS для сервисной компании. Изначально клиент хотел CRM-модуль, кабинет сотрудников и блок отчетов. На кликабельном сценарии стало видно, что главная ценность вообще в другом: заказчик должен согласовать заявку с телефона за 3 клика. Два модуля ушли из первой версии, а оценка сжалась с 14 недель до 10.
Обычно 5 интервью по прототипу дают больше пользы, чем две недели внутренних обсуждений. Пока люди не начинают нажимать на кнопки, они очень уверенно спорят о функциях.
Путаница начинается в терминах, а заканчивается в смете
Команды часто смешивают прототип, MVP, мокап и ТЗ в одну кучку. Потом удивляются, почему вроде бы «все согласовали», а оценка все равно плавает в два раза. Здесь полезно держать простую рамку:
| Артефакт | Что проверяет | Когда нужен |
|---|---|---|
| PoC | можно ли это собрать технически | сложные интеграции, нагрузка, ограничения стека |
| Prototype | понятен ли сценарий и путь пользователя | до оценки и старта разработки |
| MVP | нужна ли ценность рынку в рабочем виде | после снятия главных рисков |
| ТЗ | что именно делаем | когда сценарий уже согласован |
В fintech-проекте мы это поймали на KYC-сценарии. Красивые статичные экраны выглядели убедительно, но в интерактивном прототипе пользователь после отказа проверки просто не понимал, что делать дальше: повторить попытку, загрузить новый документ или писать в поддержку. Для команды это было «и так очевидно», для пользователя - нет.
После перехода со статичных макетов на кликабельный сценарий число спорных вопросов по оценке у нас в таких проектах обычно падает с 40+ до 10-15. Грубо говоря, меньше допущений - меньше неожиданных недель в смете.
Формат прототипа выбирают по риску
Я видел две крайности. Первая - делать слишком детальный high-fi слишком рано. Вторая - пытаться проверить сложный продукт на схеме из прямоугольников, где не видны состояния, ошибки и переходы. Оба варианта съедают время.
Для маркетплейса под NDA мы в прошлом году разделили подготовку на два трека. Покупательский путь собрали в high-fi прототипе в Figma, а интеграцию с поставщиками проверили отдельным PoC на Node.js 20 + NestJS. Это сэкономило почти 4 недели, потому что UX-риск и технический риск не смешались.
Рабочая рамка обычно такая:
- 2-3 дня на wireframe и структуру;
- 1 неделя на low-fi clickable для ранних тестов;
- high-fi - когда продукт надо показывать инвестору или крупному заказчику;
- PoC - когда вопрос в API, производительности или ограничениях интеграции.
Если оценка после этого все еще гуляет в 2-3 раза, сценарий сырой. Когда разброс спускается хотя бы в район 15-25%, в разработку можно идти спокойнее.
Самые опасные продукты выглядят простыми
Сложные системы хотя бы настораживают. «Простой сервис заявок» или «внутренний кабинет» часто проходят без лишних вопросов, и в этом как раз ловушка. Люди слишком рано начинают думать, что уже договорились.
Когда команда говорит «тут все просто», я обычно прошу нарисовать путь пользователя. В этот момент простота быстро заканчивается.
Неудачный кейс у нас тоже был. Внутренний сервис заявок для логистической компании решили делать без прототипа: процесс всем знаком, роли понятны, что здесь обсуждать. Через месяц разработки выяснилось, что у продаж, поддержки и операционного блока разные ожидания по статусам, SLA и уведомлениям. Пришлось переделывать роли, API-контракты и кусок фронтенда на уже работающем Laravel 11 + PostgreSQL 16. Потеряли 4 недели и около 900 тыс. ₽ бюджета. Я такие истории запоминаю лучше удачных, потому что они быстро отрезвляют. С тех пор на похожих проектах сначала прошу показать путь пользователя, а уже потом обсуждаю стек.
При этом не каждому проекту нужен большой этап прототипирования. Лендинг, промо-страница или типовой корпоративный сайт с одной ролью и коротким сценарием часто можно запускать быстрее.
Что проверить перед стартом, чтобы не платить за догадки
Перед разработкой я обычно смотрю на четыре вещи:
- согласованы 3-5 ключевых сценариев;
- понятны роли и права доступа;
- есть ошибки и нестандартные состояния, а не только «идеальный путь»;
- граница между MVP и следующим этапом зафиксирована.
Если на любой из этих пунктов команда отвечает длинно, с оговорками и спорами, код пока рано. Для быстрых проверок иногда хватает Maze, Lyssna или Useberry - это дешевле, чем еще неделя внутренних обсуждений без живой реакции пользователей.
Я сам когда-то начинал код слишком рано, потому что хотелось скорости и видимого прогресса. Сейчас совет простой: перед стартом спросите не «нужен ли нам прототип», а «какая ошибка через два месяца будет самой дорогой». Если ответ неприятный, лучше сломать сценарий за один день в Figma, чем за 1,5 млн ₽ в проде.
