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

• поиск пользователей.

Поиск пользователей, в свою очередь, можно разбить на пункты поменьше:

• поиск по имени;

• поиск по вхождению слова в описание;

• прочее.

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

В таком случае мы говорим об особенности реализации продукта – Product Feature (в русском языке распространен разговорный вариант «фича»). Например, возможность входа в приложение по отпечатку пальца – это фича, но не функция. Она обеспечивает быстрый доступ к функциям, снижая таким образом нагрузку на пользователей, но не ценна сама по себе.

Вряд ли пользователи скачают приложение с одной-единственной возможностью аутентификации.

Фичи снижают нагрузку в процессе использования функции.

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

Фактор 3. Техническая доступность

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

Фактор технической доступности включает в себя ряд технических аспектов работы приложения, таких как:

• ощущение скорости загрузки содержимого;

• ощущение стабильности работы;

• человекопонятные ошибки; поведение системы в ситуации сбоя (обработка исключительных ситуаций).

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

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

Ниже приведены аспекты, в формирование которых UX-дизайнер способен сделать значимый вклад.

Ощущение скорости загрузки содержимого

Ключевое слово здесь «ощущение». Объективное время загрузки контента может значительно отличаться от субъективного.

Например, наличие различных прелоадеров (preloader, предзагрузчик) и плейсхолдеров (placeholder, местозаменитель) позволяет передать пользователю ощущение того, что, во-первых, система не зависла, а во-вторых, что идет какой-то процесс.

Определенный прелоадер

Неопределенный прелоадер

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

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

Прогрессивная загрузка изображений и миниатюры загружаемых документов или интерфейсов также позволяют уменьшить субъективное время загрузки контента

Прогрессивная загрузка изображения с использованием размытой миниатюры

Помимо субъективного ощущения скорости, имеет значение атрибуция негативного опыта. Атрибуция – это то, как человек объясняет причины явлений. Связывает ли он «тормознутость» с продуктом? А может, винит в задержке операционную систему или мобильную связь?

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

Когда iOS-приложение показывало фирменную анимацию прелоадера, пользователи обвиняли в задержках само приложение, когда же там стал отображаться iOS-спиннер, они переложили ответственность на операционную систему

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

Однажды я проектировал социальную сеть. Тогда как раз выстрелил Facebook, и многие посчитали, что нужно создавать соцсети. Я еще не мыслил в понятиях бережливого производства и коротких итераций, и мои решения были перегружены функциональностью.

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

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

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

Человекопонятные ошибки, поведение системы в ситуации сбоя (обработка исключительных ситуаций)

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

Однажды при запуске минимально жизнеспособного продукта мы решили сократить время до релиза, сэкономив на обработке ошибок. После «мягкого запуска»[13 - От англ. soft launch – открытие для небольшой контролируемой аудитории из органического трафика.] мы, конечно, смогли быстро проверить ряд гипотез, но конверсия в отправку форм сильно упала – у значительного числа пользователей не получалось заполнить форму регистрации до конца. Было принято решение доработать продукт перед «большим запуском». Разрыв оказался столь велик, что с тех пор в нашем плейбуке[14 - От англ. playbook – книга правил игры, по которым живет команда.] появилось правило: «Из текста ошибки пользователю должно быть понятно, как он может решить проблему самостоятельно».

Очень важно, чтобы поведение системы при ошибке (exception, в исключительной ситуации) подсказало пользователю, как ему закончить свое путешествие.

На это влияет несколько факторов.

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

Даже указание на то, что нужно попробовать позже, снимает часть негативного опыта

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

• Время появления. Советующие блоки (tips, подсказки), где сообщается, например, что такое доменное имя занято или что пароль слишком простой, должны появляться до отправки формы – это улучшит опыт.

Фактор 4. Информационная архитектура

Информационная архитектура (англ. Information architecture, часто сокращается до ИА) – сочетание схем организации, предметизации и навигации, реализованных в информационной системе.

    Wiki

На лекциях по информационной архитектуре можно услышать такой вопрос: «Если бы вы делали сайт для продуктов питания, в какой раздел бы вы поместили арбуз?»

Обычно студенты называют много разных вариантов: «Фрукты», «Овощи»; кто хочет выделиться, говорят: «Ягоды» или «Бахчевые». Кто-то предлагает создать специальный раздел «Арбузы» или поместить его сразу в несколько разделов.