Быстрое прототипирование (Rapid Prototyping)

Быстрое прототипирование /Rapid Prototyping – это agile-подход создания  прототипов, используемая на протяжении всего процесса разработки продукта. 

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

Как работает прототипирование?

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

Если обратная связь показывает, что прототип довольно далек от истины, компания экономит недели или месяцы, создавая что-то, что не будет работать в реальном мире. В то же время положительная реакция на прототип указывает на то, что концепции продукта находятся на правильном пути, и разработка должна продолжаться.

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

Что такое методы быстрого прототипирования?

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

Эти высокоточные прототипы выглядят и ведут себя как настоящие, поэтому для их жизнеспособности требуется несколько вещей. Во-первых, продуктовые группы должны продумать все варианты использования и пути, по которым пользователи могут работать при взаимодействии с прототипом. Затем необходимо задействовать реальную разработку программного обеспечения и опыт UX, чтобы создать реалистичный, высокоточный прототип.

Однако бывают случаи, когда создание полностью визуализированного прототипа преждевременно или слишком дорого, и здесь на помощь приходит каркасное моделирование. Менеджеры по продукту могут сами создавать прототипы продукта, чтобы проиллюстрировать концепции рабочего процесса и базовые концепции UX.

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

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

Быстрое прототипирование может также включать создание нескольких прототипов для параллельного тестирования (или одновременного тестирования разными группами пользователей). Это позволяет командам решить раз и навсегда, действительно ли вариант А превосходит вариант Б.