Как проверить идею прототипом до разработки

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

Начните с предположения, а не с макета

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

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

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

Сделайте модель под выбранный вопрос

GOV.UK Service Manual описывает разные формы прототипов — от бумажных набросков до интерактивного кода. Выбирать форму предлагается по тому, что нужно проверить. Не всякой идее требуется работающая программа.

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

Для проверки понятности письма достаточно черновика сообщения. Для проверки передачи задачи можно разыграть разговор. Такой выбор форматов предусмотрен и в руководстве GOV.UK по проверке идей. Уровень детализации должен позволять наблюдать нужное действие.

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

Дайте задачу без подсказки решения

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

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

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

Отделите наблюдение от объяснения

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

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

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

Решите, что делать после проверки

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

Краткий итог может выглядеть так: «Непонятен статус заявки; меняем сообщение; проверяем различие между отправкой и подтверждением. Спрос и техническую реализацию ещё не оценивали». Такая запись полезнее общей отметки «идея понравилась».

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