Хотите лучший дизайн онбординга мобильных приложений? Для начала, поймите, какова активная цель пользователя

Недавно меня натолкнуло на размышления одно электронное письмо. Оно содержало анонс запуска MaterialUp Onboarding Challenge от UpLabs — соревнование для дизайнеров среди сообщества MaterialUp с целью «переосмыслить опыт онбординга на Android» путем создания «веселого, интуитивного процесса освоения приложения по стандартам Material
Design».

Эта задача заставила меня задуматься о моем собственном опыте в освоении мобильных приложений с разных сторон — и как конечный пользователь, и как дизайнер
цифровых продуктов…

Как пользователя, мой опыт в освоении мобильных приложений, как правило…

  1. Быстро забывается:
    Куча всякой всячины, на которую я едва взгляну при попытке получить нужный контент или функционал приложения, которое я использую. (Например: сквозной
    многоэкранный просмотр)
  2. Раздражает:
    Нужно выполнять какие-то задачи, которые мешают мне получить доступ к контенту или функционалу, ради которого я собственно скачал приложение (Пример: требование зарегистрировать аккаунт).

Как дизайнеру, чаще всего при работе над дизайном приложения для клиента, онбординг:

  1. Продумывается как второстепенная задача (для клиента):
    Это часть приложения вне основного функционала, с низким приоритетом. Что-то, на что ресурсы дизайна и разработки будут тратиться, когда будет свободное время (например, мы в последнюю минуту что-то такое допилим).
  2. Реализуется бестолково:
    По инициативе какого-то члена маркетинг- или контент-команды, уверенного в том, что экспоненциальный рост успеха продукта требует всего несколько экранов в помощь пользователю при освоении приложения (например, плюшевые экраны,
    показывающие преимущества и доступные опции продукта).

Все это немного вгоняло в депрессию…

Особенно меня, как дизайнера цифровых продуктов… Который смело заявляет о себе, как о: Пользователь-ориентированном…сфокусированном на комфорте использования… [тут еще несколько ярких эпитетов]. Что я вообще делал? Некачественный онбординг приложения практически целиком подрывало опыт пользователя, и я часть этой проблемы… О ужас!

Гомер Симпсон

И, я решил что-то предпринять…

Процесс создания онбординга

  1. Вдохновение
  2. Ресерч и аналитика
  3. Генерация идей
  4. Концепт-дизайн

Фаза 1: Ресерч, идеация и гипотезы

Начнем… Кабинетный ресерч и аналитика

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

Мой кабинетный ресерч и аналитика, в сочетании с небольшой дозой идеаций, вайтбордом, и парочкой заметками на бумаге, вылились в несколько ключевых инсайтов…

Инсайт

  1. Реализация — это возможность!

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

Реализация - это возможность!

2. Текущее состояние недостаточно оптимальное

Обычно используемые паттерны онбординга почти единодушно навевают на пользователя тоску — они не персонализированные, слишком шаблонные, не вовлекающие и нерезультативные. Чаще, чем хотелось бы, они также не несут никакой РЕАЛЬНОЙ ценности для пользователя, который впервые открывает приложение.

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

Онбординг, которого не достаточно

3. Наш пользователь — не наш приоритет…

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

Наш пользователь - не наш приоритет…

4. Мы утратили любовь…

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

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

Успешный онбординг должен быть абсолютно ненавязчивым

Так… со слабыми сторонами определились, можем ли мы это исправить?

Конечно, можем! Обсудим…

Давайте сделаем это

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

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

Что такое активное намерение? Что это означает?

Пользователь, открывший приложение впервые, может иметь огромный спектр потенциальных потребностей, целей и желаний — это я и называю «активным намерением».

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

Режимы намерений

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

Фреймворк онбординга, который позволяет продукту или сервису лучше видеть нужды пользователя, обеспечить более персонализированное, осмысленное, результативное и приятное взаимодействие с пользователем во время его первого опыта работы в приложении… и вне его. Этот тип взаимодействия будет ощущаться более органично, полезно для пользователя — предоставляя опыт, который удовлетворяет и их функциональные, и эмоциональные потребности, обеспечивая более глубокий коннект.

Ну что ж, все это конечно хорошие идеи, но сейчас настало время создать что-то осязаемое, воплотить теорию в жизнь…

Дизайн концепт
Дизайн концепта

Фаза 2: Дизайн концепта и итерации

Во-первых — очистите свой мозг от всех существующих подходов в онбординге и паттернов взаимодействия… Давайте на несколько минут помыслим иначе.

Дизайн концепта и итерации

Во-вторых — повторите за мной… «Отсутствие онбординга — это новый онбординг».

Или точнее… «Поддержка пользователей через контекстные знания и обучение — это
новый онбординг».

Концепт… Онбординг в мобильных приложениях на основе активного намерения

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

Онбординг на основе потребностей пользователя — это на самом деле вообще не онбординг… Ну, как минимум, в его традиционном понимании.

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

Давайте детальнее изучим концент…

картман

Мой дизайн-процесс… (Как был создан этот концепт)

Дизайн концепта онбординга на основе потребностей пользователя представляет собой сочетание существующих компонентов и кастомного дизайна. Я взял за основу
стандартизированную дизайн-систему (Google Material Design) в сочетании с паттерном широкого взаимодействия (Conversational UI), сплел их воедино и воплотил в жизнь с помощью моего собственного UX-дизайна.

Использование существующих библиотек компонентов и паттернов взаимодействия помогло мне в нескольких смыслах. Во-первых, это сэкономило время — я быстрее воплощал идею в жизнь и фокусировал больше усилий на создании кастомного UX-дизайна. Во-вторых, используя парадигмы дизайна и взаимодействия, знакомые уже многим пользователям, я мог максимально эффективно использовать базу ранее
приобретенных знаний — так как концепт казался более знакомым и понятным.

Мой дизайн-процесс…

Сценарий опыта… (как это работает)

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

При загрузке мы жертвуем типичными засадами онбординга, благодаря чему пользователь не будет сразу же погружен во взаимодействие. Вместо этого мы мгновенно «Дразним» (Tease) его примером контента, который предлагает приложение — четко демонстрируя реальную, осязаемую ценность, которую мы можем предоставить. Почти мгновенно за этим следует «Предложение» (Offer) помочь/подсказать, как достичь цели. (Посмотрите внизу диаграмму сценария).

Сценарий опыта… (как это работает)

Если пользователь отклоняет наше предложение помощи, это нормально — на данный момент мы можем предположить, что они хотят покопаться самостоятельно. Тем не менее, на данном этапе важно «убедить» (Reinforce) пользователя в том, что мы можем предоставить свою помощь в любое время в будущем. Чтобы четко это обозначить, мы обычно отображаем, где и как они могут получить упомянутую помощь в приложении, если и когда она им может понадобиться.

Если они принимают предложение, тогда начинается самое веселое! У нас уже есть разрешение от пользователя, чтобы напрямую вовлечь его в онбординг, по его желанию. Через серию последовательных взаимодействий мы можем обеспечить набор данных касательно их потребностей/целей, определить их активное намерение и «Предоставить» (Deliver) набор релевантных, персонализированных опций для реализации этой потребности.

Звучит круто, правда? А теперь давайте посмотрим, как это можно применить к кейсу из реального мира…

Применение концепта…(Как это можно использовать)

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

Применение концепта...

Определение активного намерения пользователя с помощью гибридных паттернов диалоговых UI-взаимодействий…

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

Используя эти паттерны взаимодействия, пользователь получает подсказку в виде наводящего вопроса. Цель этого вопроса — выделить самый релевантный кусок информации, который можно использовать для определения их потребности и активного намерения. После получения этой информации мы можем провести их по 1 из нескольких дивергентных последовательностей вопросов (не более 3−5 дополнительных вопросов), ответы на которые расширят возможности предоставления релевантного контента или опций.

В примере выше, главный вопрос дает нам понять, «Когда» пользователь хочет пообедать в ресторане. На основе ответа «сейчас» мы понимаем его активное намерение пообедать немедленно. Зная, что их потребность срочная, мы можем задавать дальнейшие вопросы более тактично и лаконично, выдавая обоснованные предположения по месту («Где?»), в котором он хочет пообедать, и количеству людей («Кто») — это дополнительные данные, которые нужно знать, чтобы предоставить набор релевантных вариантов на выбор.

В заключение…

Концепт онбординга мобильных приложений на основе намерений пользователя — это только одна идея по дизайну более осмысленного, вовлекающего, пользователь-ориентированного опыта онбординга. Будь вы дизайнер или разработчик — давайте мыслить иначе, идти на риски и придумывать новые, чокнутые… (может даже инновационные) способы по вовлечению пользователей.

Как и вызов от UpLabs повлиял на меня, надеюсь, что и этот концепт заставил вас задуматься, и вдохновил на создание чего-то! Делитесь вашими мыслями и мнениями (хорошими и не очень) в комментариях. И если вам удалось продумать свой интересный концепт, обязательно поделитесь им!