Wireframe, прототип, макет — в чём разница и зачем это знать

Клиент приходит в студию и говорит: «Хочу сначала посмотреть макет». Дизайнер кивает и делает wireframe. Клиент видит серые прямоугольники и расстраивается — он ждал что-то красивое. Знакомая история?

Проблема в том, что wireframe, прототип и макет — три разных артефакта с разными целями. Их часто используют как синонимы, но это всё равно что называть эскиз, чертёж и рендер одним словом «рисунок». Технически верно, практически бесполезно.

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

Wireframe — скелет будущего сайта

Wireframe — это схема. Чёрно-белая, иногда серая, раскладка элементов на странице без какого-либо дизайна. Никаких цветов, шрифтов, фотографий — только блоки, линии и подписи.

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

Зачем это нужно

Wireframe отвечает на вопрос «что и где будет на странице», не отвечая на вопрос «как это будет выглядеть». Это принципиально важно.

На этапе wireframe проектировщик думает о логике, а не об эстетике:

• Где пользователь нажмёт первым делом?
• Какой блок важнее — с отзывами или с ценами?
• Куда деть форму обратной связи, чтобы она не мешала, но была заметна?

Когда не тратишь время на выбор цвета кнопки, легче думать о структуре. Поэтому wireframe — инструмент мышления, а не презентации.

Когда делают wireframe

В самом начале работы, после брифа и исследования. До того как дизайнер открыл Figma с чистыми холстами и начал рисовать что-то «красивое».

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

Инструменты

Wireframe рисуют в чём угодно: Figma, Balsamiq, Whimsical, Miro, даже от руки на бумаге. Главное — скорость и простота. Balsamiq специально сделан «некрасивым», чтобы никто не воспринимал wireframe как финальный результат.

Типичное время на wireframe главной страницы среднего сайта — 2–4 часа.

Макет — дизайн без движения

Макет (его ещё называют мокапом или hi-fi дизайном) — это визуальное воплощение страницы. Здесь уже есть цвета, шрифты, фотографии, иконки, отступы — всё как в готовом продукте. Но это статичная картинка: на неё нельзя нажать, она ничего не делает.

Если wireframe — это скелет, то макет — это тело в финальном виде. Выглядит как скриншот готового сайта.

Зачем нужен макет

Согласование визуала. Клиент видит, как сайт будет выглядеть, и говорит «да» или «нет, сделайте синий». Это лучше, чем когда разработчик верстает наугад, а потом переделывает всё с нуля.

Передача в разработку. Разработчик смотрит на макет и знает: тут отступ 24px, шрифт Inter 16px Regular, кнопка такого-то цвета с таким-то радиусом скругления. Без макета он будет угадывать.

Презентация идеи. Иногда клиенту нужно показать концепцию инвесторам или руководству — wireframe для этого не подходит, а макет справится.

Сколько экранов делать

На простой лендинг — 5–10 экранов (десктоп плюс мобильная версия). На корпоративный сайт — 20–40 и больше. На интернет-магазин — несколько десятков, потому что нужны: главная, каталог, карточка товара, корзина, чекаут, личный кабинет, страница ошибки.

Десктоп и мобайл — это разные макеты

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

Инструменты

Сегодня отраслевой стандарт — Figma. Раньше использовали Sketch (Mac-only) и Adobe XD. Figma выиграла потому что работает в браузере, позволяет совместную работу в реальном времени и бесплатна для большинства случаев.

Прототип — макет, который работает

Прототип — это интерактивная версия макета. Блоки и экраны из Figma связываются переходами: нажимаешь кнопку — открывается следующий экран, нажимаешь крестик — закрывается модальное окно.

Прототип — это ещё не сайт, но уже не просто картинка. Это симуляция пользовательского опыта.

Зачем нужен прототип

Проверить UX до разработки. Можно дать прототип реальным пользователям и посмотреть, как они с ним взаимодействуют. Заходят туда, куда ожидаешь? Понимают, куда нажимать?

Пример: сделали прототип интернет-магазина, дали 5 людям добавить товар в корзину и оформить заказ. Оказалось, что 4 из 5 не находят кнопку «Оформить» — она потерялась среди другой информации. Исправить в Figma — 10 минут. Исправить после разработки — полдня работы верстальщика и бэкендщика.

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

Уточнить технические требования. Разработчик, кликая по прототипу, понимает, какие анимации и переходы нужно реализовать. Без прототипа это обсуждают словами и часто понимают по-разному.

Когда прототип нужен обязательно

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

Для простого лендинга в 5 секций прототип часто избыточен — там нечего тестировать.

Уровни детализации

Прототипы бывают разные по «точности»:

Lo-fi прототип — интерактивный wireframe. Серые блоки, но можно кликать и переходить между экранами. Быстро делается, быстро проверяется.

Hi-fi прототип — интерактивный макет. Выглядит как готовый сайт, работает как приложение. Занимает больше времени, но даёт максимально реалистичный опыт.

Как это всё связано: реальный рабочий процесс

В идеальном мире процесс выглядит так:

1. Бриф и исследование — понять задачу, изучить конкурентов, определить аудиторию
2. Wireframe — спроектировать структуру и логику
3. Обсуждение wireframe с клиентом — согласовать структуру
4. Дизайн макета — нарисовать всё красиво
5. Обсуждение макета — согласовать визуал
6. Прототип — добавить интерактивность, протестировать
7. Передача в разработку

На практике этапы часто сокращают или меняют местами. Для простого лендинга wireframe иногда пропускают — опытный дизайнер сразу рисует макет, потому что структура там несложная. Для большого корпоративного сайта wireframe делают очень детально, потому что цена ошибки высокая. В REEXY при разработке корпоративного сайта (от 15 000 ₽) этап проектирования всегда включён: без понимания структуры сложно нарисовать дизайн, который реально работает.

Итерации — это нормально

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

Что спрашивать у дизайнера или студии

Когда обсуждаете проект, задайте несколько прямых вопросов:

Делаете ли вы wireframe? Если студия сразу бросается рисовать красивый дизайн, не думая о структуре — это тревожный знак. Либо проект простой и wireframe не нужен, либо дизайнер работает интуитивно, что несёт риски.

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

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

Делаете ли мобильную версию? Иногда студии делают только десктоп, а мобайл «как получится». Уточните заранее.

Как организованы правки? Обычно в договоре прописано количество итераций на каждом этапе. Типичная схема — 2 раунда правок после показа wireframe и 2 раунда после показа макета.

Типичные ошибки клиентов

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

Утверждать wireframe и потом менять структуру — wireframe согласуется именно для того, чтобы потом не переделывать макет. Если после согласования структуры клиент говорит «а давайте уберём этот блок» — это платные правки, потому что переделывается уже готовая работа.

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

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

Чёткий итог: что и зачем

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