Прототип сайта перед разработкой: что должен получить заказчик

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

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

Чем прототип отличается от карты сайта, дизайна и технического задания

Эти артефакты связаны, но отвечают на разные вопросы.

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

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

Что должен содержать прототип сайта

1. Границы проекта и список страниц

В начале должен быть зафиксирован состав проекта. Для многостраничного сайта это карта URL или хотя бы перечень типов страниц. Для лендинга — полный порядок смысловых блоков. Для каталога — отдельные шаблоны списка, фильтра, карточки объекта и служебных состояний.

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

Полезно сразу разделить:

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

2. Цель каждой страницы и главный следующий шаг

У страницы должна быть одна понятная роль. Главная помогает выбрать направление. Страница услуги объясняет предложение и приводит к обращению. Карточка объекта помогает оценить конкретный вариант. Статья отвечает на вопрос и предлагает логичный переход к услуге или кейсу.

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

3. Реальный смысловой каркас, а не lorem ipsum

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

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

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

4. Пользовательские сценарии и переходы

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

Проверьте основные пути:

1. пользователь пришёл из поиска на страницу услуги;
2. сравнил варианты и открыл кейс;
3. вернулся к предложению;
4. выбрал способ связи;
5. заполнил форму;
6. увидел подтверждение успешной отправки.

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

5. Формы и их состояния

Прямоугольник с подписью «форма» — недостаточная спецификация. В прототипе должны быть понятны:

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

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

6. Мобильная логика

Мобильная версия — не уменьшенная копия десктопа. Ещё на этапе прототипа стоит проверить порядок блоков, длину заголовков, расположение CTA, раскрытие меню, работу таблиц, фильтров и форм.

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

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

7. SEO-основа до дизайна

Если сайт должен получать трафик из Яндекса и Google, карта спроса должна влиять на структуру до прорисовки макетов. В прототипе важно зафиксировать:

• какая группа запросов относится к каждой странице;
• один уникальный H1;
• будущие смысловые H2/H3;
• хлебные крошки и внутренние ссылки;
• место для коммерческих факторов, FAQ и доказательств;
• шаблоны Title и Description для повторяемых страниц;
• страницы, которые должны или не должны попадать в sitemap.

Это не означает, что в прототип нужно вставлять SEO-текст ради объёма. Задача — убедиться, что для подтверждённого интента существует подходящая страница и на ней есть место для полезного ответа. Более полный список подготовки есть в материале о том, что сделать до старта SEO нового сайта.

8. Правила передачи в дизайн и разработку

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

В конце полезно перечислить:

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

Какой минимум нужен для разных типов сайтов

Лендинг

Нужны последовательность блоков, главный оффер, доказательства, сценарии CTA, форма, экран успешной отправки и мобильная версия. До прототипа важно решить, действительно ли одной страницы достаточно. В этом помогает сравнение лендинга и многостраничного сайта.

Корпоративный или многостраничный сайт

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

Каталог или интернет-магазин

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

Чек-лист приёмки прототипа заказчиком

Перед согласованием ответьте на десять вопросов.

1. Все ли типы страниц и системные состояния входят в объём?
2. Понятна ли цель каждой страницы без объяснений менеджера?
3. Видно ли главное предложение в начале страницы?
4. Есть ли подтверждения обещаний: условия, примеры, команда, документы, отзывы?
5. Понятно ли, куда ведёт каждая кнопка?
6. Показаны ли ошибки и успешные состояния форм?
7. Проверен ли мобильный порядок блоков?
8. Соответствует ли структура поисковому спросу и рекламным сценариям?
9. Указано ли, какие тексты, фото и данные ещё не готовы?
10. Зафиксированы ли версия прототипа и границы следующего этапа?

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

Два примера из проектов Дзенмаркетинг

Лендинг центра подготовки к ЕГЭ

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

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

Сайт-каталог агентства недвижимости «Астория»

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

Прототип в этом проекте определил не только порядок блоков, но и будущую модель данных: каталог подключили к Google Таблицам, чтобы новые объекты можно было добавлять системно. Этот пример показывает, почему состав прототипа зависит от бизнес-модели. Подробности есть в кейсе сайта агентства недвижимости «Астория».

Красные флаги слабого прототипа

Стоит остановить передачу в дизайн, если:

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

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

Что согласовывать отдельно

Прототип не заменяет всё производство сайта. Отдельно должны быть понятны:

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

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

Следующий шаг

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

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