UX/UI дизайн для создания идеального продукта. Полный и исчерпывающий гид

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

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

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

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

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

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

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

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

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

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

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

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

Персонализированные и программируемые прототипы

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

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

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

Примеры программируемых прототипов, созданных при помощи Framer. Слева пример подгрузки транзакций пользователя, справа – подгруженной адресной книги

Дизайн-системы

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

Дизайн-система – это общедоступное хранилище артефактов и стандартов их использования, созданное с целью оптимизации дизайн-процесса.

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

На старте хранилище может представлять собой один файл, лежащий в облаке и доступный всем участникам, а затем превратиться в специфичную библиотеку, организованную при помощи инструментов Figma Community или UXPin Design System Tool.