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

Разберём, что такое вайрфрейм, прототип и макет, чем они отличаются и в каком порядке появляются в реальных проектах.

Вайрфрейм: скелет без кожи

Вайрфрейм (wireframe) — это схема страницы. Никаких цветов, никаких шрифтов, никаких картинок. Только блоки, прямоугольники и подписи: «здесь заголовок», «здесь список товаров», «здесь форма обратной связи».

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

Вайрфрейм делается быстро. Иногда это просто карандашный набросок на листе A4. Иногда — схема в Figma или Miro с серыми прямоугольниками. Главное, что на этом этапе не тратится время на детали, которые потом всё равно поменяются.

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

  • Сколько секций на странице?
  • Где кнопка заказа — вверху или после блока с ценами?
  • Нужен ли блок с отзывами?
  • Что важнее — фото блюд или список преимуществ?

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

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

Прототип: вайрфрейм, который кликается

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

Прототипы делают в тех же инструментах: Figma, Adobe XD, Axure, Marvel. Дизайнер связывает экраны переходами — и получается симуляция работы интерфейса.

Зачем это нужно? Есть вещи, которые невозможно проверить на статичной схеме:

  • Насколько удобно пользователю найти нужный раздел?
  • Понятно ли, что это кнопка, а не просто текст?
  • Не слишком ли длинный путь от главной до оформления заказа?

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

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

Два типа прототипов. Низкодетализированный (lo-fi) — быстрый, схематичный, для ранних тестов. Высокодетализированный (hi-fi) — практически готовый дизайн с реальным контентом, который уже близок к финальному макету. Граница между hi-fi прототипом и макетом иногда размытая — зависит от того, используется ли он для тестирования или для передачи разработчикам.

Макет: финальный дизайн

Макет (или мокап — от англ. mockup) — это финальное визуальное решение. Здесь уже всё: цвета бренда, конкретные шрифты с заданными размерами, реальные фотографии, иконки, отступы до пикселя.

Макет делается в Figma (сейчас это стандарт индустрии), реже — в Sketch или Adobe XD. На выходе дизайнер передаёт разработчику файл, где всё размечено: какой цвет у фона, какой радиус у кнопки, какой межстрочный интервал у абзаца.

Хороший макет содержит:

  • Все состояния элементов: обычное, при наведении, активное, неактивное, с ошибкой
  • Адаптивные версии: десктоп, планшет, мобильный
  • Реальный контент, а не lorem ipsum — чтобы видеть, как текст ведёт себя в блоках
  • Компонентную структуру — кнопки, карточки, заголовки оформлены как переиспользуемые элементы

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

Как эти три этапа связаны

Линейный процесс выглядит так:

  1. Аналитика и ТЗ
  2. Вайрфрейм — структура и логика
  3. Прототип — тест сценариев
  4. Макет — финальный визуал
  5. Разработка

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

Ключевое правило: чем раньше найдена проблема, тем дешевле её исправить. Схема иерархии стоимости примерно такая:

  • Исправить на вайрфрейме: условно бесплатно
  • Исправить на прототипе: час-два работы дизайнера
  • Исправить в макете: несколько часов, возможно переделка нескольких экранов
  • Исправить в готовой разработке: от дня до недели работы разработчика
  • Исправить после релиза: плюс репутационные потери

Когда можно пропустить этапы

Не каждый проект требует полного цикла. Вот практические ориентиры.

Сайт-визитка или лендинг для малого бизнеса. Если бюджет небольшой (сайт-визитка стартует от 2 000 ₽, лендинг — от 3 500 ₽), делать полноценный прототип с тестированием экономически не оправдано. Достаточно вайрфрейма для согласования структуры и финального макета. Прототип пропускается.

Корпоративный сайт с несколькими разделами. Здесь вайрфрейм уже важен — нужно согласовать навигацию, иерархию разделов, логику CTA. Прототип желателен хотя бы в lo-fi варианте.

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

Сложный веб-сервис или SaaS. Здесь прототип — не опция, а необходимость. Иногда прототипирование занимает больше времени, чем разработка.

Кто что делает

В разных командах роли распределяются по-разному. Но есть типичная картина:

UX-дизайнер — делает вайрфреймы и прототипы. Его работа — логика, удобство, сценарии. Он не думает о красоте, он думает о том, как пользователь пройдёт путь от входа до цели.

UI-дизайнер — делает финальный макет. Его работа — визуал: цвета, типографика, иконки, анимации. Он берёт скелет от UX и одевает его.

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

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

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

На что смотреть при приёмке каждого этапа

Если вы заказываете дизайн и хотите принять каждый этап осознанно, вот чек-лист.

Вайрфрейм — проверяйте:

  • Все ли разделы/страницы учтены?
  • Понятна ли иерархия информации на каждой странице?
  • Есть ли все нужные блоки (форма, цены, отзывы, контакты)?
  • Логична ли навигация?

Не смотрите на красоту — её здесь нет и не должно быть.

Прототип — проверяйте:

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

Макет — проверяйте:

  • Соответствует ли визуал бренду (цвета, шрифты)?
  • Есть ли мобильная версия?
  • Прописаны ли состояния элементов (hover, focus, error)?
  • Соответствует ли реальный контент тому, что в макете (не lorem ipsum)?

Частые ошибки

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

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

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

Пропускать мобильную версию в макете. Адаптив — это не «потом сам разберётся разработчик». Это отдельный дизайн с другой логикой компоновки. Если в макете нет мобильной версии, это не готовый макет.

Инструменты, которые используют в 2026 году

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

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

Axure остался нишевым инструментом для сложных интерактивных прототипов с условной логикой — там, где Figma не справляется.

Eskiiz и Balsamiq используются редко, но встречаются в некоторых командах для lo-fi вайрфреймов.

Как это работает у нас

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

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

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