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

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

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

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

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

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

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

Прототип, дизайн-макет и техническое задание решают разные задачи.

Прототип отвечает на вопросы:

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

Дизайн-макет показывает визуальное оформление:

• цвета;
• типографику;
• изображения;
• сетку;
• отступы;
• стили кнопок;
• визуальные состояния элементов.

Техническое задание фиксирует требования к реализации:

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

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

Например, уже на этапе прототипа можно заметить, что:

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

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

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

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

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

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

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

Low-fidelity-прототип может состоять из:

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

Его задача — не показать, каким красивым будет сайт, а определить:

• иерархию информации;
• последовательность блоков;
• расположение CTA;
• структуру навигации;
• основные сценарии.

Такой прототип можно сделать на бумаге, в Figma, Miro или другом удобном инструменте.

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

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

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

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

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

Например:

• регистрацию;
• авторизацию;
• оформление заказа;
• работу фильтра;
• выбор тарифа;
• личный кабинет;
• многошаговую форму;
• бронирование.

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

Например, в прототипе можно:

• изменить состояние кнопки;
• показать модальное окно;
• раскрыть список;
• переключить вкладку;
• изменить значение переменной;
• смоделировать корзину;
• настроить разные ветки сценария.

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

Например, попросить участника:

Найдите товар, добавьте его в корзину и перейдите к оформлению заказа.

После этого наблюдать:

• где он сомневается;
• какие кнопки не замечает;
• где возвращается назад;
• правильно ли понимает названия разделов.

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

Для тестирования прототипов используются специализированные UX-инструменты, которые могут собирать клики, пути и результаты заданий. А уже после запуска сайта можно подключать полноценную веб-аналитику и тепловые карты пользовательского поведения. Не стоит также привязывать high-fi-прототип к универсальному сроку вроде «3–5 дней».

Время зависит от:

• количества экранов;
• числа сценариев;
• сложности логики;
• числа устройств;
• требований к детализации.

Прототип простой посадочной страницы действительно может быть подготовлен быстро, а модель сложного интернет-магазина, сервиса или личного кабинета может потребовать значительно больше времени.

По способу сборки прототипы можно разделить на несколько видов.

• Бумажный скетч.
  Подходит для быстрых идей, мозгового штурма и обсуждения структуры без привязки к инструменту.
• Онлайн-доска.
  Удобна для совместной работы над пользовательскими потоками, картой страниц и ранней структурой.
• Статичный wireframe.
  Показывает расположение элементов и структуру конкретного экрана.
• Интерактивный прототип.
  Позволяет пройти пользовательский сценарий и проверить взаимодействия.

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

• Marvel — может использоваться для построения простых кликабельных сценариев.
• Axure — подходит для прототипов со сложной логикой, состояниями и условиями.
• Tilda или Webflow — иногда используются для прототипа непосредственно в браузере, особенно когда важно проверить поведение адаптивного интерфейса.
• Figma — универсальный вариант для wireframe, дизайна и интерактивных прототипов.

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

Как мы делаем прототип

Прототипирование мы начинаем не с интерфейса Figma, а с понимания задачи бизнеса.

На первом этапе выясняем:

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

Если у компании уже есть сайт, дополнительно анализируем данные:

• Яндекс Метрики;
• Search Console;
• Яндекс Вебмастера;
• CRM;
• поискового спроса;
• существующих посадочных страниц.

Для SEO-проекта этот этап особенно важен.

Нельзя проектировать новый сайт только по принципу:

У конкурентов есть такой раздел — сделаем и у нас.

Сначала нужно понять, какие страницы необходимы исходя из:

• продукта;
• пользовательских задач;
• семантики;
• структуры спроса.

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

Обычно смотрим:

• структуру;
• меню;
• страницы услуг;
• каталоги;
• фильтры;
• формы;
• CTA;
• способы подачи коммерческой информации.

После анализа формируем информационную архитектуру:

Главная → Раздел → Подраздел → Карточка / Услуга → Целевое действие.

Затем прописываем основные пользовательские сценарии.

Для интернет-магазина:

Категория → Фильтр → Карточка → Корзина → Оформление.

Для сайта услуг:

Поисковый запрос → Страница услуги → Изучение предложения → Форма → Заявка.

Для B2B-проекта:

Категория → Технические характеристики → Условия поставки → Запрос расчёта.

Каждый сценарий проверяем на понятность. Не существует универсального правила:

пользователь должен прийти к цели максимум за три клика.

Иногда один дополнительный шаг делает интерфейс понятнее, а попытка искусственно сократить путь только перегружает предыдущий экран.

Поэтому мы смотрим не на количество кликов само по себе, а на другое:

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

После этого начинаем рисовать wireframe.
На первом этапе намеренно используем минимум декоративных деталей:

• нейтральные цвета;
• простые блоки;
• условные изображения;
• реальные или близкие к реальным заголовки.

Для важных элементов добавляем комментарии.

Например:

Здесь показываем цену после выбора параметров.

или:

При нажатии открывается форма запроса коммерческого предложения.

Первую версию передаём на согласование, собираем замечания и уточняем структуру.

Количество итераций заранее фиксировать как «две-три» необязательно. Простая страница может быть утверждена сразу, а сложный сервис потребует нескольких циклов.

Главная задача — зафиксировать логику до дорогих стадий дизайна и разработки.

Вид прототипа	Степень детализации	Когда использовать
Бумажный скетч	Минимальная	Быстрая фиксация идеи
Wireframe / low-fi	Низкая	Согласование структуры и иерархии
Интерактивный прототип / hi-fi	Средняя или высокая	Проверка UX-сценариев
HTML/CSS-прототип	Высокая	Проверка поведения в браузере и технически сложных решений
Прототип в Figma	От низкой до высокой	Совместная работа, согласование и интерактивные сценарии

Что учесть при создании прототипа

Перед передачей прототипа в дизайн необходимо пройти основные сценарии так, как это сделал бы пользователь.

Мы задаём несколько вопросов:

• Откуда человек приходит?
• Что он хочет получить?
• Понимает ли он предложение страницы?
• Видит ли следующий шаг?
• Есть ли информация, необходимая для принятия решения?
• Что происходит после целевого действия?
• Может ли пользователь вернуться назад без потери результата?

Например, для формы важно предусмотреть не только поля, но и:

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

Адаптивность тоже лучше продумывать ещё на этапе прототипа. Google продолжает использовать мобильную версию страницы для индексирования и ранжирования и рекомендует responsive design как наиболее простой в реализации и сопровождении вариант.

Поэтому мы проверяем заранее:

• меню;
• таблицы;
• фильтры;
• карточки;
• формы;
• длинные заголовки;
• кнопки;
• sticky-элементы.

При этом мобильная версия не должна просто механически повторять десктоп.

На небольшом экране может изменяться:

• порядок блоков;
• формат навигации;
• расположение CTA;
• отображение фильтров.

Но важный контент нельзя без причины исключать из мобильной версии. Google рекомендует сохранять ключевой контент и метаданные, поскольку именно мобильная версия используется для mobile-first indexing.

Отдельно проверяем реальные тексты.

Lorem ipsum позволяет быстро заполнить экран, но плохо показывает, как поведёт себя макет после добавления настоящего контента.

Поэтому для ключевых блоков лучше использовать хотя бы реалистичные:

• H1;
• подзаголовки;
• названия кнопок;
• карточки товаров;
• характеристики.

Это сразу показывает проблемы:

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

Доступность также желательно учитывать уже в прототипе.

В исходных рекомендациях часто встречается требование:

интерактивная зона должна быть минимум 44×44 пикселя.

Это не совсем актуальная формулировка для WCAG 2.2.

Критерий WCAG 2.2 уровня AA Target Size (Minimum) требует минимум 24×24 CSS px либо достаточное расстояние между более маленькими интерактивными целями; стандарт также предусматривает исключения.

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

Также стоит проверить:

• логичный порядок фокуса;
• понятные подписи элементов;
• состояние ошибки;
• использование клавиатуры;
• альтернативы действиям, которые требуют drag-and-drop.

WCAG 2.2 отдельно требует, чтобы функциональность, основанная на перетаскивании, имела альтернативный способ управления одним указателем, если само перетаскивание не является обязательным.

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

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

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

Если та же необходимость обнаружится после разработки, изменение может затронуть:

• дизайн;
• мобильную версию;
• frontend;
• backend;
• аналитику;
• тестирование.

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

Именно поэтому мы используем прототип как инструмент ранней проверки решений.

В Agile-процессе прототип может развиваться итерациями:

Гипотеза → прототип → проверка → обратная связь → корректировка.

Не обязательно ждать, пока будет спроектирован весь сайт.
Например, можно сначала проверить:

• каталог;
• карточку товара;
• корзину;

и только после этого переходить к следующему сценарию.

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

До начала разработки на прототипе можно проверить:

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

Если используются специальные платформы для usability testing, можно дополнительно собирать:

• success rate;
• misclicks;
• click maps;
• маршруты прохождения.

А вот полноценную веб-аналитику и реальные тепловые карты поведения мы подключаем уже к работающему интерфейсу или специально развёрнутой тестовой версии.

A/B-тестирование прототипа тоже возможно, но важно правильно трактовать результат. Если десять пользователей чаще выбирают вариант A, это ещё не означает, что после запуска он обязательно даст выше конверсию на реальном трафике.
На прототипе мы проверяем прежде всего UX-гипотезы, а окончательную бизнес-эффективность — на реальном продукте при достаточном объёме данных.

Поэтому вместо неподтверждённого утверждения:

прототип убирает 70% поздних правок

корректнее сказать:

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

До начала разработки мы обычно фиксируем:

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

Так прототип становится не просто картинкой для согласования, а инструментом проверки гипотез.

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

Один из самых частых вопросов — сколько времени занимает прототипирование.

Универсального срока нет.
Он зависит от:

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

При этом количество URL не всегда определяет объём работы.

Например, в интернет-магазине может быть 20 000 карточек товаров, но проектировать отдельно все 20 000 страниц не нужно — создаётся один или несколько шаблонов карточки.

Поэтому корректнее оценивать проект по количеству уникальных типов экранов и сценариев, а не просто по числу страниц сайта.

Можно ли вообще пропустить прототип?

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

Но по мере роста сложности проекта ценность прототипа увеличивается.
Особенно он полезен, когда есть:

• каталог;
• фильтры;
• корзина;
• личный кабинет;
• разные роли;
• многошаговые формы;
• сложные интеграции.

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

Ещё один вопрос — кто должен утверждать прототип.

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

• продукт;
• аудиторию;
• бизнес-процесс;
• маркетинг;
• ограничения разработки.

Для небольшого бизнеса это действительно может быть собственник. В крупной компании — product owner, руководитель маркетинга, ecommerce-команда или проектный комитет.

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

Поэтому в начале проекта мы рекомендуем определить:

• кто собирает комментарии;
• кто принимает итоговое решение;
• кто консультирует;
• кто должен только ознакомиться.

Все замечания желательно сводить в один источник.

Это снижает количество противоречивых комментариев:

Сделать кнопку выше.

и одновременно:

Убрать кнопку с первого экрана.

Прототип в итоге становится общей точкой фиксации решений между бизнесом, SEO-командой, дизайнерами и разработчиками.

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

До начала дизайна мы проверяем:

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

Так прототип помогает решить две задачи одновременно: спроектировать удобный пользовательский путь и не потерять SEO-логику сайта ещё до начала разработки.