Характерные черты

Высокая детализация и высокая интерактивность

Прототипы этого вида располагаются в правом верхнем углу классификации, приведенной в начале раздела.

Создание высокоуровневых – часто их называют еще Hi-Fi (High Fidelity) – прототипов позволяет проверить поведение пользователей и унифицировать видение в команде. Однако это очень дорогой артефакт с длительным периодом производства. Как правило, при его разработке задействуется большое количество ресурсов команды, иногда сопоставимое с разработкой прототипируемой функциональности, а из-за временны́х затрат на производство и согласование неминуемо увеличиваются сроки поставки.

Если при аддитивной разработке[58] после поставки функции можно быстро среагировать на какую-то проблему и «допилить» улучшение до следующего релиза, то что делать, если проблема обнаружится на этапе тестирования прототипа? Тут нужно переходить на итерационный процесс доработки прототипа, когда прототип тестируется, затем дорабатывается, а после цикл повторяется вновь. Из-за этого разработка начнется значительно позднее – на несколько недель, а то и месяцев.

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

Чтобы определиться со стратегией нового приложения и провести пользовательское исследование совместно со студией Лебедева, мы создали прототип, практически не отличимый по поведению от реального продукта

Как мы уже знаем из раздела «Плоскость скоупа» (см. главу 5), иногда получается так, что изначально нарисованный UX-дизайнером экран изобилует мелкими деталями, которые уходят в процессе декомпозиции типа User Story Mapping (см. там же), и в результате появляется минималистичный, но быстрый с точки зрения реализации вариант. Многие из идей, нарисованных дизайнером, могут вообще никогда не увидеть свет.

Таким образом, из кучи макетов, сделанных «про запас», трудно вычленить самую ценную функциональность, из-за чего команда разработчиков рискует зарыться в излишнюю детализацию.

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

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

Также программируемые прототипы позволяют генерировать уникальное поведение, которое сложно создавать посредством WYSIWYG-редакторов.[59]