Кнопки нарисованы, но что произойдёт после нажатия? Сохранится ли выбор, если вернуться назад? Поймёт ли человек, что отправил запрос, а не получил подтверждение заказа? Мы в «Гуси-Лебеди» предлагаем ответить на эти вопросы в прототипе сайта, пока решения можно обсуждать и менять до полноценной разработки.
Прототип сайта представляет структуру, содержание и поведение интерфейса в модели, пригодной для выбранной проверки. Разберём процесс на условном сайте аренды оборудования. Посетителю нужно выбрать инструмент, проверить даты, понять стоимость и отправить запрос. Это учебный пример, а не условия конкретного проката.
Для чего нужен прототип и как выбрать его вид
«Согласовать сайт» - слишком широкая задача. Для структуры вопрос звучит так: найдёт ли посетитель нужную категорию? Для карточки: поймёт ли он совместимость, комплектацию и условия аренды? Для оформления: заметит ли, что отправляет запрос, а не получает окончательное подтверждение наличия?
Запишите решение, которое будет принято после проверки. Например, если люди не различают аренду на сутки и на рабочую смену, команда меняет единицы расчёта и пояснения. Если непонятна совместимость, добавляет характеристики и подбор. Такой прототип проверяет конкретное предположение, а не служит поводом обсудить вкусы участников встречи.
| Вопрос | Нужная модель | Что пока не требуется |
|---|---|---|
| Где искать товар? | Структура разделов и названия | Фотореалистичная карточка |
| Как оформить запрос? | Связанные экраны и состояния формы | Настоящая платёжная интеграция |
| Как ведёт себя сложное поле? | Интерактивный элемент с вводом | Полный каталог |
| Сможет ли API подтвердить остаток? | Техническая проверка интеграции | Один только макет экрана |
Можно иметь серый интерфейс с точными текстами и работающей логикой. Можно нарисовать красивый экран, в котором все кнопки ведут на один успех. Первый вариант часто полезнее для проверки сценария. Оцените отдельно визуальную точность, реалистичность содержания, ширину разделов и глубину взаимодействия.
При переходе к UX/UI-дизайну интерфейса перенесите в задание проверенные сценарии и обнаруженные ограничения прототипа. Для каждого состояния сохраните тексты, действия и правила перехода, чтобы визуальная проработка не потеряла логику взаимодействия.
Скетч удобен для быстрой перестановки блоков. Вайрфрейм фиксирует информационную иерархию. Кликабельный прототип показывает переходы. Кодовый прототип нужен, когда важно поведение реального браузера: ввод, фокус, прокрутка, изменение ширины. Это не обязательная лестница для каждого проекта; выбирайте минимальную модель, которая способна ответить на поставленный вопрос.
В рекомендациях Nielsen Norman Group по тестовым заданиям акцент сделан на реалистичных целях без подсказки пути. Даже детализированный макет даст слабые данные, если модератор заранее объяснил участнику, какую кнопку нажимать.
Если делаете прототип сайта в Figma, подготовьте фреймы нужных состояний. В режиме Prototype выберите объект, с которого начинается взаимодействие, соедините его с нужным экраном и настройте событие, действие и цель. Проверьте прямой и обратный путь. Порядок описан в официальной инструкции Figma по связям прототипа. Кликабельный переход показывает модель сценария, но не подтверждает работу сервера.
Бумага подходит для обсуждения порядка блоков, редактор для связи экранов, а браузерная модель для проверки реального ввода и прокрутки. Выбирайте инструмент под вопрос. Шаблон или нейросеть могут дать начальный набросок, но содержание, ветки и ограничения нужно проверить самостоятельно. Цену и срок изготовления можно согласовать после определения состава сценариев.
Как создать прототип сайта: содержание и переходы
Для учебного проката нужны категории, названия моделей, характеристики, единицы аренды, условия получения, ограничения доставки, правила расчёта и статус наличия. Если эти данные пока неизвестны, помечайте вопросы владельцу бизнеса. Не заменяйте их выдуманными гарантиями и ценами ради убедительного экрана.
Возьмите крайние примеры контента: длинное название инструмента, несколько вариантов комплектации, отсутствие фотографии, много характеристик, нулевой результат поиска. Иначе аккуратная карточка с тремя короткими строками станет непригодной при первой загрузке реального каталога.
Составьте список шаблонов, а не только URL. Десять тысяч карточек могут использовать один шаблон, но одна форма может иметь десяток важных состояний. Для оценки разработки нужны оба измерения: типы страниц и правила их поведения.
Учебный путь: категория → карточка → даты → условия получения → контакты → подтверждение отправки. На каждом шаге укажите входные данные, действие и результат. «Нажал продолжить» не описывает, что система проверила и какой статус теперь имеет запрос.
Обсуждая проектирование прототипа сайта попросите показать начало, завершение и восстановление каждого ключевого сценария. Набор экранов без переходов не позволяет проверить, справится ли пользователь с задачей.
Посетитель может прийти сразу из поиска в карточку. Ему всё ещё нужны условия, ориентир в каталоге и возможность сравнить варианты. Не проектируйте сайт так, будто все обязательно начинают с главной и читают блоки сверху вниз.
Отдельно проверьте возврат: человек меняет даты после ввода контактов, возвращается из условий доставки или открывает другую комплектацию. Какие значения сохраняются? Что пересчитывается? Требуется ли повторное подтверждение? Мы предлагаем зафиксировать эти решения до разработки, чтобы команда одинаково понимала поведение системы.
Какие состояния и мобильные экраны показать
Для формы выбора дат недостаточно двух экранов «пусто» и «успех». Нужны загрузка доступности, отсутствие подходящих дат, ошибка сервиса, изменение цены, просроченный результат проверки и подтверждённая отправка запроса. Состояния должны иметь понятное действие для пользователя.
| Состояние | Что объяснить | Следующий шаг |
|---|---|---|
| Нет оборудования на даты | Выбранный вариант недоступен | Другие даты или подходящий аналог |
| Сервис наличия не ответил | Доступность пока не подтверждена | Повторить проверку или оставить запрос оператору |
| Изменилась стоимость | Какая сумма и почему пересчитана | Подтвердить новые условия |
| Ошибка контакта | Какое поле исправить | Сохранить остальные данные |
| Запрос принят | Номер и ожидаемый дальнейший контакт | Просмотреть запрос или изменить его по правилам |
Различайте бизнес-отказ и техническую ошибку. «Нет свободного оборудования» и «не удалось проверить» требуют разных решений. Если оба состояния показать как пустой каталог, пользователь и аналитик сделают неверный вывод о наличии.
Не ограничивайтесь уменьшенной копией широкого экрана. На телефоне длинный блок характеристик может отодвинуть даты и стоимость далеко вниз. Определите, что нужно для первого решения, а что раскрывается по запросу. При этом существенные условия нельзя скрывать так, что человек узнаёт о них только после отправки.
Проверьте открытое меню, фильтры, длинные значения, ошибки под полями и поведение основной кнопки. Если есть закреплённая нижняя панель, учтите клавиатуру и сообщения формы: панель не должна закрывать исправляемое поле. Статичный макет не доказывает корректность этого поведения, поэтому сложный участок разумно проверить в браузере.
Для передачи разработчику укажите порядок элементов при перестроении и смысл скрытия. «На мобильном убрать» - недостаточное требование, когда речь идёт об условиях аренды, предупреждении или критичной характеристике.
Как проверить прототип и оформить изменения
Дайте задачу в терминах жизненной ситуации: «Вам нужен инструмент на следующие выходные. Выберите подходящий вариант, уточните условия получения и отправьте запрос». Не говорите «откройте каталог, нажмите фильтр и выберите даты»: так вы проверите способность следовать инструкции, а не понятность интерфейса.
До сессии убедитесь, что нужные ветки прототипа работают. Сообщите, что проверяется интерфейс, а не способности участника. Во время выполнения фиксируйте первый выбор, ошибочные переходы, возвраты, вопросы и момент остановки. Если требуется помощь, запишите её: завершение после подсказки нельзя считать самостоятельным успехом.
После действия спросите, какой результат человек ожидает. Он может дойти до экрана благодарности, но решить, что оборудование уже забронировано, хотя отправлен только запрос. Формально путь завершён, а ожидание опасно расходится с процессом. Такой дефект важнее небольшого лишнего клика.
Слабая запись: «форма неудобная». Рабочая запись: «участник изменил даты, не заметил пересчёт суммы и отправил запрос, ориентируясь на старую цену». В ней есть ситуация, наблюдаемое действие и последствие. Следующая гипотеза: показать изменение рядом с итогом и запросить подтверждение перед отправкой.
В карточке проблемы укажите версию прототипа, сценарий, свидетельство, серьёзность, предложенное изменение и способ повторной проверки. Не назначайте серьёзность только по числу повторений. Даже единичная путаница между заявкой и подтверждённой бронью может иметь значимые последствия.
Учебная сессия с несколькими участниками позволяет найти проблемы, но не даёт достоверную рыночную конверсию. Не пишите «80% клиентов не понимают сайт», если четыре человека из пяти запутались в ограниченном прототипе. Корректно: «в этой проверке четыре участника из пяти не заметили условие; исправляем и проверяем повторно».
Что передать дизайнеру и разработчику
Согласуйте именованную версию и перечень экранов. Приложите карту переходов, состояния, правила расчёта, модель контента, условия валидации и список открытых вопросов. Комментарий «обсудили на звонке» не заменяет принятое решение. У каждого спорного пункта нужен ответственный и дата разрешения.
При переходе к детальной проработке макетов сайта передайте содержание, ограничения компонентов и результаты проверки прототипа. Так визуальная детализация не отменит уже согласованную логику.
Для формы аренды передача должна объяснять: откуда приходит наличие, сколько действует результат проверки, что происходит при изменении даты, когда запрос получает номер и что считается успешной отправкой. Прототип может показывать это визуально, но технический контракт интеграции оформляется отдельно.
Проверьте доступность исходного файла для команды, права на редактирование, шрифты и вложенные изображения. Сохраните экспорт ключевых экранов как снимок согласованной версии. Ссылка на постоянно меняющийся файл без версии затрудняет приёмку: стороны могут обсуждать разные состояния одной работы.
Когда прототип готов к следующему этапу
Прототип готов к следующему этапу, когда основные сценарии можно пройти, важные состояния описаны, содержание достаточно реалистично, а критические вопросы имеют решения или явно назначенных владельцев. Это не обещание отсутствия проблем в будущем. Производительность, фактическую доступность с клавиатуры, серверную валидацию и интеграции нужно проверять в работающем продукте.
Практический приём: перед согласованием попросите человека, не участвовавшего в рисовании, объяснить по прототипу, что произойдёт после каждого действия. Если он не может отличить отправку от подтверждения, найти условия или понять отказ, экран ещё нуждается в работе - даже если визуально всем нравится.
Прототип опирается на структуру сайта, а его проверка связана с юзабилити. Для коммерческого сценария пригодится разбор посадочной страницы; для испытания самого предложения - руководство по MVP и гипотезам.
Мы в Гуси-Лебеди предлагаем принимать прототип по согласованным сценариям и описанным ограничениям. Тогда у команды есть понятное основание для следующего этапа и список того, что предстоит подтвердить уже на рабочем сайте.