В дописьменном обществе форма посуды могла нести информацию о типе и качестве содержимого. Это, вероятно, первый пример упаковочного брендинга
Уже перейдя во владение покупателя, идентификатор бренда выступает как коммуникативный инструмент – демонстрирует принадлежность к особому классу людей и удовлетворяет таким образом потребность в доминировании. Это касается не только дорогих брендов одежды и часов; можно показывать свое превосходство, отказываясь от дорогих брендов и лейблов или выбирая брендовые товары, потребление которых «спасает мир».
Разумеется, свойства брендинга, связанные с потребительским поведением, такие как:
• идентификация продукта;
• упрощение сравнения продуктов;
• упрощение распространения информации о продукте;
• передача информации о дополнительных свойствах продукта;
• удовлетворение потребности в демонстрации принадлежности к сообществу,
в полной мере переносятся на цифровые продукты и значительно влияют на качество пользовательского опыта.
Часто параллельно с разработкой прототипа, минимально жизнеспособного продукта (Minimal Viable Product, MVP, подробнее см. главу 5), создается идентификация бренда.
Наблюдая за пользователями, можно убедиться, что от варианта брендинга зависит не только субъективная удовлетворенность клиента (измеряемая, например, с помощью метрики SUS[12]), но и время решения задач.
То, что ныне широко известный Стив Пирс (Steve «Buzz» Pearce){1} сделал для продукта Skype, сильно повлияло на становление термина «цифровой брендинг». Эта работа была одной из наиболее ярких.
Помимо классических идентификаторов, таких как знак, цветовая палитра и шрифты, в цифровом брендинге появляются дополнительные – пиктограммы, эмоджи, анимация и даже компоновка экранов.
Если говорить в целом, бренд – неотъемлемая часть продукта и, следовательно, пользовательского опыта. Для создания продукта, который будут по-настоящему любить, нужно разработать сильный, релевантный бренд.
У цифрового брендинга, пожалуй, самый широкий набор способов воздействия на аудиторию.
Фактор 2. Функциональность
Функциональность – набор возможностей (функций), которые предоставляет система или устройство.
Функция – способность объекта выполнять работу.
Даже максимально неудобным продуктом будут пользоваться, если у него нет конкурентов.
Пользователь «нанимает» продукт, чтобы тот что-то сделал для удовлетворения его потребностей. Пользователь продолжит пользоваться вашим продуктом, пока не появится другой, на который можно переключиться.
К функциям продукта применимо свойство многосоставности.
Предположим, функция управления списком пользователей выполняет следующие задачи:
• просмотр списка пользователей;
• добавление пользователя;
• удаление пользователя;
• редактирование информации о пользователе;
• поиск пользователей.
Поиск пользователей, в свою очередь, можно разбить на пункты поменьше:
• поиск по имени;
• поиск по вхождению слова в описание;
• прочее.
Наличие у продукта одной функции говорит о том, что у него пока очень мало конкурентов, но со временем пользователю предлагаются все новые и новые функции. Если два продукта выполняют одинаковую функцию, пользователь выберет продукт, взаимодействие с которым несет меньшие энергозатраты.
В таком случае мы говорим об особенности реализации продукта – Product Feature (в русском языке распространен разговорный вариант «фича»). Например, возможность входа в приложение по отпечатку пальца – это фича, но не функция. Она обеспечивает быстрый доступ к функциям, снижая таким образом нагрузку на пользователей, но не ценна сама по себе.
Вряд ли пользователи скачают приложение с одной-единственной возможностью аутентификации.
Фичи снижают нагрузку в процессе использования функции.
Например, возможность пополнить баланс мобильного телефона – это функция банковского мобильного приложения, а возможность выбрать из адресной книги номер телефона для пополнения – это фича, особенность реализации упомянутой функции.
Фактор 3. Техническая доступность
Даже очень красивое приложение, с прекрасным стилем, великолепной компоновкой и кратчайшими пользовательскими маршрутами пользователь может отвергнуть, если оно тормозит и работает нестабильно.
Фактор технической доступности включает в себя ряд технических аспектов работы приложения, таких как:
• ощущение скорости загрузки содержимого;
• ощущение стабильности работы;
• человекопонятные ошибки; поведение системы в ситуации сбоя (обработка исключительных ситуаций).
Начинающим дизайнерам интерфейсов свойственно полагать, что они не могут влиять на ощущение от технических аспектов работы приложения и что ответственность за отсутствие «глюков» лежит «вот на тех ребятах» (неопределенно указывают в направлении подвала, где сидят «мифические» разработчики).
На самом деле UX-дизайнер, как и любой участник команды, не только несет полную ответственность за опыт, связанный с технической доступностью; в его силах влиять на ситуацию, активно включаясь в работу на всех этапах.
Ниже приведены аспекты, в формирование которых UX-дизайнер способен сделать значимый вклад.
Ощущение скорости загрузки содержимого
Ключевое слово здесь «ощущение». Объективное время загрузки контента может значительно отличаться от субъективного.
Например, наличие различных прелоадеров (preloader, предзагрузчик) и плейсхолдеров (placeholder, местозаменитель) позволяет передать пользователю ощущение того, что, во-первых, система не зависла, а во-вторых, что идет какой-то процесс.
Определенный прелоадер
Неопределенный прелоадер
Определенный прелоадер показывает либо конкретное значение, либо долю загруженного контента. Неопределенный лишь отображает, что происходит загрузка
Плейсхолдеры обозначают место, куда скоро подгрузится элемент интерфейса, и могут быть совмещены с определенными и неопределенными прелоадерами.
Прогрессивная загрузка изображений и миниатюры загружаемых документов или интерфейсов также позволяют уменьшить субъективное время загрузки контента
Прогрессивная загрузка изображения с использованием размытой миниатюры
Помимо субъективного ощущения скорости, имеет значение атрибуция негативного опыта. Атрибуция – это то, как человек объясняет причины явлений. Связывает ли он «тормознутость» с продуктом? А может, винит в задержке операционную систему или мобильную связь?
В приведенном ниже примере дизайнеры заменили фирменный прелоадер Facebook на прелоадер в стиле операционной системы. В результате опыт значительно изменился – пользователи стали соотносить длительность загрузки приложения не с продуктом, а с операционной системой, производительностью смартфона или пропускной способностью сетей передачи данных.
Когда iOS-приложение показывало фирменную анимацию прелоадера, пользователи обвиняли в задержках само приложение, когда же там стал отображаться iOS-спиннер, они переложили ответственность на операционную систему
В моей практике тоже был случай, когда проектирование интерфейса влияло на скорость загрузки.
Однажды я проектировал социальную сеть. Тогда как раз выстрелил Facebook, и многие посчитали, что нужно создавать соцсети. Я еще не мыслил в понятиях бережливого производства и коротких итераций, и мои решения были перегружены функциональностью.
В примере далее дизайнеру ничего не стоит нарисовать в углу аватара «лампочку» – индикатор активности пользователя, но реализация потребует значительных затрат сил со стороны разработчиков и нетривиальных архитектурных решений, повышающих нагрузку на вычислительные ресурсы.
Сейчас я понимаю, что дизайнер должен был быть непосредственным участником команды разработки, ему следовало ориентироваться на системную архитектуру, производительность вычислительной инфраструктуры и, самое главное, вносить корректировки от релиза к релизу. Если бы я руководствовался этими соображениями, дизайн получился бы совершенно другим.
Дизайнер, лишенный связи с командой разработки, может усложнять интерфейс и добавлять менее приоритетные индикаторы и элементы управления, каждый из которых способен значительно влиять на скорость подгрузки объектов
Человекопонятные ошибки, поведение системы в ситуации сбоя (обработка исключительных ситуаций)
Очень много пользовательских путешествий обрывается до пункта назначения из-за того, что из текста ошибки пользователь не понимает, какие дальнейшие действия ему следует предпринять. Особенно этим грешат продукты, созданные в формате Lean Startup, когда разработка ведется кратчайшим путем до осуществления первой продажи.
Однажды при запуске минимально жизнеспособного продукта мы решили сократить время до релиза, сэкономив на обработке ошибок. После «мягкого запуска»[13] мы, конечно, смогли быстро проверить ряд гипотез, но конверсия в отправку форм сильно упала – у значительного числа пользователей не получалось заполнить форму регистрации до конца. Было принято решение доработать продукт перед «большим запуском». Разрыв оказался столь велик,