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