Часто параллельно с разработкой прототипа, минимально жизнеспособного продукта (Minimal Viable Product, MVP, подробнее см. главу 5), создается идентификация бренда.

Наблюдая за пользователями, можно убедиться, что от варианта брендинга зависит не только субъективная удовлетворенность клиента (измеряемая, например, с помощью метрики SUS[12]), но и время решения задач.

То, что ныне широко известный Стив Пирс (Steve «Buzz» Pearce){1} сделал для продукта Skype, сильно повлияло на становление термина «цифровой брендинг». Эта работа была одной из наиболее ярких.

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

Если говорить в целом, бренд – неотъемлемая часть продукта и, следовательно, пользовательского опыта. Для создания продукта, который будут по-настоящему любить, нужно разработать сильный, релевантный бренд.

У цифрового брендинга, пожалуй, самый широкий набор способов воздействия на аудиторию.

Функциональность – набор возможностей (функций), которые предоставляет система или устройство.

Функция – способность объекта выполнять работу.

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

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

К функциям продукта применимо свойство многосоставности.

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

• просмотр списка пользователей;

• добавление пользователя;

• удаление пользователя;

• редактирование информации о пользователе;

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

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

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

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

• прочее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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