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

Что такое прототип сайта и почему без него не обойтись

Прототип, макет, ТЗ: в чём разница

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

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

На практике мы обычно собираем прототип до того, как показываем клиенту первые дизайн-концепции. Это экономит бюджет: правка прямоугольников и стрелок стоит в разы дешевле, чем перерисовка экранов. Бизнес видит структуру будущего сайта и может оценить, как будут расположены ключевые блоки, а команда получает понятное задание для дизайнера и разработчика. В 2026 году это стандарт для любого вменяемого проекта, независимо от его масштаба.

Какие бывают прототипы: от скетча до кликабельного

Прототип низкой детализации: быстро и дёшево

На старте проекта не нужен пиксель-перфект. Достаточно бумажного скетча или серой схемы в Figma: прямоугольники, линии, заглушки текста. Такой прототип собирается за пару часов и показывает структуру, иерархию блоков и логику переходов, а не визуал. Мы обычно рисуем low-fi макеты на этапе брифа с клиентом, чтобы зафиксировать договорённости до того, как вложим часы в дизайн.

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

Интерактивный прототип: когда нужен и что умеет

Кликабельный прототип собирают в Marvel, Figma или Axure, когда нужно проверить сценарии: регистрацию, оформление заказа, личный кабинет. Он имитирует поведение реального сайта: переходы, выпадающие списки, состояния кнопок. На таком прототипе мы проводим первые юзабилити-тесты с реальными пользователями и выявляем проблемные зоны до написания кода. После итераций нередко подключаем тепловую карту сайта, чтобы понять, куда смотрят и где застревают глаза.

Интерактив не заменяет дизайн и вёрстку, но экономит бюджет: ошибки в логике на этом этапе стоят копейки, а после запуска уже тысячи. Средний high-fi прототип в Figma с автолейаутами и компонентами собирается за 3–5 рабочих дней на типовой лендинг. Для интернет-магазина с каталогом и корзиной срок вырастает до двух недель, зато потом дизайнеры не переделывают экраны по десять раз.

По способу сборки прототипы делятся на несколько видов. Бумажный скетч с карандашом и стикерами удобен для мозгового штурма внутри команды, когда нужно быстро набросать идеи и не отвлекаться на инструменты. Онлайн-доска в Miro с проводами и заметками выручает при удалённой работе: все участники видят изменения в реальном времени и оставляют комментарии прямо на схеме. Статичные wireframe в Figma, серые каркасы с пометками, чаще всего используются для согласования структуры с заказчиком, который хочет увидеть расположение блоков до проработки визуала.

• Кликабельный прототип в Marvel: быстрая сборка переходов без программирования.
• Динамический макет в Axure: сложная логика, условия и переменные для крупных порталов.
• Прототип в Tilda или Webflow: сразу верстается и тестируется в браузере.
• Интерактивный прототип в Figma: автолейауты и компоненты для детальной проработки сценариев.

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

Как мы делаем прототип: пошаговый процесс

Шаг 1. Собираем требования и анализируем конкурентов

Начинаем не с Figma, а с брифования и разбора бизнес-задач. Спрашиваем клиента, кто целевая аудитория, какие действия на сайте критичны для продаж, что уже не работает в текущей версии. Параллельно смотрим 5–7 прямых конкурентов: фиксируем их структуру, логику подачи информации и типовые ошибки. Часто находим удачные решения, которые можно адаптировать под нишу клиента, но без слепого копирования, иначе сайт потеряет индивидуальность. На выходе фиксируем список требований и ограничений, который становится базой для всех дальнейших шагов.

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

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

Что учесть при создании прототипа: чек-лист

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

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

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

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

Прототип в Agile: как он экономит бюджет и сроки

Почему правки в прототипе в 10 раз дешевле правок в дизайне

В классическом водопадном процессе ошибка, обнаруженная на этапе вёрстки, тянет за собой переделку макетов, согласование с клиентом и сдвиг сроков. В Agile всё иначе: прототип становится той точкой, где цена ошибки минимальна. Мы обычно считаем так: изменить блок на бумажном скетче стоит час работы аналитика, в Figma это уже полдня, а после старта разработки правка той же логики превращается в задачу на два-три дня с риском задеть соседние модули.

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

• Замеряем время на выполнение ключевого сценария, например оформление заказа, на реальных пользователях.
• Проверяем, понимает ли аудитория навигацию без подсказок модератора, и фиксируем «застревания».
• Сравниваем два варианта расположения конверсионных элементов, например кнопки и формы, на A/B-тесте прототипа.
• Собираем тепловые карты кликов в сервисе типа Hotjar, чтобы увидеть, куда пользователи жмут интуитивно.
• Фиксируем вопросы и возражения, которые возникают у испытуемых при взаимодействии с интерфейсом.
• Сверяем результаты с целями бизнеса и отсекаем сценарии, которые не окупают разработку.

На практике это экономит не только деньги, но и нервы. Был кейс интернет-магазина, где на прототипе выяснилось, что пользователи не понимают, как добавить товар в корзину из карточки: кнопка терялась на фоне фото. Переделка одного экрана обошлась в пару часов работы аналитика, а если бы ошибка ушла в дизайн и вёрстку, мы бы потеряли минимум неделю. В другом проекте юзабилити-тест показал, что форма из 8 полей отпугивает 40% трафика, и мы сократили её до 4 полей ещё до того, как дизайнер начал отрисовку. Так что прототип в Agile это не просто схема, а инструмент управления рисками, который окупает себя на каждом спринте.

Частые вопросы клиентов о прототипах

Чаще всего нас спрашивают, сколько времени занимает прототипирование. Если говорить о типовом корпоративном сайте или интернет-магазине с 20–30 страницами, то черновой вариант появляется за 3–5 рабочих дней. Ещё пара дней уходит на согласование и правки, если клиент отвечает быстро. Для сложных порталов с личным кабинетом сроки растягиваются до двух недель. Лучше закладывать этот этап в общий график проекта, а не пытаться втиснуть его в неделю перед стартом дизайна, иначе получится скомканный результат, который не сэкономит, а добавит работы.

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

Утверждать прототип должен тот, кто принимает конечный результат, а не менеджер-посредник. На практике это владелец бизнеса или коммерческий директор, потому что именно они видят, как прототип сайта отражает логику продаж и пользовательские сценарии. Если оставить решение за маркетологом, а потом подключить собственника, правки неизбежны. Чтобы не разводить лишние итерации, мы просим клиента собрать у себя внутри группу согласования до старта и на этапе демонстрации прототипа фиксируем все замечания в одном документе. Это снимает 80% вопросов на следующих стадиях. В агентстве Cinar мы как раз строим процесс так, чтобы прототип становился точкой принятия решений, а не формальностью, поэтому он напрямую влияет на итоговую стоимость разработки.

Часто задаваемые вопросы

Кирилл Токарев

Senior SEO-специалист

Подписаться на ТГ