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