Прототип сайта — модель будущих страниц и действий посетителя. Она помогает проверить, понимает ли человек предложение, находит ли нужную информацию и может ли перейти к следующему шагу. Прототип бывает простым наброском или подробной интерактивной моделью. Его полезность определяется вопросами, на которые он позволяет ответить.
Для владельца бизнеса результат этой работы — согласованное решение: как посетитель доберётся до запроса, что увидит по пути и какие сведения передаст компании. Вместе с решением нужно зафиксировать, что ещё неизвестно. Красивый экран и работающая ссылка между экранами сами по себе не подтверждают готовность сайта.
Структура, прототип и визуальный макет отвечают на разные вопросы
Структура описывает состав и связи разделов. Например, у поставщика оборудования есть страницы услуг, отраслевых решений, полезных материалов и запроса. По структуре можно понять, где размещается информация. Но перечень страниц ещё не показывает, заметит ли посетитель возможность обсудить свою задачу.
Прототип показывает, как человек использует эти страницы. Посетитель читает о подходящей услуге, нажимает «Обсудить задачу», видит, с какой темой связан запрос, и переходит к заполнению. Здесь можно проверить смысл кнопки, последовательность действий и достаточность пояснений. Для обсуждения расположения информации бывает достаточно статичных схем экранов; чтобы наблюдать самостоятельный проход, полезны переходы между ними.
Визуальный макет задаёт конкретное оформление: шрифты, цвета, изображения, размеры, отступы и внешний вид состояний. На нём видно, читается ли пояснение и насколько заметна кнопка рядом с остальным содержимым. Один неподвижный макет не показывает весь путь посетителя. Несколько макетов можно связать в подробный кликабельный прототип.
Поэтому это не обязательно три отдельных файла, которые делают строго по очереди. Команда может уточнять структуру по результатам проверки прототипа, а затем проверять тот же сценарий на оформленных экранах. Важно различать предмет согласования: состав страниц, действия посетителя и внешний вид интерфейса.
Учебный пример: запрос поставщику из трёх разных мест
Представим компанию, которая поставляет оборудование для маркировки упаковки. Посетитель хочет выяснить, подойдёт ли решение для его производства, а менеджеру нужно понять предмет обращения. Компания и все решения ниже придуманы для объяснения; это не клиентский кейс Студии Вебирус.
До запроса человек может прийти разными путями:
- Со страницы услуги — уже знает, что ищет помощь с подбором оборудования.
- Из отраслевого решения — ищет вариант для пищевого производства, но ещё не выбрал конкретное оборудование.
- Из статьи — изучает вопрос и хочет обсудить свою ситуацию, не проходя весь каталог.
В этом примере команда предлагает общий экран запроса. На нём показывается исходная тема обращения: выбранная услуга, отрасль или название материала. Посетитель может уточнить задачу своим текстом. Менеджер должен получить этот контекст вместе с обращением — это согласуемое требование к будущему сайту, а в прототипе пока лишь демонстрируемое поведение.
Схема показывает учебный путь в прототипе. Она не означает, что запрос уже сохраняется или передаётся в систему продаж. На каждом входе нужно отдельно проверить, понятен ли человеку переход и сохраняется ли смысл его обращения.
Если проверять только маршрут с главной страницы, можно пропустить посетителя статьи. Он ещё не выбрал услугу, поэтому поле с обязательным выбором модели оборудования остановит его. В нашем примере это повод обсудить запрос без выбранной модели: менеджер сначала уточняет задачу, а оборудование подбирают позже. Такое решение нельзя автоматически переносить на другой бизнес — его подтверждает тот, кто будет обрабатывать обращения.
Что проверять в простом прототипе
Низкая детализация полезна, когда неизвестны состав информации и порядок действий. Экраны можно собрать из серых блоков без окончательной графики. Но значимые названия и пояснения лучше написать осмысленно: надпись «Текст» не позволит проверить, понимает ли посетитель условия обращения.
В учебном примере сначала достаточно показать три исходные страницы, общий запрос и подтверждение. Проверяют, есть ли на каждой странице понятный следующий шаг, не заставляет ли маршрут возвращаться в начало сайта и видно ли человеку, о чём он обращается. Если выбранная тема неверна, нужно решить, как её изменить или убрать.
На этой детализации можно обнаружить лишний шаг или отсутствие важного ответа. Например, посетителю статьи не объяснили, можно ли обратиться без названия модели. Добавить такое пояснение и повторно проверить путь проще, пока оно не требует переделки оформленных экранов и готовой формы.
Простой прототип не даёт надёжного ответа на вопросы о визуальной заметности, точных размерах и удобстве касаний. Серый блок может обозначать будущую кнопку, но по нему нельзя заключить, что оформленную кнопку будет легко найти и нажать на телефоне.
Когда нужна высокая детализация
Подробный прототип нужен, если ответ зависит от конкретного содержания, расположения элементов или поведения интерфейса. Для нашего запроса это может быть проверка длинной темы обращения на телефоне, редактирования этой темы, возврата к исходной странице и понятности сообщений формы.
Здесь используют близкие к будущему сайту тексты и размеры экранов. Показывают не только удачное заполнение, но и существенные состояния: ошибка ввода, исправление, переход назад, подтверждение. Если прототип лишь переключает заранее подготовленные картинки, это нужно объяснить участнику и заказчику. Такой переход позволяет оценить сообщение, но не проверяет, действительно ли система распознаёт ошибку в произвольных данных.
Внешняя точность и интерактивность — разные свойства. Серые экраны могут быть кликабельными, а тщательно оформленный макет — неподвижным. Иногда для проверки ввода, клавиатуры или поведения в браузере нужен прототип на коде. Выбирают форму модели, которая позволяет наблюдать нужное действие; подробная анимация не заменяет недостающий сценарий.
Когда порядок действий согласован, дизайн сайта помогает воплотить его в конкретных визуальных решениях. Если оформление меняет понятность перехода, сценарий проверяют ещё раз уже на этих экранах.
Как проверить путь без подсказок посетителю
Попросите человека, похожего на будущего покупателя, выполнить задачу. Для учебного примера она может звучать так: «Вы изучили материал о маркировке и хотите выяснить, подходит ли решение для вашей упаковки. Покажите, как вы обратитесь к компании, и объясните, какого ответа ждёте». Название нужной кнопки в задании не подсказывают.
Наблюдайте за действиями: где человек начинает искать, какой текст читает, в каком месте останавливается и что ожидает после нажатия. Вопрос «Всё понятно?» даёт меньше материала для решения, чем замечание «Посетитель ищет контакты внизу статьи, потому что не понял подпись кнопки». Проверяйте входы по отдельности, с подходящими для них задачами.
Обсуждение с владельцем и проверка с покупателем решают разные задачи. Владелец подтверждает, что компания готова обработать такой запрос. Покупатель показывает, понимает ли он предложенный путь. Если реальных представителей аудитории пока не удалось привлечь, внутренний проход помогает найти противоречия, но его не следует записывать как подтверждённое удобство для клиентов.
Для исправления полезно сохранять связку «наблюдение — изменение — повторная проверка». В учебном сценарии: человек решил, что без выбранной модели обратиться нельзя; команда убрала обязательный выбор модели из первого обращения и уточнила пояснение; новый проход должен показать, понимает ли посетитель возможность описать задачу. Само внесение правки ещё не подтверждает, что проблема исчезла.
Что остаётся неизвестным после кликабельного прототипа
Нажатие «Отправить» может просто открыть следующий экран с фразой «Запрос принят». Так проверяют понятность сообщения и ожидания посетителя. Чтобы подтвердить реальную работу формы, нужно отправить тестовый запрос через реализованный сайт и проверить его получение на стороне компании.
Удобно явно разделить оставшиеся вопросы:
- Работа формы и интеграции. Где сохраняется запрос, попадает ли исходная тема к менеджеру, что происходит при сбое передачи и повторном нажатии? Эти ответы требуют согласованных правил и технической проверки.
- Поведение готового интерфейса. Можно ли заполнить форму с клавиатуры, что происходит при появлении экранной клавиатуры, читаются ли сообщения средствами доступности? Картинки с переходами не подтверждают свойства будущей вёрстки.
- Содержание и процесс компании. Кто ответит на запрос, что ему нужно для начала разговора, какие условия можно обещать посетителю? Прототип помогает обнаружить вопросы, а ответы дают ответственные сотрудники.
Подробнее о составе полей и состояниях можно прочитать в статье о понятной форме заявки, а о проверке готового интерфейса на телефоне — в материале об адаптивном сайте. Здесь важно провести границу: успешный проход по модели подтверждает только то поведение и те условия, которые в ней действительно проверялись.
Прототип на коде тоже не становится готовым сайтом автоматически. Реализация для проверки идеи может не включать защиту данных, полноценную обработку ошибок и работу под нагрузкой. При передаче в разработку отдельно определяют, что пригодно для использования, а что нужно реализовать заново.
Что заказчику зафиксировать при согласовании
Фраза «Прототип утверждён» слишком неопределённа, если непонятны версия, проверенные маршруты и оставшиеся вопросы. Зафиксируйте результат рядом с конкретной версией экранов. Это может быть короткая запись в рабочем документе; отдельный большой регламент нужен не каждому проекту.
Для нашего учебного примера запись могла бы содержать следующее:
- Принятое решение: с услуги, отраслевого решения и статьи человек переходит к общему запросу; исходная тема видна и допускает изменение; выбор модели для первого обращения не обязателен.
- Основание: перечислены просмотренные входы, условия прохода и замечания; указано, участвовали ли представители аудитории или только команда проекта.
- Подтверждение бизнеса: руководитель продаж согласовал обращение без модели и показанный состав сведений; владелец подтвердил выбранный путь.
- Открытый вопрос: технический специалист проверит передачу темы обращения в систему продаж. До результата этой проверки нельзя считать демонстрацию доказательством работоспособности интеграции.
- Следующая проверка: после реализации тестовый запрос с каждого входа должен дойти до ответственного сотрудника с верным контекстом. Оформление и мобильное поведение проверяются на согласованных макетах и готовой странице.
Это образец записи, а не отчёт о проведённом исследовании. В реальном проекте нужны фактическая версия, участники, наблюдения и ответственные за неизвестные. Если нерешённый вопрос способен изменить весь маршрут, сначала закрывают его или пересматривают решение. Мелкое оформление можно уточнять позже, когда оно не влияет на согласованный путь.
Какой объём прототипирования оправдан
У простой страницы с понятным содержанием и одним знакомым действием может быть достаточно схемы блоков и проверки макета. Для повторяющихся страниц обычно проверяют общий шаблон и значимые исключения, а не делают отдельную сложную модель каждого экземпляра. Новый путь выбора, разные входы в обращение или спорные условия требуют большего внимания.
Перед работой сформулируйте нерешённый вопрос: «Сможет ли посетитель статьи обратиться без выбранной модели?» Затем определите минимальную модель, на которой это можно проверить, и результат, после которого команда примет решение. Такой подход помогает выбрать обоснованный объём прототипирования сайта.
Прототип помогает сокращать переделки, когда спорное решение обнаруживают до его распространения на дизайн, вёрстку и интеграцию. Экономия возникает из конкретной работы, которую не пришлось переделывать: например, из нескольких вариантов формы, построенных на неверном обязательном выборе модели. Универсального процента здесь нет. Ценность прототипа для заказчика видна в принятых решениях, устранённых противоречиях и честном перечне того, что ещё предстоит проверить.
