Прототип сайта для проверки сценария до графики и разработки

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

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

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

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

Вайрфрейм (wireframe) — каркас отдельного экрана. Он показывает основные области, элементы, содержание и приоритет, обычно без финальной типографики, цвета и графики.

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

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

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

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

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

Фраза «сделать прототип сайта» слишком широка. Прототип услуги и прототип оформления сложного заказа имеют разную глубину.

Для корпоративной страницы можно проверить:

Для интернет-магазина важнее другое:

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

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

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

Высокодетализированный прототип (high fidelity, high-fi) ближе к готовому интерфейсу. На нём можно проверять заполнение формы, выбор варианта, микротекст, мобильное поведение и реакции. Он дороже, а реалистичный вид создаёт опасную иллюзию готовности: участники начинают обсуждать отступы, хотя бизнес-правила ещё не определены.

Детализацию выбирают по вопросу:

Чем реалистичнее прототип, тем важнее прямо назвать, что в нём ненастоящее. Иначе согласование картинки ошибочно превращается в согласование системы.

Lorem ipsum, одинаковые карточки и заглушка «описание преимущества» делают прототип аккуратным, но скрывают ограничения.

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

Контент-first не означает написать все тексты до первого экрана. Достаточно использовать репрезентативные данные:

Если интерфейс работает только на специально подобранном коротком контенте, он не прошёл проверку.

«Пользователь переходит в каталог» — не сценарий. Нужна ситуация.

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

Из такого описания возникают проверяемые шаги:

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

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

Тестирование прототипа — не презентация с вопросом «вам нравится?». Участнику дают ситуацию и просят выполнить действие, не подсказывая путь.

Подготовка состоит из нескольких решений:

Во время сессии важнее видеть действия, чем собирать мнения. Человек может сказать, что всё понятно, и при этом трижды открыть не тот раздел. Исследователь отмечает путь, остановки, возвраты, неверные ожидания и вопросы.

После теста проблемы группируют по механизму:

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

Для сценария полезны простые показатели:

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

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

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

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

На экране заказа становится видно:

Согласование должно фиксировать не только экран, но и открытые вопросы. Удобны аннотации:

Так прототип становится мостом к требованиям, не притворяясь технической спецификацией.

Кликабельная модель не подтверждает, что интеграция возможна, программный интерфейс (API) выдержит нагрузку, данные чистые, поиск релевантен, а расчёт цены корректен.

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

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

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

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

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

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

Третья — показывать только счастливый путь. В системе не оказывается пустого результата, ошибки, просроченной сессии, отказа оплаты и повторной отправки.

Четвёртая — путать комментарии руководителя с пользовательским тестом. Владелец продукта знает внутреннюю структуру и не представляет нового посетителя.

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

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

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

Для каждого критичного сценария заполните карточку.

Перед передачей в визуальный дизайн проверьте:

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

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