Как выбрать формат прототипа для проверки идеи

Формат прототипа выбирают по вопросу, на который нужно ответить. Черновик текста подходит для проверки смысла сообщения, последовательность экранов — для обсуждения пути, интерактивная модель — для наблюдения за действиями. Чем сложнее модель, тем больше работы по её подготовке; добавляйте детали, только если без них нельзя провести нужную проверку.

Опишите действие, которое хотите увидеть

Начните с фразы: «Человек должен суметь…». Например, понять требования к участию в волонтёрской смене, выбрать время или исправить неверно введённые сведения. Эти вопросы требуют разных моделей, даже если относятся к одной будущей услуге.

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

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

Используйте текст и бумагу для ранних вопросов

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

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

Ограничение такого формата — условность взаимодействия. Если ведущий передвигает карточки и объясняет каждый шаг, нельзя утверждать, что участник самостоятельно разобрался бы с сайтом. Запишите, какую помощь потребовалось оказать.

Добавьте взаимодействие, когда оно влияет на ответ

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

Сравнивайте не названия инструментов, а доступные возможности:

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

Покажите процесс, если вопрос не про экран

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

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

Выбирайте доступный формат, который участник способен использовать. Иногда нужны крупный текст, другой способ ввода или работа на привычном устройстве; это следует учесть при подготовке.

Зафиксируйте границу между моделью и продуктом

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

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

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