Зачем нужен прототип сайта

Дорогой способ найти, что кнопка не там

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

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

Визуал и сценарий легко перепутать. Разница слоёв: UX и UI: в чём разница. Прототип стоит на стороне сценария. UI без него — обои на неразмеченной квартире.

Что прототип показывает, а ТЗ — нет

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

Прототип раскладывает блоки. Видно, что человек сделает глазами за первые секунды. Видно, хватает ли места под реальные названия услуг, а не под «Lorem». Видно, не разъедется ли шапка, когда пунктов станет на два больше.

Без прототипа команда согласовывает референсы. Референс всегда чужой: чужой объём текста, чужие ограничения, чужая форма. Перенос «как у них» ломается на ваших полях.

Какие экраны прототипировать

Не все подряд. Ключевые шаблоны:

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

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

Мобильная ширина в прототипе обязательна, если доля заходов с телефона для вас не анекдот. Десктопная простыня, сжатая потом «как получится», — частая причина мелких кнопок и форм, которые закрывает клавиатура.

Кто сидит на прогоне и какой детализации не хватает

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

Низкая и ложная детализация

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

Какой глубины достаточно

Для большинства бизнес-сайтов хватает низкой детализации: блоки, подписи, кнопки, пометки «здесь список из CMS». Высокая детализация (каждый отступ) уже мимикрирует под UI и снова уводит в вкус.

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

Один прогон с человеком вне проекта стоит дороже десятка внутренних «нам нравится». Дайте задачу: «оставьте заявку на услугу X». Молчите. Смотрите, где он застрял.

Что прототип экономит

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

Он не экономит содержание. Пустые блоки так и останутся пустыми, если тексты не сданы. Прототип с честными заголовками из ваших услуг полезнее, чем идеальная сетка с «Заголовок услуги».

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

Возражение «мы сразу видим дизайн»

Иногда заказчик просит «сразу красиво, без серых квадратов». Это можно сделать после короткого прототипа, не вместо. Два круга визуала без схемы обычно стоят дороже одного круга схемы и одного круга UI. Если бюджет жёсткий, режьте число шаблонов в визуале, не выкидывайте проверку маршрута.

Как принимать прототип

Не фразой «в целом ок». Чек-лист:

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

После приёмки визуал наследует сетку и приоритет блоков. Спорить о палитре можно. Спорить «а давайте форму уберём, портит» — уже изменение постановки, не вкуса.

Рабочий контур «структура → прототип → визуал → вёрстка» как раз и есть нормальная разработка сайта, а не заказ «сразу в Figma красиво».

Когда можно без отдельного артефакта

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