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