Как провести короткую проверку прототипа: выбрать задачу, наблюдать без подсказок, записать ошибки и честно представить результат.
·4 мин чтения
Чтобы проверить понятность прототипа, дайте человеку задачу и посмотрите, как он её выполняет. Вопрос «вам нравится?» измеряет впечатление от разговора, а не способность воспользоваться продуктом. Для команды хакатона полезнее увидеть конкретную остановку и исправить её до финального показа.
Короткая проверка помогает обнаружить проблемы интерфейса. Она не доказывает размер рынка, готовность платить или эффективность решения для всех пользователей. Заранее назовите, что вы хотите узнать, и не расширяйте вывод после пары удачных попыток.
Выберите вопрос, который влияет на ближайшее решение
Вместо проверки всего продукта выделите один риск. Понимает ли человек, где загрузить документ? Может ли отличить результат от примера? Находит ли способ исправить ошибку? Полученный ответ должен менять конкретный экран или поведение.
Сопоставьте вопрос с готовностью прототипа. Бумажный макет позволяет обсудить последовательность действий, но не измерить скорость реальной обработки. Работающая форма показывает ошибки ввода, однако сама по себе не подтверждает пользу сервиса для организации.
Запишите ожидаемое наблюдение до начала. Например: «Человек выбирает нужную заявку и видит её статус без объяснения интерфейса». Если вместо этого он открывает несколько разделов и спрашивает, куда нажать, у вас появляется материал для исправления.
Найдите подходящих участников
Пригласите людей, которые выполняют похожую задачу или могут правдоподобно оказаться в такой ситуации. Если вы делаете инструмент для координатора мероприятия, другой координатор полезнее случайного знакомого, который никогда не работал с заявками.
Когда целевая аудитория недоступна, можно проверить понятность отдельных действий на коллегах. Просто сохраните это ограничение в заметках. На защите называйте их участниками предварительной проверки интерфейса, а не клиентами, подтвердившими спрос.
Объясните, что вы показываете раннюю версию и изучаете её работу. Для записи экрана или голоса заранее согласуйте формат и использование материала. Не просите реальные пароли, финансовые сведения и другие чувствительные данные ради учебного сценария.
Составьте задание без подсказки
В руководстве GOV.UK тестовые задачи описаны как правдоподобные цели без раскрытия способа выполнения. Для хакатона это можно применить к одному короткому сценарию.
Сравните две формулировки. «Нажмите зелёную кнопку и загрузите файл» проверяет выполнение вашей инструкции. «Вы получили список заявок и хотите найти повторные записи» оставляет человеку возможность самому найти действие. Вторая формулировка лучше показывает понятность интерфейса.
Подготовьте одинаковые исходные данные для повторных проверок. Если одному человеку вы даёте простой файл, а другому заведомо повреждённый, сравнение потребует учесть эту разницу. Для разных условий заведите отдельные сценарии и не смешивайте результаты.
Наблюдайте и фиксируйте факты
Один участник команды проводит проверку, другой записывает действия. Отмечайте, где человек остановился, что ожидал увидеть и какой результат получил. Не заменяйте наблюдение оценкой личности: «не понял подпись» полезнее, чем «невнимательный пользователь».
Если человек застрял, сначала дайте ему время найти выход. Затем можно уточнить, чего он ожидал. Когда без помощи продолжить невозможно, помогите и отметьте вмешательство. Сценарий, завершённый после объяснения, отличается от самостоятельного выполнения.
Записывайте слова аккуратно. Дословную цитату используйте только там, где она действительно сохранена и допустима к публикации. Иначе передайте смысл как наблюдение команды. Не придумывайте выразительную реплику, чтобы сделать презентацию убедительнее.
Разделите дефекты и пожелания
Участник может предложить новую функцию, но это ещё не означает, что её нужно строить. Спросите, какую задачу он пытается решить. Иногда просьба добавить отдельную страницу вызвана тем, что человек не заметил уже существующее действие.
Сначала исправляйте то, что мешает завершить основной путь или приводит к неверному результату. Затем оцените проблемы понимания и удобства. Пожелания, не связанные с текущей задачей, сохраняйте для дальнейшего исследования.
Учебный пример: человек отправил форму и повторил отправку, потому что не увидел подтверждения. Команда может добавить понятный итоговый экран и защиту от случайного повторения. Для этого не требуется строить полноценную систему уведомлений, если она не входит в задачу.
Повторите исправленный шаг
После изменения проверьте тот же риск снова. По возможности пригласите человека, который ещё не видел экран: участник первой сессии уже знает путь и может пройти его по памяти. Если проверяете с тем же человеком, отметьте это ограничение.
Не обязательно повторять весь продукт. Иногда достаточно убедиться, что новая подпись понятна и состояние после отправки видно. Но если изменение затронуло обработку данных, проверьте также, что прежний рабочий сценарий не сломался.
Храните короткую таблицу наблюдений: задача, результат, помощь ведущего, найденная проблема, изменение и повторная проверка. Она позволяет рассказать жюри, что именно вы узнали. Само число проведённых бесед без этой связи мало объясняет.
Представьте вывод без лишнего масштаба
Укажите количество участников, их связь с целевой аудиторией, формат прототипа и дату проверки. Если проверяли только один сценарий, не называйте продукт полностью протестированным. Если участники были знакомыми разработчиками, не выдавайте их ответы за исследование рынка.
Можно сформулировать результат просто: «В предварительной проверке обнаружили, что подтверждение отправки незаметно. Добавили итоговый экран и повторили сценарий». Это пример формы отчёта, а не реальное измерение команды. Свяжите исправление с демонстрацией проекта, чтобы на финале показать и решение, и основание для него.
Результаты проверки удобно сопоставить с явными критериями. Возьмите шаблон критериев Stavleak за основу внутреннего разбора и замените пункты под свою задачу.
