Прототипирование сайта: от вайрфрейма до кликабельного прототипа

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

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

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

Что такое прототип сайта и чем он отличается от вайрфрейма и макета?

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

• Вайрфрейм (wireframe, каркас) отвечает на вопрос «что где лежит». Это схема страницы: блоки, их порядок и относительный вес, навигация, места под тексты и изображения. Цвета, шрифтов и фотографий нет намеренно — чтобы взгляд не цеплялся за оформление.
• Макет (mockup) отвечает на вопрос «как это выглядит». Статичная картинка с финальной типографикой, палитрой, иконками и фотографиями. Макет нельзя «прокликать», зато по нему видно характер бренда.
• Прототип отвечает на вопрос «как это работает». Набор связанных экранов с переходами, состояниями и обратной связью: нажали кнопку — открылась корзина, отправили пустую форму — появилась ошибка. Прототип может быть и серым, и цветным: определяет его интерактивность, а не внешний вид.

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

Есть и четвёртый артефакт, который часто пропускают, — карта сайта (информационная архитектура). Это список страниц и их иерархия, без содержимого. С неё прототипирование и начинается: невозможно нарисовать навигацию, пока непонятно, какие разделы в ней будут.

Зачем прототипировать сайт, если можно сразу рисовать дизайн?

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

Прототип решает несколько задач одновременно:

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

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

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

Какие бывают прототипы: low-fi, mid-fi и hi-fi

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

• Low-fidelity (низкая детализация). Скетчи на бумаге или маркерной доске, серые прямоугольники в Figma или Miro. Делаются за минуты, их не жалко выбрасывать. Подходят для мозгового штурма и выбора между несколькими вариантами структуры.
• Mid-fidelity (средняя детализация). Аккуратный серый вайрфрейм с реальными заголовками, текстами, полями форм, сеткой и примерными размерами. Это рабочая лошадка большинства проектов: на нём согласуют структуру и проводят первые юзабилити-тесты.
• High-fidelity (высокая детализация). Прототип, близкий к финальному интерфейсу: цвета, типографика, иконки, микроанимации, состояния. Нужен для финальных тестов, демонстрации инвесторам или стейкхолдерам и передачи сложных взаимодействий в разработку.

По интерактивности прототипы бывают статичными (набор экранов без связей), кликабельными (переходы по нажатию между экранами) и функциональными — с логикой, переменными и условиями, когда поле действительно валидируется, а корзина пересчитывает сумму. Функциональные прототипы собирают в Figma с переменными, в Axure или прямо в коде.

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

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

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

1. Сформулируйте цель сайта и каждой ключевой страницы. Не «рассказать о компании», а «посетитель из поиска понимает, подходит ли ему услуга, и оставляет заявку». Цель определяет, что будет на странице первым.
2. Опишите аудиторию и сценарии. Кто приходит, откуда, с каким вопросом и что должен сделать. Для магазина это «найти товар — сравнить — положить в корзину — оформить», для сервиса — «понять цену — оставить заявку». Три–пять главных сценариев достаточно.
3. Соберите карту сайта. Список страниц, их иерархия и связи. Проверьте названия разделов карточной сортировкой или хотя бы по словам из поисковых запросов, а не по внутренним терминам компании.
4. Нарисуйте скетчи. Пять–десять минут на бумаге на каждый ключевой экран, лучше по два-три варианта. На этом этапе ищут идеи, а не красоту.
5. Соберите вайрфреймы с реальным контентом. Перенесите лучший вариант в Figma на сетку. Вместо «Lorem ipsum» — настоящие заголовки, цены, названия услуг, хотя бы черновые. Именно здесь выясняется, что заголовок не помещается, а важная информация спрятана в пятом экране.
6. Добавьте переходы и состояния. Свяжите экраны по сценариям: главная — каталог — карточка — корзина — оформление. Нарисуйте состояния, которые обычно забывают: пустой поиск, ошибку формы, загрузку, успешную отправку.
7. Сделайте мобильную версию. Не «потом адаптируем», а сразу: на мобильных экранах приходит большая часть трафика, и порядок блоков там часто другой.
8. Проверьте на пользователях и согласуйте. Короткий юзабилити-тест, разбор замечаний, правки и фиксация утверждённой версии.

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

Что должно быть на прототипе обязательно

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

Как сделать кликабельный прототип в Figma?

Figma сегодня — стандарт для прототипирования веб-интерфейсов: в ней можно и нарисовать вайрфрейм, и связать экраны, и отдать проект разработчикам в Dev Mode. Базовый кликабельный прототип собирается так:

1. Создайте фреймы под каждый экран сценария с размером целевого устройства — например, 1440 пикселей для десктопа и 390 для мобильного.
2. Соберите повторяющиеся элементы (шапку, кнопки, карточки, поля) как компоненты с вариантами: обычное, наведение, фокус, ошибка, неактивное. Тогда правка в одном месте применится везде.
3. Переключитесь на вкладку Prototype, выберите элемент и протяните связь к целевому фрейму. Задайте триггер (On click, On hover, While pressing) и действие (Navigate to, Open overlay, Swap with).
4. Для выпадающих меню, модальных окон и подсказок используйте оверлеи, а не отдельные копии экрана.
5. Назначьте стартовый фрейм для каждого сценария (Flow starting point) и дайте ему понятное имя: «Оформление заказа», «Подбор тарифа».
6. Если нужна логика — счётчик в корзине, условный показ ошибки, — используйте переменные и условия. Для большинства тестов достаточно простых переходов.
7. Запустите Present и пройдите все сценарии сами, прежде чем показывать прототип людям: битые переходы на тесте отнимают время и сбивают респондента.

Альтернативы тоже есть. Axure остаётся сильным инструментом для сложной логики и документации, Miro и FigJam удобны для скетчей и карты сайта, Framer и Webflow позволяют собрать прототип, который почти сразу становится живой страницей. Выбор инструмента вторичен: важнее, чтобы им владела вся команда и чтобы прототип было легко поправить.

Состояния элементов лучше не придумывать с нуля для каждого проекта, а взять из чек-листа: в нашем разборе состояний компонента собраны hover, focus, disabled, loading, error и empty с требованиями доступности.

Какой инструмент выбрать для прототипирования?

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

• Бумага и маркерная доска. Самый быстрый способ перебрать варианты структуры. Ничего не стоит, не требует навыков, отлично работает на воркшопе с заказчиком. Минус — нельзя протестировать удалённо и сложно хранить версии.
• FigJam и Miro. Подходят для карты сайта, пользовательских сценариев и грубых схем экранов. Удобно собирать замечания стикерами. Для кликабельных переходов возможностей мало.
• Figma. Универсальный выбор: вайрфреймы, компоненты, кликабельные прототипы, переменные и условия, совместная работа и передача в разработку из одного файла. Если команда уже ведёт дизайн-систему в Figma, прототип собирается из её компонентов и потом плавно превращается в макет.
• Axure RP. Сильна там, где много логики: сложные формы, условные сценарии, таблицы с фильтрами, личные кабинеты. Позволяет писать подробные спецификации прямо рядом с экранами. Порог входа выше, чем у Figma.
• Framer и Webflow. Прототип собирается на реальной вёрстке, с настоящей адаптивностью и анимациями. Хороши для маркетинговых сайтов и лендингов, где прототип быстро становится продакшен-страницей. Для сложных веб-приложений обычно не подходят.
• Прототип в коде. HTML и CSS или фреймворк с готовыми компонентами. Оправдан, когда нужно проверить реальное поведение — производительность, работу с данными, доступность для экранных дикторов. Самый дорогой вариант, поэтому его применяют точечно.

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

Как прототип меняется в зависимости от типа сайта?

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

Лендинг

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

Корпоративный сайт и сайт услуг

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

Интернет-магазин

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

Личный кабинет и веб-сервис

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

Сколько времени занимает прототипирование и кто его делает?

Сроки зависят от числа уникальных шаблонов и сценариев, а не от числа страниц. Сто страниц услуг по одному шаблону — это один шаблон. Ориентиры для mid-fi прототипа с одним циклом тестирования и правок выглядят так:

• лендинг — от одного до трёх рабочих дней;
• корпоративный сайт на 5–10 шаблонов — от одной до двух недель;
• интернет-магазин с каталогом, фильтрами и оформлением заказа — от двух до четырёх недель;
• личный кабинет или веб-сервис — от трёх недель и больше, в зависимости от числа ролей и сценариев.

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

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

Как протестировать прототип на пользователях?

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

1. Сформулируйте задачи, а не вопросы. Не «Понятно ли меню?», а «Вы хотите заказать доставку на завтра. Найдите, сколько она будет стоить». Задача должна совпадать с реальным сценарием.
2. Наберите респондентов из целевой аудитории. Для качественного теста на одном сценарии обычно хватает пяти человек — подробно о границах этого правила мы писали в материале про тестирование на пяти пользователях.
3. Не подсказывайте. Попросите думать вслух и молчите, даже если человек ищет кнопку минуту. Именно эта минута — главный результат теста.
4. Фиксируйте поведение, а не оценки. Где человек остановился, что прочитал не так, куда нажал первым, сколько времени заняла задача, дошёл ли до конца.
5. Сведите находки. Сгруппируйте проблемы по экранам, оцените частоту и влияние на задачу, отберите то, что исправляем до дизайна.

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

Как согласовать прототип и передать его в дизайн и разработку?

Согласование прототипа — точка, после которой структура считается утверждённой. Чтобы оно не превратилось в бесконечные круги правок, договоритесь о правилах заранее.

• Показывайте вживую, а не ссылкой. Проведите заказчика по сценариям, объясните, какие решения приняты и почему. Ссылка без комментария почти всегда возвращается с правками цвета серых прямоугольников.
• Собирайте замечания в одном месте. Комментарии в Figma или один документ, а не мессенджер, почта и устные пожелания.
• Отделяйте структуру от вкуса. Замечания про цвет и шрифты переносятся на этап дизайна, на прототипе их не обсуждают.
• Фиксируйте версию. Утверждённый прототип сохраните отдельной страницей или веткой, чтобы дизайн опирался на неё, а не на «последний вариант».

Для передачи в дизайн и разработку к прототипу добавляют аннотации. Что на странице динамическое и откуда берутся данные. Какие поля обязательны и как они валидируются — здесь пригодится наш разбор UX форм. Какие интеграции нужны (CRM, оплата, доставка), как ведёт себя страница на разных ширинах, какие состояния у каждого компонента. Разработчик, который видит эти пометки, задаёт вдвое меньше вопросов и реже додумывает поведение сам.

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

Какие ошибки при прототипировании стоят дороже всего?

1. «Lorem ipsum» вместо текстов. Структура, которая прекрасно выглядит с рыбой, разваливается при первом реальном заголовке на три строки.
2. Только «счастливый путь». Прототип показывает успешный заказ, но не показывает, что происходит, когда товара нет, оплата не прошла или поиск ничего не нашёл. Эти экраны потом рисует разработчик — как получится.
3. Прототип только для десктопа. Мобильная версия, придуманная на этапе вёрстки, почти всегда хуже продумана и требует переделок.
4. Слишком высокая детализация слишком рано. Красивый hi-fi на первой итерации жалко выбрасывать, и команда начинает защищать неудачную структуру.
5. Тест на коллегах. Люди, которые знают продукт, не споткнутся там, где споткнётся новый посетитель.
6. Нет владельца решений. Если не определено, кто утверждает прототип, правки приходят от всех и противоречат друг другу.
7. Прототип не связан с оценкой. Если после согласования прототипа никто не пересчитал объём работ, сроки и бюджет разойдутся с планом.

Чек-лист готовности прототипа к дизайну

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

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

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.