Зачем прототип до разработки и сколько он экономит

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

Прототип — это не дизайн, не ТЗ и не MVP

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

Не ТЗ, но заменяет большую его часть. Фразу «менеджер может отменить заказ» каждый читает по-своему. Экран с кнопкой «Отменить», окном подтверждения и списком причин отмены все читают одинаково. О том, как писать само техзадание, — в заметке о ТЗ на сайт.

Не MVP. MVP работает с настоящими данными и живыми пользователями, прототип — нет. Он проверяет логику, а не спрос. Разница подробно — в заметке «Что такое MVP и как запустить его за 3–⁠6 недель».

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

Какие ошибки ловит прототип

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

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

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

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

Сама проверка выглядит просто:

Человек получает задачу — «оформите возврат» или «найдите заказ клиента, который звонил вчера» — и пытается выполнить её на прототипе. Я не подсказываю, а смотрю, где он запнулся. Каждая заминка — вопрос к логике, а не к человеку.

Как прототип сработал на B2B-платформе

ETS Tender — тендерная биржа: тендер, предложения, сделка, согласования, несколько ролей с разными правами. В таком продукте красивые экраны ничего не решают, если логика не продумана.

Я сначала разобрал роли, сценарии и потоки данных, зафиксировал правила системы и собрал канбан-модель тендеров, сделок и согласований. Потом проверил логику на прототипах и только после этого рисовал интерфейсы. Ошибки в логике были найдены и убраны там, где их исправление стоит минуты, а не недели разработки.

Когда вместо прототипа — сразу рабочая версия

Иногда быстрее проверить идею не на серых экранах, а на работающей версии с настоящими данными. Так было с Audi Centre Almaty. У дилера уже были выгрузки по машинам в наличии, словари опций и комплектаций — из них можно было сразу собирать коммерческое предложение. Первая рабочая версия конструктора появилась через три дня после старта, и менеджеры отправляют КП через неё.

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

Что остаётся после прототипа

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

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

Как оценить экономию для своего проекта

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

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

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

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

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