Прототип сайта - это схема будущих экранов без дизайна и без верстки: блоки, тексты-заглушки, порядок разделов и связи между страницами. Я делаю его на старте почти каждого проекта, будь то лендинг на Tilda или интернет-магазин на WordPress, потому что правки на этом этапе стоят часов работы, а не недель переделки готового сайта. Дальше объясняю, зачем клиенту вообще тратить время на согласование прототипа, какие виды макетов встречаются на практике и по какому чек-листу я сам принимаю прототип, когда над проектом работает не один человек.
Зачем нужен прототип сайта на старте проекта
Пока сайт существует в виде серых блоков без цвета и шрифтов, любое изменение занимает пять минут: подвинуть блок, убрать раздел, поменять местами кнопки. Как только та же структура превращается в дизайн-макет с иллюстрациями и подобранной типографикой, любая правка тянет за собой пересборку соседних блоков. А если структуру меняют уже после верстки, это выливается в переписывание кода и повторное тестирование форм.
На практике клиенты чаще всего просят добавить новый раздел или поменять порядок блоков именно на этапе прототипа, а не после того, как увидели готовый дизайн. Пока перед глазами нет ярких картинок и логотипа, проще оценивать логику: как посетитель попадает с главной страницы в каталог, сколько кликов до формы заявки, где на странице стоит кнопка оплаты. Прототип отвечает на вопрос, работает ли эта схема, а не на вопрос, красиво ли это выглядит.
Есть и вторая причина держать этот этап отдельно. Пока структура не зафиксирована, легко посчитать честную смету: количество уникальных блоков видно сразу, а не угадывается по общему впечатлению от будущего сайта. Поэтому я всегда фиксирую прототип отдельным этапом с явным подтверждением заказчика в переписке, прежде чем переходить к дизайну.
Виды прототипов: от скетча до кликабельного макета
На разных этапах проекта я использую разный уровень детализации, и не всегда имеет смысл сразу делать самый подробный вариант.
| Вид прототипа | Что показывает | Когда использую |
|---|---|---|
| Скетч на бумаге или доске | Общую идею структуры, без привязки к размерам блоков | На первой встрече, чтобы быстро проверить идею с клиентом |
| Wireframe | Расположение блоков, разделов и текстовых зон в масштабе будущей страницы | Для согласования структуры каждой страницы перед началом дизайна |
| Кликабельный прототип | Переходы между экранами: кнопки и ссылки ведут на нужные страницы прямо в макете | Для сложных сценариев вроде многошаговой формы заказа или личного кабинета |
Кликабельный прототип я собираю в Figma: у неё открытый API, поэтому связи между экранами и структуру проекта можно потом выгрузить или подключить к другим инструментам команды. Для простого лендинга обычно достаточно wireframe. Для интернет-магазина или сервиса с личным кабинетом без кликабельного прототипа сложно проверить, не потерялся ли пользователь на полпути к оплате. Смешивать уровни детализации на одном этапе не стоит: если часть страниц нарисована схематично, а часть уже с кликабельными переходами, заказчику сложно понять, что из этого финальная версия, а что черновик.
Что должно быть в макете сайта перед утверждением
Прототип, который можно подписывать, отвечает на несколько вопросов сразу, а не просто показывает примерное расположение блоков.
Структура и разделы
Каждая страница сайта видна целиком: из чего состоит главная, что идёт в каталоге, какие блоки есть на карточке товара. Если раздел на сайте появится позже, а в прототипе его не было, это уже не мелкая правка, а новая задача со своей оценкой.
Логика форм и кнопок
В прототипе указано, что происходит после нажатия кнопки «Отправить» или «Купить»: переход на страницу благодарности, всплывающее окно, письмо на почту. Без этого верстальщик или программист додумывает поведение сам, а потом переделывает его под то, что клиент представлял иначе.
Адаптив для мобильных
Хотя бы ключевые страницы показаны в мобильной версии, а не только в десктопной. У многих моих клиентов больше половины трафика приходит с телефона, и то, что удобно умещается на широком экране, на мобильном нередко требует другого порядка блоков. Если мобильная версия не проработана на этом этапе, дизайнер и верстальщик решают спорные места по-своему, и итоговый вид на телефоне может не совпасть с тем, что представлял себе заказчик.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Чек-лист приёмки прототипа: 5 пунктов, которые проверяю
Когда прототип приходит на согласование, я прохожу по одному и тому же списку, чтобы не подписать макет, который потом придётся пересобирать.
- Все страницы из технического задания представлены в прототипе, ни один раздел не потерялся.
- У каждой формы понятно, какие поля обязательны и что происходит после отправки.
- Переходы между страницами проверены кликами, а не только описаны словами в комментариях к макету.
- Мобильная версия ключевых страниц показана отдельно, а не оставлена на усмотрение верстальщика.
- Тексты-заглушки по длине близки к реальным, чтобы наполнение не сломало блок.
Пятый пункт чаще всего пропускают. Макет с текстом-заглушкой вроде «Текст текст текст» выглядит аккуратно, а как только его заменяют на реальное описание товара в три раза длиннее, блок расползается. Поэтому я прошу заказчика присылать хотя бы примерные тексты уже на этапе прототипа, а не после утверждения дизайна. Если хотя бы один из пяти пунктов не выполнен, я возвращаю прототип на доработку, а не подписываю его с оговоркой «поправим по ходу дела».
Ошибки при согласовании структуры сайта, которые дорого исправлять потом
Утверждение прототипа «по диагонали» встречается чаще всего: клиент бегло смотрит на макет, кивает, а через неделю после сдачи дизайна вспоминает, что забыл раздел с отзывами. Правки на этом этапе уже требуют пересмотра сметы, а не бесплатной доработки.
Отсутствие мобильной версии в прототипе тоже аукается позже. Если весь макет собран только под десктоп, часть решений о порядке блоков принимается вслепую, и на мобильной версии всё равно придётся что-то менять уже во время верстки.
Прототип без логики переходов создаёт похожую проблему. Когда в схеме нарисованы экраны, но не показано, как пользователь переходит от каталога к оплате, дизайнер и разработчик достраивают сценарий каждый по-своему, и в итоге он не совпадает ни с ожиданием клиента, ни друг с другом.
Добавление разделов после подписания прототипа обходится дороже всего. Новый раздел «Кейсы» или «Отзывы», добавленный на этапе дизайна, тянет за собой изменение меню, футера и внутренних ссылок на всех страницах, где они уже были заложены. Все три ошибки объединяет одно: правки, не замеченные на этапе прототипа, всплывают на более позднем и более дорогом этапе, где их исправление требует пересборки уже готовых экранов.
Как прототип влияет на сроки и бюджет разработки
Смета на разработку сайта считается от объёма и сложности блоков, которые видны в прототипе. Лендинг на Next.js у меня стоит от 80 000 ₽, сайт на WordPress от 60 000 ₽, сайт на Tilda от 30 000 ₽, и в каждом случае цифра завязана на количество страниц и уникальных блоков, а не на угадывание объёма после старта работ.
Если по итогам прототипирования становится понятно, что задача выросла до полноценного каталога с фильтрами, корзиной и оплатой, я предупреждаю об этом сразу и пересчитываю смету на интернет-магазин под ключ, а не подгоняю проект под старую цифру за счёт качества.
Изменения, внесённые после утверждения прототипа, я оцениваю отдельно, как дополнительную задачу, а не как часть исходной сметы. Это справедливо в обе стороны: заказчик платит за реально добавленный объём, а не за фиксированную ставку, которая не учитывала новый раздел. Если непонятно, какой объём работ ляжет в основу будущего прототипа, обсуждаю задачу на консультации до того, как берусь за макет.
Частые вопросы
Сколько времени занимает разработка прототипа сайта?
На практике wireframe для лендинга из 4-5 экранов готов за 2-3 дня. Кликабельный прототип для интернет-магазина с личным кабинетом занимает дольше, потому что нужно продумать переходы для каждого сценария: регистрация, оформление заказа, отслеживание доставки.
Нужен ли дизайн, чтобы утвердить прототип?
Нет, и в этом смысл этапа. Прототип собирается в серой палитре без иллюстраций и подобранных шрифтов, чтобы обсуждение шло про структуру и логику, а не про цвет кнопки. Дизайн приходит следующим этапом, уже поверх утверждённой схемы.
Можно ли менять прототип после его согласования?
Технически можно в любой момент, вопрос в стоимости. Правки, которые меняют структуру страниц уже после утверждения прототипа и начала дизайна, я оцениваю как дополнительную задачу, потому что переделка затрагивает не только один экран, а связанные с ним блоки.
Чем прототип отличается от дизайн-макета?
Прототип показывает расположение блоков и логику переходов. Дизайн-макет показывает, как это будет выглядеть с реальными цветами, шрифтами, фотографиями и иконками. Прототип отвечает на вопрос, что где находится, дизайн на вопрос, как это выглядит.