Как обеспечить надежную защиту вашего пользователя

Не позволяйте нестабильному процессу адаптации пользователей разрушить ваш UX.

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

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

Я сильно увлекся книгами, и мне посчастливилось почти сразу наткнуться на книгу «Пуленепробиваемый веб-дизайн» Дэна Седерхольма.

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

Сейчас эта концепция может показаться очень очевидной, но мне неловко признаться, что в то время она взорвала мой мозг.

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

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

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

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

И это, дорогие друзья, качество, которого мне часто очень не хватает во многих процессах адаптации.

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

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

Все дело в том, чтобы вдумчиво рассмотреть и применить наиболее "пуленепробиваемые" варианты, доступные для нашего опыта онбординга.

В качестве примера рассмотрим…

(Очень) хрупкий шаблон адаптации

Давайте поговорим о подсказках! Вы знаете, эти забавные маленькие друзья:

На первый взгляд они кажутся довольно полезными, не так ли?

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

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

Гораздо более вероятно, что вы нашли их:

• Отвлекающими, например, когда подсказки появляются, когда вы только-только готовы погрузиться во что-то, или, что еще хуже, когда вы уже находитесь в самом процессе.
• Контролирующими, например, когда они занимают весь экран и заставляют вас нажимать «Далее-Далее-Далее-Далее», пока наконец не вернет вас на место водителя.
• Нестабильными, как в тех случаях, когда вас случайно выкидывает из подсказки до ее окончания и вы не можете начать ее снова, чтобы посмотреть, что вы пропустили.

«Отвлекающий, контролирующий и ненадежный» — это описание, больше подходящее ужасному бывшему или оскорблённому Clippy, а не качественному опыту адаптации.

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

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

• Вместо того чтобы отвлекать, давайте стремиться к интегрированности
• Вместо контроля, давайте стремиться расширять возможности
• И вместо нестабильности, давайте стремиться к стойкости

Вместе они объединяются, как Вольтрон, в…

Святая троица пуленепробиваемости онбординга

1. Интегрированный (в отличие от отвлекающего)

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

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

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

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

2. Расширение прав и возможностей (в отличие от контроля)

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

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

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

Пользователи могут делать значимые вещи в вашем приложении — подчеркивайте именно это, а не недостатки вашего интерфейса.

3. Устойчивый (в отличие от нестабильного)

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

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

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

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

Имея в виду эти концепции пуленепробиваемости, давайте выясним, как их можно применить с помощью…

Некоторые гораздо менее хрупкие шаблоны адаптации

Пустые состояния

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

Многие продукты упускают огромные возможности, просто сообщая: «Здесь не на что смотреть». Или, что еще хуже, некоторые даже высказывают предостерегающее осуждение типа «вы еще ничего не сделали».

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

• Интегрированы ли они? Пустые состояния - это самое определение интегрированности: они буквально являются частью вашего продукта, независимо от того, разрабатываете вы их или нет, так что вы вполне можете сделать их эффективными!
• Расширяют ли они возможности? Определенно могут! Это зависит от того, насколько вдумчиво вы переформулируете сообщение «у вас ничего нет» в призыв к действию, который направит людей на то, чтобы сделать что-то значимое.
• Они стойкие? Лучше поверь в это, детка! В отличие, скажем, от вводного тура, эти щенки остаются на месте до тех пор, пока пользователь не сделает что-то для их решения, а значит, они оказывают помощь по расписанию пользователя.

Системы прогресса

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

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

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

• Интегрированы ли они? Хотя они могут быть не совсем естественной частью приложения, они также далеки от того, чтобы отвлекать или прерывать органичный поток внутри продукта. Думайте о них как о отличном запасном варианте для пользователя, а не как об элементе, конкурирующем за его непосредственное внимание.
• Они расширяют возможности? Как и в случае с пустыми состояниями выше, любой опыт адаптации дает вам столько возможностей, сколько вы сами этого захотите. Тем не менее, системы развития относятся к числу моделей, наиболее тесно связанных с стимулированием пользователей к действиям, имеющим реальные последствия, и в этом вся концепция расширения возможностей.
• Устойчивы ли они? Да, абсолютно! Они специально разработаны для долгосрочной работы (подумайте о нескольких посещениях, а не только о первом). Совет для профессионалов: если кто-то достигнет 100% прогресса, вы всегда можете повысить его до уровня 2 и начать новую серию квестов!

Письма жизненного цикла

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

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

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

• Интегрированы ли они? Они вообще не являются частью продукта, поэтому трудно сказать, что они «интегрированы» сами по себе. Опять же, они не делают абсолютно ничего, чтобы отвлечь пользователя от поставленной задачи, как только пользователь заходит в продукт.
• Они расширяют возможности? В идеале, да! Назойливые электронные письма типа «Вы не заходили в систему две недели — мы скучаем по вам!!» не особенно расширяют возможности, но те, которые описывают ключевое действие, которое должен совершить пользователь (и объясняют ему, почему это выгодно), определенно да. Как и во всем, все дело в правильном позиционировании.
• Устойчивы ли они? Когда все сделано хорошо, они абсолютно надежны! Слишком многие компании-разработчики программного обеспечения недостаточно инвестируют в электронные письма жизненного цикла, смиренно отправляя пару, когда кто-то зарегистрируется, и на этом заканчивают. Если то, что вы отправляете своей пользовательской базе, действительно полезно и актуально, вы не должны колебаться при загрузке — подумайте о десятках, а не о паре, и о месяцах, а не днях.

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

Однако, надеюсь, эта структура предоставит вам принципы, по которым вы сможете их оценить.

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

Честный ответ: серебряной пули просто не существует.

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

Автор: Сэмюэл Хьюлик — редактор UX по адаптации пользователей и взаимосвязям.