UX/UI дизайн для создания идеального продукта. Полный и исчерпывающий гид бесплатное чтение
© Шуваев Я.А., текст, 2022
© Оформление. ООО «Издательство «Эксмо», 2023
О книге
В данной книге я не пытался рассказать обо всех существующих процессах и артефактах, связанных с дизайном цифровых продуктов. Детальные описания процессов сейчас можно найти в Интернете – в «Википедии», электронных книгах и видеоуроках. Моя главная цель – представить факты через призму личного опыта и конкретные примеры из жизни. Это, на мой взгляд, не только сделает теорию более интересной, но и позволит понять, как она связана с практикой.
Занимаясь преподаванием, я обратил внимание на то, что в личном и профессиональном развитии движение идет в направлении от интуитивных практик к контринтуитивным.
Поэтому структура книги выстроена следующим образом.
• Начинаем мы с основных определений, потом выявляем связь между UI- и UX-дизайном. Понимаем, что цифровой продукт – это больше, чем интерфейс, и что опыт не всегда связан с внешней оболочкой.
• Определяем основные факторы, которые влияют на опыт использования цифровых продуктов, помимо интерфейса.
• Процесс работы над дизайном цифровых продуктов представляет собой деятельность на уровне не только внешнего оформления, но и других взаимодействий с интерфейсом. Поэтому дальше мы описываем этот процесс, используя модель слоев UX.
• Интуитивно кажется, что цель работы UX-дизайнера – создавать различные объекты (артефакты), и потому далее мы изучим артефакты, необходимые для реализации продукта на каждом слое.
• Здесь мы приходим к тому, что дизайн продукта – это цикл, тесно связанный с циклом производства этого продукта, и что в его основе могут лежать разные процессы. Для каждого слоя определены свои артефакты и процессы. Артефакты могут быть описаны через порождающие процессы, а процессы – через порождаемые артефакты.
Чтобы не повторять дважды, я описывал новые сущности, как только о них заходила речь. В других частях книги есть ссылки на первое упоминание.
Несмотря на наличие нарратива, книгу необязательно читать по порядку. Вы можете перемещаться в ту часть, которая наиболее актуальна для вас на вашем профессиональном уровне.
О себе
Долгое время я работал в одном из самых известных российских брендинговых агентств – DDVB. Я начинал как дизайнер интерфейсов и разработчик в одном лице. Команда росла и впоследствии превратилась в отдельную компанию, где я занял пост CEO и партнера. Мы сфокусировались на производстве цифровых продуктов под названием Direct Digital и делали проекты для крупнейших отечественных и зарубежных заказчиков, среди которых: Администрация Президента РФ, Внешэкономбанк, Coca-Cola, «Газпром», «Татнефть», «Башнефть», Bosco, QIWI, STADA и др.
В тот момент я увидел, что цифровая трансформация охватывает все больше бизнесов. Клиентские сервисы постепенно переходили в Интернет и мобильные приложения. Цифровые продукты стремительно усложнялись, и появилась необходимость в применении более системного и технологичного подхода к их дизайну. Мы одними из первых в России стали оказывать услуги в области дизайна пользовательского опыта (user experience design).
Сейчас на рынке труда не хватает UX/UI-дизайнеров, их готовы приглашать на хорошие зарплаты ведущие компании по всему миру. Но тогда все лишь начиналось – бизнес уже ощущал потребность в специалистах, но еще не осознавал ее. Клиентский поток был очень маленький. Рынок только зарождался, и ему требовалась помощь.
Одним из стратегических шагов в его формировании стал запуск образовательного курса UX/UI: Digital Product Design в Британской высшей школе дизайна. Он до сих пор входит в число самых известных и успешных образовательных курсов по UX/UI в России. Впоследствии я адаптировал программу курса под онлайн и запустил собственную школу uxacademy.ru.
На курсе мы сделали более ста индустриальных проектов для ведущих продуктовых компаний. Ежегодно сотни человек заканчивают программу, а география студентов выходит далеко за границы стран бывшего СССР.
Я не упускал возможности практиковаться и, помимо основной деятельности, помогал друзьям с UX в их стартапах. В результате такой коллаборации появился проект Agrarus.ru – сельскохозяйственная торгово-логистическая площадка. Погрузившись в мир Agile[1] и Lean Startup[2], я почувствовал, что хочу завязать с выполнением заказов, и примкнул к команде в роли CXO (Chief eXperience Officer).
Мы не получали зарплат и все инвестиции вкладывали в разработку. Для содержания семьи я создал компанию shuvaev.com, и она до сих пор оказывает услуги в области UX-дизайна, консультирования и цифровой трансформации.
Тогда я занимался проектированием и работал как сам по себе, так и с разными компаниями. Ярким опытом была коллаборация с агентством Suprematika, и в ее результате было получено множество отечественных и зарубежных наград за дизайн, включая международную награду Red Dot.
Через некоторое время основной инвестор принял решение остановить финансирование Agrarus.ru по внешним причинам, и меня пригласили развивать мобильный банк «Альфа-Мобайл» в «Альфа-Банке».
Банк находился на волне Agile-трансформации, и на тот момент основные цифровые продукты централизованно разрабатывались в выдающемся офисе подразделения «Альфа-Лаборатория» – мекке цифровых энтузиастов, финтех-гениев и дизайн-мыслителей. За эти потрясающие два года работы мы достигли больших результатов – обновили дизайн мобильного банка и хорошо развили функциональность, что позволило подняться в рейтинге мобильных банков Markswebb с 11-го места на 2-е, 4-е и 1-е места (для операционных систем Android и iOS и в категории «Планшеты»). Аудитория за это время выросла в два раза.
Меня захватил опыт цифровой трансформации банка, и когда мне предложили участвовать в создании компании «Ак Барс Цифровые Технологии» – инновационного центра группы «Ак Барс Банк», – я сразу же согласился и присоединился к команде в качестве руководителя направления R&D.[3]
Пока компания росла, я совмещал несколько ролей.
Как Agile-тренер, я с командой запустил гибкий, бережливый производственный процесс, базирующийся на «бирюзовых» ценностях[4], и в итоге уже с первых месяцев мы получили прорывные результаты.
В роли Scrum-мастера я внедрил Scrum[5] в пяти командах, не без поддержки самих команд, конечно, и это позволило в рекордные сроки обновить цифровой банк, перезапустить его сайт и выпустить ряд других продуктов.
В роли владельца продукта вместе с командой R&D я запустил несколько пилотов, начиная с тех, что обеспечивали быстрые победы, – интеграции c Apple Pay, Android Pay[6] и Samsung Pay, – и продолжая высокотехнологичными проектами в области искусственного интеллекта и автоматизации.
Приведу основные.
• Aimee – система автоматизации контакт-центра на основе искусственного интеллекта, которая более чем в 40 % случаев отвечает за оператора.
• Face2Pay – система оплаты, основанная на распознавании лица.
• Сервис на основе диалогового ИИ, помогающий обычным людям начать инвестировать.
В этой самой любимой роли я пребываю до сих пор, так что ждите новостей.
Затем меня пригласили создавать новую IT-компанию Viasat Tech на позицию директора по цифровым проектам. Мы делаем революцию в области стриминга цифровых развлечений.
Несмотря на то что мне уже практически не приходится рисовать экраны интерфейсов, я по-прежнему считаю себя дизайнером.
Во время своего пути я с уровня оформления внешнего вида продукта погрузился на уровень компоновки объектов, затем на уровень проектирования всей цепочки взаимодействия, потом на уровень определения функциональности продукта и, наконец, добрался до уровня предназначения продукта.
Миссия дизайнера – создавать идеи, которые делают массы людей счастливыми, и неважно, какими инструментами это достигается, – с помощью пера планшета или стратегической сессии. Счастье – запечатленный результат взаимодействия, опыт – конечная цель, и на пути к ней все средства производства и другие артефакты, включая сам продукт, являются лишь инструментами.
Введение
Пользовательский опыт: основные определения
Пользовательский опыт, или опыт пользователя, – буквальный перевод английского выражения User Experience (UX), потомок термина Customer Experience. Связь терминов описана в главе 2.
Термин UX тесно связан с понятием цифрового продукта (Digital Product).
Для дальнейшей работы с книгой введем ряд определений.
Продукт – это результат труда автора или коллектива авторов. Он отчуждается в пользу третьих лиц в обмен на ресурсы, которые в стоимостном эквиваленте превосходят ресурсы, необходимые для производства продукта.
В зависимости от типа продукта «третьих лиц» называют по-разному – потребители, клиенты или пользователи, если речь идет о цифровых продуктах.
Возвращаемые ресурсы в современном мире – это деньги, но может быть также сырье или составные части продукта; для цифровых продуктов – это контент, расширения или элементы кода. Часто под возвращаемыми ресурсами подразумеваются действия, например, приглашение друзей или просмотр рекламы. Такие действия не возвращают ресурсы напрямую, но улучшают жизнеспособность продукта на величину, равную стоимостному эквиваленту затрат на привлечение новых пользователей или размещение рекламы.
Цифровой продукт – продукт, взаимодействие с которым осуществляется через цифровые каналы.
По аналогии с реальными продуктами копии программного обеспечения стали называть цифровыми продуктами. Продаются они точно так же, как и обычные, – коробками в магазинах
Пользовательский опыт – результат взаимодействия с цифровым продуктом, проявляющийся в изменении поведения.
Цифровые каналы (цифровые точки касания) – точки касания сервиса посредством компьютеров.
Этот сценарий покупки билета и прохода на мероприятие с помощью сервиса Face2Pay наша команда продемонстрировала на FinovateFall 2018. Он включает три цифровые точки касания – банковское мобильное приложение, где надо привязать изображение лица к платежной карте, виджет покупки билетов на сайте и видеовалидатор на мероприятии
Метрики продукта – количественные характеристики продукта, полученные с помощью анализа поведения масс аудитории при взаимодействии с цифровым продуктом и отображающие влияние взаимодействия на ресурсы, поступающие от пользователей. Остановимся на этом подробнее.
Под ресурсами в современном мире, как правило, подразумеваются деньги.
Это могут быть платежи в прямом или косвенном виде – просмотры баннеров и переходы по ссылкам на них, привлечение новых пользователей, удержание других пользователей за счет создания контента и пр.
Очевидно, что без притока ресурсов продукт не способен долго существовать и развиваться, поэтому бизнес-метрики очень важны.[7]
Вот основные метрики, с помощью которых оцениваются текущие бизнес-показатели продукта:
• количество активных пользователей, в день (DAU) и в месяц (MAU);
• приток новых пользователей (установки, регистрации);
• удержание пользователей (n-Day Retention – доля оставшихся на n-й день после прихода);
• доход на пользователя (ARPU, Average Revenue per User).
Помимо основных бизнес-показателей – мерил живучести продукта, – часто используются метрики «здоровья» продукта или косвенные метрики для оценки качества опыта; как градусник, измеряющий температуру тела, они помогают выявлять то, что в будущем может стать проблемой.
Новые пользователи появляются каждый месяц, но не все из них остаются. Процент оставшихся на n-й день после прихода называется n-Day Retention
Наглядным и показательным собранием таких метрик считается Google Heart.
Компания Miro разработала шаблон для коллективной работы в фреймворке Google Heart с подробным пошаговым планом: https://miro.com/templates/heart-template/,
Google Heart может быть хорошей основой для создания собственного набора метрик, подходящего для функции или для целого продукта
HEART – это аббревиатура, составленная из первых букв категорий:
• Happiness – метрики «счастья», вроде NPS (Net Promoter Score, индекс сетевого распространения); удовлетворенность, субъективное удобство;
• Engagement – метрики вовлечения, такие как частота использования, вариативность использования функций, количество загруженного контента;
• Adoption – метрики принятия продукта, к которым относятся первичные покупки, подписки, обновления продукта;
• Retention – метрики удержания; n-day Retention был описан выше, но помимо него используется ежемесячный отток и динамика оттока;
• Task Success (успешность выполнения) – время выполнения, скорость выполнения, процент завершенности.
По каждому направлению выписываются метрики, подходящие для конкретного продукта или функции.
И далее для каждого направления уточняются цели, сигналы и метрики.
• Цели – ключевые показатели, на которые ориентируется команда при развитии продукта.
• Сигналы – показатели, по которым можно судить о приближении к цели; например, изменившийся рейтинг в магазине приложений иногда сигнализирует о том, что у продукта изменился показатель удержания.
• Метрики – постоянно отслеживаемые значения; информация о динамике системы используется в принятии решений.
Отдельно хотелось бы выделить из вышеперечисленного букета популярную метрику NPS.
Она помогает оценить желание пользователя посоветовать продукт своим друзьям.
1. Пользователям предлагается ответить на вопрос: «Какова вероятность того, что Вы порекомендуете продукт своим друзьям/знакомым/коллегам?» – оценкой по 10-балльной шкале, где 0 соответствует ответу: «Ни в коем случае не буду рекомендовать», а 10 – ответу: «Обязательно порекомендую».
2. В зависимости от того, кто сколько баллов поставил, потребители разделяются на три группы:
a) 9–10 баллов – сторонники (promoters) товара/бренда;
б) 7–8 баллов – нейтральные потребители;
в) 0–6 баллов – критики (detractors).
3. Производится расчет индекса по формуле: NPS = % сторонников – % критиков
В NPS отсекаются пассивные ответы и учитываются только выраженно положительные или выраженно отрицательные ответы. NPS – хороший индикатор, своего рода промышленный стандарт, позволяющий сравнивать разные продукты между собой
Но вернемся к основным определениям.
Улучшение метрики – изменение метрики, влияющее на увеличение количества ресурсов, поступающих от пользователя. Например, рост притока, удержания или дохода на пользователя.
Качество опыта взаимодействия – результат взаимодействия с продуктом, влияющий на изменение метрик продукта.
Положительный пользовательский опыт – с точки зрения пользователя, это опыт, который стимулирует совершение повторного взаимодействия; с точки зрения бизнеса, это опыт, улучшающий метрики продукта.
На улучшение качества опыта, помимо увеличения частоты взаимодействия, указывает также то, что пользователи начинают осваивать все больше и больше функций продукта, переходить на более продвинутый тарифный план, помогая команде разработчиков, или активнее генерировать контент внутри продукта.
В целом можно сказать, что пользователи с положительным опытом возвращают в продукт ресурсы, увеличивая его жизнеспособность.
Отрицательный пользовательский опыт – тот, от которого ухудшаются метрики продукта и который подавляет желание повторного взаимодействия. Он снижает количество используемых функций, уменьшает объем платежей, качество размещаемого контента или других ресурсов. Словом, из-за негативного пользовательского опыта снижается живучесть продукта.
Фактор UX – свойство продукта, влияющее на качество пользовательского опыта.
Глава 1
Физиологические основы пользовательского опыта
Трудно сказать, где физиологические аспекты поведения человека переходят в психологические. Ученые, изучающие мозг, шутят: «Изучение одного нейрона – это цитология[8], а нескольких нейронов – уже психология».
Чтобы формулировать более качественные гипотезы о том, каким должен быть продукт, дизайнеры, помимо собственного мнения, опираются на данные об использовании продукта, а также на общедоступные факты и закономерности, связывающие поведение человека с метриками. Источниками таких фактов и закономерностей служат науки о мозге и поведении человека. Ниже представлен список не всех, но, по крайней мере, нескольких основных фактов, которые будут учитываться в этой книге.
Факт 1. Скорость получения результата улучшает качество пользовательского опыта
В 1997 году профессор Вольфрам Шульц выявил закономерность в системе внутреннего вознаграждения мозга. Согласно его исследованиям, при положительном опыте взаимодействия нейромедиатор дофамин участвует в механизме закрепления условного рефлекса, а при его отсутствии происходит гашение рефлекса. Другими словами, если ожидание награды оправдывается, сигнал передается в центр наслаждения.
Из-за прямой стимуляции «зоны рая» у крысы выработался устойчивый рефлекс нажимать на рычаг – она так делала до тысячи раз в день
Также выявлена зависимость между скоростью получения награды и интенсивностью поощрения.
Получается, что чем быстрее пользователь получает желаемое, тем выше его удовлетворенность от взаимодействия. А чем выше его удовлетворенность, тем лучше закрепляется рефлекс совершать определенную цепочку действий.
Факт 2. Когнитивная нагрузка влияет на скорость достижения результата и количество ошибок
Под когнитивной нагрузкой понимают усилие, необходимое для удержания в краткосрочной памяти информации, которую нужно обработать.
Джордж Миллер одним из первых выдвинул теорию об ограниченности «оперативной» памяти человека. Согласно ей, память подобна кошельку ограниченного объема, и туда помещается ограниченное количество ментальных объектов (мемов[9] или чанков[10]), требуемых для решения задачи. В истории феномен стал известен под названием «семь плюс-минус два», хотя в исследовании Миллера этих цифр не было.
Долгое время инженеры широко использовали правило «семь плюс-минус два», чтобы создавать эффективные инструкции, а также интерфейсы станков и приборных панелей. Несмотря на интуитивную очевидность, для правила характерна приблизительность и обобщение – в нем не учитываются типы мемов.
Позже группа ученых переосмыслила эксперимент Миллера и уточнила выводы. Было выявлено, что разные типы мемов занимают разный объем в «кошельке», то есть имеют разную эффективность хранения и обработки. Следовательно, время решения задачи зависит не только от количества мемов, но и от их типа.
Самые эффективные из мемов, изученных в исследовании, – цифры. С их помощью люди могут быстрее решать задачи при фиксированном количестве объектов.
В дальнейших исследованиях основоположник теории когнитивной нагрузки Джон Свеллер и его последователи выявили связь между когнитивной нагрузкой и количеством ошибок при выполнении задачи, а также установили несколько видов когнитивной нагрузки:
• внутренняя – связана с непосредственным решением задачи испытуемым, когда он опирается на собственный опыт;
• внешняя – связана с эффективностью обучающей модели, предложенной дизайнером;
• связанная – обусловлена схемой, объединяющей образовательный материал.
Итак, какие из этого можно сделать выводы.
• Снижение когнитивной нагрузки улучшает качество пользовательского опыта. Из-за сокращения нагрузки ускоряется взаимодействие, а значит, и привыкание к продукту; также уменьшается число ошибок, что положительно влияет на конверсии в целевые действия.
• Важно минимизировать количество мемов, необходимых для единовременного удержания в краткосрочной памяти, а также по возможности отдавать предпочтение «компактным», более эффективным типам мемов – например, цветовому кодированию вместо подписей.
• При создании интерфейсов важно учитывать уровень обученности пользователя – это позволит снизить для него внутреннюю нагрузку.
• Чтобы пользователь быстрее освоил новые способы взаимодействия с продуктом, лучше использовать наиболее наглядные и удобные для восприятия способы обучения.
• Необходимо структурировать элементы, с которыми взаимодействует пользователь на пути своего следования к цели, с учетом влияния предыдущих элементов на последующие.
Факт 3. Закрепляется более энергосберегающее поведение
Головной мозг в спящем состоянии потребляет 16 % ресурсов организма, а в активном – 24 %.
Существует большое количество свидетельств того, что в процессе эволюции мозг многих животных увеличивался или уменьшался в зависимости от необходимой для выживания нагрузки. И это происходило не только с простыми организмами типа паразитов, но и с людьми.
Иными словами, основное предназначение мозга – сэкономить энергию для решения эволюционно значимых задач, таких как питание, размножение, забота о потомстве и пр.
Существует подход, основанный на исследованиях о закреплении поведения, при котором результат достигается быстрее, а когнитивная нагрузка становится меньше.
Сравнивая продукты А и Б, мы можем предположить, что пользователь с большей вероятностью переключится на продукт А в случае, если затратит на взаимодействие с ним меньшее количество энергии.
В понятие затрачиваемой энергии входит много элементов:
• энергия, затрачиваемая непосредственно мозгом;
• мышечная энергия, затрачиваемая на взаимодействие;
• ресурсы организма, необходимые для работы мозга, – молекулы питательных веществ и нейромедиаторы.
Максимально достоверно измерить энергию, потребляемую мозгом, позволяет трехмерное сканирование активности мозга в МРТ-аппарате. Так что, несмотря на универсальность этого подхода, специалисты в сфере создания интерфейсов, возможно, еще долго будут ориентироваться на косвенные показатели – количество действий и время, затрачиваемое на каждое действие.
Глава 2
Связь User Experience и Customer Experience
Иногда для иллюстрации связи этих двух терминов используют диаграмму:
Если рассматривать банковский бизнес:
• Human Experience (с англ. опыт человека) описывает опыт всех людей во взаимодействии с сервисами банка – это могут быть даже потенциальные сотрудники банка, которые заполняют анкету соискателя на сайте;
• Prospect Experience (с англ. опыт потенциального клиента) описывает опыт потенциальных клиентов, взаимодействующих, например, с посадочной страницей акции или со стойкой выдачи кредита в гипермаркете;
• Customer Experience (с англ. опыт клиента) описывает опыт клиентов при получении услуги, скажем, при совершении перевода в отделении банка;
• User Experience (с англ. опыт пользователя) описывает пользовательский опыт при получении услуги через цифровые каналы, например, при совершении перевода в мобильном приложении банка.
Порядок и вложенность кругов может меняться.
Если человек, не являющийся клиентом банка, оформляет кредит на его сайте, он в этот момент еще не считается клиентом, но уже становится пользователем банковских сервисов. И наоборот, если клиент оформил кредит в отделении и не прибегал к цифровым каналам, его нельзя назвать пользователем.
В итоге можно сказать, что:
• деление опыта на клиентский и пользовательский условно и зависит от предметной области;
• если взаимодействие с сервисом происходит только через цифровые точки касания, то такой опыт можно назвать пользовательским (User Experience); если же часть шагов осуществляется через нецифровые точки касания, то это, скорее, клиентский опыт (Customer Experience).
Глава 3
В чем разница между UX- и UI-дизайном?
Выступая перед студентами, я часто задаю им такой вопрос и получаю совершенно разные ответы. Вот самые распространенные:
• «UI-дизайн – про красоту, а UX-дизайн – про удобство»;
• «UXD (UX design) – это рисование прототипов, а UID (UI design) – рисование макетов»;
• «UXD – это проведение исследований, а UID – создание финального интерфейса»…
Давайте попробуем разобраться.
Очевидно, что если у продукта есть пользовательский интерфейс, то он влияет на качество пользовательского опыта. Но он не всегда выступает точкой касания; иногда взаимодействие осуществляется через интерфейс другого продукта (когда продукты связаны через API[11]) или через пуш-уведомление, в таком случае на качество опыта сильно влияют скорость отклика и сообразительность поискового алгоритма под капотом. Помимо этого, есть масса других факторов, которые влияют на качество опыта и притом не связаны с интерфейсом.
Отсюда можно сделать вывод, что при работе над дизайном пользовательского опыта мы оперируем бо́льшим количеством факторов, чем при работе над дизайном пользовательского интерфейса.
Чтобы студентам было проще разобраться, я предлагаю им заполнить пропуски в шаблоне:
Ужасный интерфейс, но я ЛЮБЛЮ продукт, потому что ______________________.
Или как вариант:
Прекрасный интерфейс, но я НЕНАВИЖУ этот продукт, потому что ______________________.
Хотя задача касается только тех UX-факторов, что не относятся к пользовательскому интерфейсу (UX без UI), студенты часто вспоминают UI-факторы, и они тоже фиксируются на доске.
В результате, если времени на задачу достаточно, получается что-то вроде эйлеровой диаграммы с множеством факторов, влияющих на UX. И лишь некоторые из них связаны с UI.
Можно спорить о корректности названий факторов, а также о том, насколько близки некоторые из них и вправе ли мы их объединять. Также можно допустить, что здесь указаны не все факторы, а только те, которые автор посчитал наиболее значимыми в повседневной практике. Несмотря на это, чтобы понять, какими красками UX-дизайнер рисует пользовательский опыт, предлагаю разобрать приведенные факторы – те, что относятся именно к UX без UI. UI-факторы будут рассмотрены в других главах.
Глава 4
Факторы UX
Фактор 1. Брендинг
Если посмотреть, что сейчас происходит на любом сформировавшемся рынке, то можно увидеть, что расстояние между участниками стремительно сокращается, форма и размеры устройств унифицируются, функции и технические характеристики перестают значимо различаться. Что же заставляет нас предпочитать один смартфон другому, несмотря на кажущееся сходство? Одна из причин – это бренд.
Brand в переводе с английского – клеймо; пастухи метили скот, чтобы отличать коров, принадлежащих разным семействам.
На первых рынках покупатели сравнивали скот и другие продукты, производимые разными семействами, и у них устанавливалась прочная ассоциативная связь между характеристиками продуктов и клеймом. Это упрощало задачу повторного сравнения. В следующий раз когнитивная нагрузка, связанная с выбором, снижалась – потребители отдавали предпочтение товарам с уже знакомым визуальным идентификатором.
Визуальным идентификатором может быть не только знак, но и другие детали оформления, например, цвет упаковки или декоративные элементы.
Кроме того, отправляя кого-нибудь на рынок, удобнее не описывать характеристики продукта, а назвать имя семьи производителя (аудиальный идентификатор) или показать, как выглядит товарный знак (визуальный идентификатор). В этом случае мы говорим о том, что идентификаторы бренда упрощают распространение информации о продукте.
Помимо идентификационной, товарный знак может иметь коммуникативную функцию – иногда в нем передается сообщение о свойствах продукта.
В дописьменном обществе форма посуды могла нести информацию о типе и качестве содержимого. Это, вероятно, первый пример упаковочного брендинга
Уже перейдя во владение покупателя, идентификатор бренда выступает как коммуникативный инструмент – демонстрирует принадлежность к особому классу людей и удовлетворяет таким образом потребность в доминировании. Это касается не только дорогих брендов одежды и часов; можно показывать свое превосходство, отказываясь от дорогих брендов и лейблов или выбирая брендовые товары, потребление которых «спасает мир».
Разумеется, свойства брендинга, связанные с потребительским поведением, такие как:
• идентификация продукта;
• упрощение сравнения продуктов;
• упрощение распространения информации о продукте;
• передача информации о дополнительных свойствах продукта;
• удовлетворение потребности в демонстрации принадлежности к сообществу,
в полной мере переносятся на цифровые продукты и значительно влияют на качество пользовательского опыта.
Часто параллельно с разработкой прототипа, минимально жизнеспособного продукта (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] мы, конечно, смогли быстро проверить ряд гипотез, но конверсия в отправку форм сильно упала – у значительного числа пользователей не получалось заполнить форму регистрации до конца. Было принято решение доработать продукт перед «большим запуском». Разрыв оказался столь велик, что с тех пор в нашем плейбуке[14] появилось правило: «Из текста ошибки пользователю должно быть понятно, как он может решить проблему самостоятельно».
Очень важно, чтобы поведение системы при ошибке (exception, в исключительной ситуации) подсказало пользователю, как ему закончить свое путешествие.
На это влияет несколько факторов.
• Текст ошибки. Насколько понятно из текста, может ли пользователь завершить маршрут самостоятельно? Помимо человекопонятного описания проблемы, очень важно дать инструкции о том, как исправить проблему без посторонней помощи, если это возможно.
Даже указание на то, что нужно попробовать позже, снимает часть негативного опыта
• Расположение блока с ошибкой. Расположение информирующего блока-валидатора непосредственно рядом с полем ввода позволит помочь пользователю не только завершить отправку формы, но и сократить количество попыток ввода.
• Время появления. Советующие блоки (tips, подсказки), где сообщается, например, что такое доменное имя занято или что пароль слишком простой, должны появляться до отправки формы – это улучшит опыт.
Фактор 4. Информационная архитектура
Информационная архитектура (англ. Information architecture, часто сокращается до ИА) – сочетание схем организации, предметизации и навигации, реализованных в информационной системе.
Wiki
На лекциях по информационной архитектуре можно услышать такой вопрос: «Если бы вы делали сайт для продуктов питания, в какой раздел бы вы поместили арбуз?»
Обычно студенты называют много разных вариантов: «Фрукты», «Овощи»; кто хочет выделиться, говорят: «Ягоды» или «Бахчевые». Кто-то предлагает создать специальный раздел «Арбузы» или поместить его сразу в несколько разделов.
Налицо противоречие между некой «правильной» структурой разделов классификатора (в этом случае таксономией) и той структурой, которую ожидают увидеть разные группы пользователей.
Таксономия арбуза согласно APG II – таксономической системе классификации цветковых растений
Для выявления того, в каких разделах должны находиться элементы, чтобы пользователи их быстрее нашли, применяют инструмент карточной сортировки. Пользователям предлагают самостоятельно разложить карточки по разным разделам и дать им имена.
Сортировка физических карточек или стикеров лишена ограничений онлайн-инструментов и позволяет увидеть нетривиальные связи между объектами
Помимо офлайн-инструментов, существует множество специализированных онлайн-инструментов, таких как OptimalSort, UsabilityTools (UXSuite), хотя можно использовать и универсальные сервисы, такие как Trello или Miro.
Карточная сортировка в Trello
Так какой же таксон выбрать для арбуза?
В приведенном ниже меню фастфуда картофель фри и кола намеренно разместили в разделе с бургерами, чтобы сократить маршрут пользователя при формировании заказа. Я был очень признателен дизайнеру подобного меню, когда однажды на морозе не очень удобно припарковался около сенсорного экрана; этот принцип информационной архитектуры уменьшил время заказа.
Такие каталоги создаются на основе принципа сервисных тоннелей.
Принцип сервисного тоннеля позволяет сэкономить количество шагов при формировании заказа
Сервисный тоннель (service tunnel) – это принцип построения сервиса, когда после продажи основной услуги клиенту тут же предлагается следующая, которая ему с большой вероятностью понадобится. Понятие пришло из маркетинга, где является созвучным логичным развитием популярного термина «воронка продаж» (service funnel).[15]
Примерами сервисных тоннелей служат многочисленные сайты по продаже авиабилетов: после продажи билета клиенту предлагается страховка, выбор лучшего места, приоритет при входе в самолет, бронирование отеля и аренда авто и т. д.
Можно сказать, что мы проектируем структуру приложения, стремясь снизить когнитивную нагрузку на пользователей (см. главу 1). То есть сделать так, чтобы их путешествие было самым коротким, а время, потраченное на принятие решения о дальнейших шагах, минимальным.
Например, мы можем составить карты путешествий для различных ситуаций, в которые попадают пользователи. Объединив их, мы получим оптимальную структуру разделов для основных пользовательских сегментов.
Приведу пример многолетней давности. От меня требовалось разработать оптимальную структуру разделов сайта для компании-застройщика, у которой было несколько жилищных комплексов.
Тогда для описания сегментов целевой аудитории использовали модную в то время методику персон.[16]
В брифе заказчик выделил персон пяти типов:
• «инвестор» – человек, который покупает квартиру для сбережения и приумножения финансов;
• «трудоголик» – покупает жилье рядом с офисом;
• «молодой семьянин» – человек, у которого появилась семья и которому нужно съехать от родителей; на этом этапе для него важно иметь пусть бюджетную, но собственную квартиру и минимальное число объектов городской инфраструктуры;
• «молодой родитель» – вариант «молодого семьянина», которому нужно съехать от родителей из-за рождения ребенка; для него важны объекты детской инфраструктуры рядом с домом и экология;
• «пенсионер» – человек, который после выхода на пенсию решает переехать за город; для него важны экология и вид за окном.
Каждая такая персона действует, руководствуясь своими побуждениями. Проблема моделирования персон заключается в том, что у нескольких демографических групп может быть одна и та же мотивация. В более современном подходе Jobs to Be Done (см. главу 7) на смену персонам приходят жизненные ситуации, в которых иногда оказываются совершенно разные люди.
Например, мотивация персоны «инвестор» присуща всем людям с потребностью сберечь и приумножить свои средства, вне зависимости от пола, возраста и семейного положения. Подробнее о разнице в подходах читайте в разделе, посвященном Jobs to Be Done.
Персоны: все.
Жизненная ситуация: человек сравнил все варианты и решил купить жилье у нас.
Job Story: я сравнил варианты и выбрал объект, так что теперь хочу видеть перед собой карточку квартиры, чтобы во время звонка мог верно передать описание интересующей квартиры.
Мастер-бренд – это компания-застройщик, саббренд – жилищный комплекс (ЖК) застройщика
Персоны: все.
Жизненная ситуация: человек находится в процессе выбора квартиры, и ему не хватило информации на сайте.
Job Story: когда я только начинаю искать объекты недвижимости, я хочу сравнить между собой несколько квартир, чтобы позвонить насчет одной из них.
Персоны: «трудоголик»; «молодой родитель».
Жизненные ситуации: много времени уходит на дорогу до работы; много времени уходит на дорогу с ребенком до ближайшего парка или детской площадки.
Job Story 1: когда у меня уходит много времени на поездку до работы, я хочу видеть карту с расположением квартир, чтобы выбрать ближайшую к офису.
Job Story 2: когда у меня уходит много времени на дорогу до объекта детской инфраструктуры, я хочу видеть эти объекты на плане рядом с домом, чтобы выбрать квартиру, оптимальную по расположению.
Персоны: «инвестор»; «молодой родитель».
Жизненные ситуации: человек хочет вложить часть сбережений в квадратные метры; ребенок растет, и скоро ему понадобится отдельная комната.
Job Story 1: когда мне надо инвестировать в квартиру, я хочу видеть соотношение стоимости квартиры и эффективной площади, чтобы выбрать объект.
Job Story 2: когда ребенку нужна отдельная комната, я хочу видеть соотношение стоимости квартиры и планировку, чтобы выбрать объект.
Персоны: «молодой семьянин».
Жизненные ситуации: необходимо как можно быстрее съехать от родителей с минимальным бюджетом.
Job Story: когда нужно как можно быстрее съехать от родителей с минимальным бюджетом, нужен список действующих акций от застройщика, чтобы точно выбрать самое выгодное предложение.
Персоны: «пенсионер».
Жизненные ситуации: появилось свободное время для жизни за городом в хорошей экологической среде.
Job Story: когда есть возможность жить за городом, я хочу видеть фотографии окружающей природы и видов из окна моего потенциального жилья, чтобы выбрать максимально экологичное место.
У каждого путешествия внутри системы линейная структура, однако, когда мы начнем их объединять, то увидим, что у части путешествий есть точки пересечения. Для целостного восприятия информационной архитектуры все полученные карты нужно собрать в единую диаграмму, где будут отражены все маршруты всех групп пользователей.
Такое представление называется диаграммой пользовательского потока (User Flow).
Основные принципы построения диаграммы потока:
• путь каждой группы пользователей состоит из минимального количества шагов;
• отсутствуют шаги с дублирующейся функциональностью;
• каждое путешествие имеет конец или содержит целевое и значимое для бизнеса действие.
На основании диаграммы пользовательского потока можно спроектировать структуру разделов сайта так, чтобы основные сегменты аудитории тратили минимальное количество энергии для достижения результата.
Итоговая структура разделов сайта оптимальна с точки зрения количества шагов, совершаемых каждой группой пользователей для достижения результата
Итак, какие можно сделать выводы.
• При проектировании структуры разделов следует исходить не только из научных способов организации и классификации, но также принимать во внимание пользовательские ожидания.
• При создании дерева структуры следует стараться, чтобы маршрут путешествия по нему большинства пользователей был минимальным, например чтобы самые востребованные функции лежали ближе к точке входа. Для этого нужно разбить аудиторию на сегменты и выявить базовые потребности каждого. Для такого анализа можно воспользоваться популярными подходами, основанными на персонах (Personas) и на работе к выполнению (Jobs to Be Done).
• Иногда имеет смысл располагать элементы в «неправильных» категориях, так как инородный объект может закрыть потребность, которую не закрыли элементы, расположенные в «правильных» категориях.
Фактор 5. Стиль повествования
В течение жизни мы играем множество ролей в разных ролевых моделях. Начинаем с модели «ребенок-взрослый» в роли «ребенок», а затем постоянно переключаемся между моделями и ролями: «ребенок-ребенок», «ученик-учитель», «взрослый-взрослый».
Понимание коммуникативной функции ролевой модели позволяет более качественно прогнозировать результат взаимодействия и быстрее принимать решение о следующем действии. В эпоху интеллектуальных ассистентов особенно важно определять роль цифрового продукта в коммуникации и модель взаимодействия.
Стиль повествования помогает пользователю быстро сориентироваться, в какой ролевой модели ему предстоит взаимодействовать с продуктом.
«Альфа-Лаборатория» поставила эксперимент, в котором было создано мобильное приложение, альтернативное основному мобильному банку для физических лиц – Alfa-Sense. Целевой аудиторией выступали цифровые тренд-сеттеры – инноваторы, желающие первыми попробовать новый опыт. Концепция подразумевала, что это будет приложение-друг, умный ассистент, который помогает легко управляться с личными финансами. И, конечно же, приложение общалось с пользователем на «ты» от первого лица.
Один и тот же оператор контакт-центра в одном канале общался с клиентом на «ты», а в другом – исключительно на «вы»
Получилось так, что один и тот же оператор контакт-центра в одном канале общался с клиентом на «ты», а в другом переходил на «вы».
Опыт показал, что клиенты «Альфа-Мобайл» не приняли бы панибратский тон, точно так же как и клиенты Alfa-Sense отстранились, услышав «вы» от своего финансового помощника.
Фактор 6. PR
Связи с общественностью (Public Relations, PR, пиар) – совокупность технологий, помогающих при формировании образа объекта или идеи у той или иной социальной группы.
В современном мире, где активно развивается культура копирования, продуктам уже очень тяжело конкурировать только за счет функциональности.
Все чаще на предпочтения влияют такие свойства компании, как социальная ответственность, корпоративная культура, идеология и нравственные ориентиры.
Например, предпочтение продуктов компании Basecam (ранее 37signals) во многом обусловлено теми идеями и той культурой производства, которую основатели пропагандируют в литературе{2}, – работа без офисов (remote, удаленная) и возвращение к классическим бизнес-подходам в создании прорывных продуктов (rework).
Из отечественных компаний выделяется Tilda – ее публичная активность разительно отличается от традиционного подхода к корпоративному PR.
Facebook-канал Tilda реально интересно читать.
Помимо статей об обновлении продукта, там публикуется много интересного о жизни команды.
Живые сообщения от первого лица мотивирует поддерживать продукт и формирует к нему очень теплое отношение.
Так же как DevOps и UX, PR – это не элемент для названия чьей-то роли в команде, а культура и практики, которых придерживаются ее участники.[17]
Есть хороший подход, когда каждый член команды выступает пиарщиком и пишет для СМИ о своей работе или продукте. Впервые я столкнулся с ним в «Альфа-Лаборатории» – PR-шеф, вместо того чтобы писать скучные пресс-релизы, договорилась с профильными СМИ о публикациях интервью и материалов от разработчиков, дизайнеров и менеджеров продукта.
Такой подход отлично работает сразу в двух направлениях. С одной стороны, мы получаем честный, актуальный и увлекательный контент от первого лица, где создатель с гордостью описывает новую функциональность продукта. С другой стороны, площадка, где выходит публикация с рассказом о продукте, проникается ценностями и сама внутренне становится пропагандистом.
Фактор 7. Пуш-уведомления
Как уже говорилось ранее, пользовательский опыт формируется не только в результате взаимодействия с интерфейсом приложения. Одна из сторонних точек касания – пуш-уведомления. Формально пуш-уведомления – часть интерфейса операционной системы или браузера; они отправляются через специальный сервис и, следовательно, должны описываться позже, в разделе об API; однако, на мой взгляд, они заслуживают отдельного раздела.