Проверьте прототип по трём сценариям посетителя

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

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

Шаг 1. Зафиксируйте версию и ограничения

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

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

Шаг 2. Подготовьте три задания

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

Задание описывает цель человека, а не название кнопки. Вместо «нажмите “Услуги”, затем “Обсудить”» напишите: «Вы выбираете подрядчика для корпоративного сайта. Найдите подходящий формат работы и способ передать задачу». Это учебная формулировка: замените её контекстом своей аудитории.

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

Шаг 3. Запишите фактическое прохождение

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

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

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

Шаг 4. Оформите список проблем

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

Учебный пример: участник выбирает услугу, открывает форму и не видит, какой вариант выбран. Это вымышленный разбор, не результат исследования CoreWeb. В карточке P-01 можно записать: «После перехода в форму контекст выбора не показан. Участник спрашивает, нужно ли повторно описывать услугу. Уточнить, сохраняется ли выбор; показать согласованное состояние в следующей версии».

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

Шаг 5. Повторите после изменения

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

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

Результат урока

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

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

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