Сейчас я понимаю, что дизайнер должен был быть непосредственным участником команды разработки, ему следовало ориентироваться на системную архитектуру, производительность вычислительной инфраструктуры и, самое главное, вносить корректировки от релиза к релизу. Если бы я руководствовался этими соображениями, дизайн получился бы совершенно другим.
Дизайнер, лишенный связи с командой разработки, может усложнять интерфейс и добавлять менее приоритетные индикаторы и элементы управления, каждый из которых способен значительно влиять на скорость подгрузки объектов
Человекопонятные ошибки, поведение системы в ситуации сбоя (обработка исключительных ситуаций)
Очень много пользовательских путешествий обрывается до пункта назначения из-за того, что из текста ошибки пользователь не понимает, какие дальнейшие действия ему следует предпринять. Особенно этим грешат продукты, созданные в формате Lean Startup, когда разработка ведется кратчайшим путем до осуществления первой продажи.
Однажды при запуске минимально жизнеспособного продукта мы решили сократить время до релиза, сэкономив на обработке ошибок. После «мягкого запуска»[13] мы, конечно, смогли быстро проверить ряд гипотез, но конверсия в отправку форм сильно упала – у значительного числа пользователей не получалось заполнить форму регистрации до конца. Было принято решение доработать продукт перед «большим запуском». Разрыв оказался столь велик, что с тех пор в нашем плейбуке[14] появилось правило: «Из текста ошибки пользователю должно быть понятно, как он может решить проблему самостоятельно».
Очень важно, чтобы поведение системы при ошибке (exception, в исключительной ситуации) подсказало пользователю, как ему закончить свое путешествие.
На это влияет несколько факторов.
• Текст ошибки. Насколько понятно из текста, может ли пользователь завершить маршрут самостоятельно? Помимо человекопонятного описания проблемы, очень важно дать инструкции о том, как исправить проблему без посторонней помощи, если это возможно.
Даже указание на то, что нужно попробовать позже, снимает часть негативного опыта
• Расположение блока с ошибкой. Расположение информирующего блока-валидатора непосредственно рядом с полем ввода позволит помочь пользователю не только завершить отправку формы, но и сократить количество попыток ввода.
• Время появления. Советующие блоки (tips, подсказки), где сообщается, например, что такое доменное имя занято или что пароль слишком простой, должны появляться до отправки формы – это улучшит опыт.
Фактор 4. Информационная архитектура
Информационная