Прототип сайта: какую детализацию выбрать до начала дизайна

Какой вопрос должен решить прототип

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

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

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

Разделите детализацию внешнего вида и поведения

Чёрно-белая схема может подробно показывать весь путь оформления, а аккуратно оформленный макет — содержать только один экран без работающих переходов. Поэтому слово «детальный» нужно раскрывать. Отдельно укажите содержание, внешний вид и взаимодействия, которые должен передать результат.

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

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

Выберите несколько законченных задач посетителя

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

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

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

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

Подставляйте настоящий смысл вместо одинаковых серых строк

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

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

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

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

Какие состояния нужны форме, фильтру и личному кабинету

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

• Форма: пустой ввод, ошибка в поле, отправка, подтверждение и недоступность отправки.
• Поиск или фильтр: исходный список, выбранные условия, отсутствие результатов и очистка выбора.
• Товар: доступный вариант, недоступный вариант, изменение количества и объяснение условий.
• Кабинет: вход, отсутствие данных, нужный документ и ограничение доступа.

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

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

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

Мобильный вариант проверяйте как отдельный способ выполнения задачи

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

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

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

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

Как провести короткую проверку понятности

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

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

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

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

Как собирать замечания, чтобы не переделывать всё по кругу

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

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

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

Что получить вместе с утверждённым прототипом

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

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

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

Чтобы обсудить проектирование с ШТАБ ИТ, подготовьте основные задачи посетителей, примеры услуг и ограничения бизнеса. Начните с одного законченного пути и списка состояний. После его проверки будет проще определить нужную глубину остальных страниц и перейти к дизайну с понятными решениями.