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

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

Прототипы бывают двух уровней. Низкодетализированный, или low-fi, — статичные схемы экранов, которые можно показать на созвоне и обсудить, как раскладку на бумаге. Кликабельный — те же экраны, но связанные переходами: нажали «Записаться» в шапке — попали на форму, нажали услугу в списке — открылась её страница. Кликабельный нужен, когда на сайте есть путь длиннее одного экрана: каталог с фильтрами, личный кабинет, многошаговая заявка. Для сайта услуг из десяти типовых страниц чаще хватает low-fi плюс отдельной схемы «откуда и куда ведут кнопки».

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

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

Точные множители мы не называем — они зависят от сложности страницы и от того, кто вносит правку. Но порядок именно такой: минуты, часы, дни. И правок в проекте не одна и не две. Типичная история без прототипа: клиент видит первый дизайн-макет, и выясняется, что оффер сформулирован не так, порядок услуг не совпадает с приоритетами продаж, а форму нужно перенести с середины страницы на первый экран. Дизайнер переделывает. Второй круг — уже мелочи, но их пятнадцать. Каждый круг — согласование, ожидание, ещё правки. Так дизайн лендинга растягивается на месяц там, где сама отрисовка занимает несколько дней.

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

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

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

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

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

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

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

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

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

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

Первая — утверждать прототип с «рыбой» вместо реальных текстов. Схема с надписями «Заголовок услуги» и «Описание преимущества 1» выглядит аккуратно, но не проверяет ничего: клиент утверждает раскладку, а не смысл. Реальный оффер потом окажется в полтора раза длиннее, три преимущества превратятся в шесть, и блок, который на прототипе выглядел компактным, в дизайне поплывёт. Мы не показываем прототип клиенту, пока в нём нет живых текстов первого экрана, названий услуг и подписей на кнопках — даже если это черновые формулировки, которые потом отшлифует редактор.

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

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

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

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

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