Приходит основатель и говорит: «Нужен прототип для инвестора». За этой фразой обычно скрывается ожидание почти готового продукта: красивые экраны, несколько переходов, ощущение, что код уже где-то рядом. Но инвестору нужен один ответ, команде - другой, а будущему пользователю вообще третий.
За последние годы я видел это много раз: ошибка с форматом съедает 1-2 недели и 200-400 тыс. ₽ еще до того, как проверена хотя бы одна гипотеза. Полезен не самый красивый прототип. Полезен тот, который дешевле всего снимает самый рискованный вопрос проекта.
Прототип, MVP и PoC решают разные задачи
Самая частая путаница начинается именно здесь. Бизнес говорит: «давайте MVP», хотя в реальности нужно понять, как человек вообще пройдет сценарий. Команда открывает Figma, обсуждает стек вроде Laravel 11 или Node.js 20 + NestJS, хотя вопрос пока не технический.
У нас был проект в B2B-логистике, где клиент просил «минимальный продукт» для инвестора и первых продаж. Через 3 дня работы с интерактивным прототипом выяснилось, что после второго шага диспетчер хочет не подтверждать заявку, а дробить ее на части. Если бы мы сразу пошли в разработку, под переделку попали бы 30-40% согласованного объема.
| Артефакт | Что проверяет | Есть backend | Когда нужен |
|---|---|---|---|
| Прототип | Сценарий, структура, UX | Нет | До оценки и до разработки |
| MVP | Реальную ценность в работающем продукте | Да | Когда гипотеза уже собрана |
| PoC | Техническую реализуемость | Частично | Когда риск в интеграции, алгоритме, нагрузке |
Частая ошибка: «Нам нужен MVP, чтобы понять путь пользователя».
Как правильно: если ответ можно получить без кода, сначала делайте прототип.
Когда идея еще спорная, грубый скетч полезнее красивого макета
Если команда еще спорит, кто главный пользователь и где возникает первая ценность, детальный интерфейс только мешает. Разговор быстро уходит в обсуждение кнопок, пустот и «убедительного вида». На этой стадии бумага, Miro или FigJam работают лучше аккуратной Figma.
У нас был SaaS для сервисных компаний, где основатели не могли договориться, продукт делается для мастера, оператора или владельца. За 90 минут в Miro мы собрали 6 экранов ключевого пути и увидели, что половина веток существует только потому, что каждый тянет логику под свою роль. В тот же день убрали 3 спорные ветки и отложили дизайн.
Такой формат особенно полезен, когда неясно:
- кто главный пользователь;
- где у него первая ценность;
- какие шаги обязательны;
- какие исключения всплывут сразу.
Разговор в такие моменты обычно звучит похоже. Кто-то предлагает сразу идти в Figma, «чтобы выглядело серьезно». Потом выясняется, что серьезно это должно выглядеть просто потому, что материал нужно кому-то показать. Но показывать пока нечего, если команда еще не договорилась о самом маршруте пользователя.
Один раз мы пошли ровно по этому пути и ошиблись. Сразу собрали детальный макет, потому что заказчику нужно было «убедительно». Через неделю почти все выбросили: спор шел о бизнес-логике, а не об интерфейсе.
Wireframe показывает тот объем, которого не видно в голове
Когда общий сценарий уже собран, нужен следующий слой точности. Здесь wireframe становится самым полезным мостом между идеей и оценкой разработки. Для бизнеса это момент, когда система впервые становится видимой целиком: роли, ошибки, пустые состояния, подтверждения, возвраты назад, права доступа.
В сервисе онлайн-записи для медицинского проекта на старте казалось, что путь пользователя укладывается в 4 экрана. После wireframe в Figma получилось 9 состояний: ошибка оплаты, возврат в запись, отмена, повторная отправка кода, ограничения по ролям, пустой слот. Смета выросла, но причина была вполне здоровой - мы увидели реальный объем, а не красивую картинку из обсуждения.
Часто wireframe воспринимают как серый черновик дизайна. На практике это рабочий документ для бизнеса, продакта и разработки. По нему уже можно разбирать список задач и не спорить потом, откуда взялись лишние недели.
Кликабельный прототип нужен тогда, когда логика уже собрана
Интерактив окупается в момент, когда базовый путь согласован и нужно смотреть поведение. Где человек зависает, куда нажимает первым, на каком шаге бросает сценарий. Для интервью, демо инвестору и передачи логики в разработку это сильный инструмент, но только если сама логика уже собрана.
В прошлом году мы делали B2B FinTech-кабинет. Собрали кликабельный прототип в Figma, за 1 неделю провели 6 интервью и увидели повторяющийся сбой: шаг верификации люди воспринимали как лишний барьер и не понимали, почему он стоит так рано. В коде такая правка обошлась бы заметно дороже.
По срокам ориентир обычно такой:
- low-fi схема - 1 день;
- wireframe основного потока - 2-4 дня;
- интерактив на 10-15 экранов - от нескольких дней до 2 недель.
Если у команды нет согласия по базовой логике, кликабельность рано включать в работу. Она создает ощущение ясности раньше, чем появляются решения.
Выбирать надо по вопросу, который тормозит проект
Я предпочитаю очень простую матрицу: сначала формулируем риск, потом выбираем артефакт. Если делать наоборот, почти всегда начинается лишняя работа.
- Нужно быстро согласовать идею с партнером - бумага, Miro, FigJam.
- Нужно понять состав экранов и оценить объем - wireframe в Figma.
- Нужно проверить сценарий на пользователях - кликабельный прототип.
- Нужно проверить интеграцию с ERP, расчет или обмен данными - PoC.
У зрелых команд прототип - это не что-то, что делают «перед стартом на всякий случай». Это способ не спутать ощущение движения с проверкой реальности. И, судя по тому, как все чаще команды начинают именно с вопроса о риске, этот подход постепенно становится нормой: меньше артефактов ради процесса, больше - ради ответа, который действительно нужен проекту.
