Онбординг в Диадоке

Цель онбординга

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

Наследие прошлого

Нашей цели мешала пара вещей.

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

Эти лайтбоксы предлагали:

  • Выпустить сертификат для работы.
  • Отправить заявление участника ЭДО.
  • Оставить почту для того, чтобы мы могли слать рассылки.
  • Посмотреть видео о сервисе и почитать справочные статьи.

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

Решения

Страница «Быстрый старт»

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

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

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

Все это я учла на странице «Быстрый старт».

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

  1. Если у пользователя уже есть сертификат и он был загружен до того, как пользователь попал в сервис, мы не покажем блок про сертификат.
  2. Если заявление участника ЭДО было отправлено другим пользователем из текущей организации, то заново его отправлять не надо — второго блока не будет.
  3. Если почта была подтверждена ранее на этапе регистрации, то и третьего блока может не быть.
  4. Если нет причин показывать все три блока — значит сервис полностью готов к работе, и мы вовсе не будем показывать пользователю страницу «Быстрый старт», а перейдем к онбординговым тултипам, которые ведут к целевому действию. О них рассказываю чуть ниже.

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

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

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

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

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

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

Онбординговые тултипы

Старый онбординг мы совсем перестали показывать на старте. Его место заняли новые тултипы. Они появляются после скрытия страницы «Быстрый старт», когда пользователь оказывается в разделе «Входящие документы». Логика тултипов такая:

  1. Если в этот момент есть входящий документ — предложим подписать его. Такое бывает нечасто, но может случиться, если сам Контур прислал документ на подписание.
  2. Если входящего документа нет, но организацию пользователя приглашает другая организация обмениваться документами, мы позовем пользователя в раздел «Контрагенты». Там пользователь сможет принять или отклонить приглашение контграгента обмениваться документами.
  3. Если нет входящих и никто не приглашает пользователя к обмену документами, мы предложим отправить приглашение своему контрагенту, чтобы обмениваться документами. Позовем в раздел «Контрагенты». Без подтвержденного приглашения обмениваться документами не получится.
  4. Если у пользователя есть хотя бы один контрагент есть, мы предложим создать и отправить первый документ.
  5. На странице самого документа тоже есть тултип, зовущий подписать документ.

Тултипы скрываются после совершения действия, на которое они указывают. Или по кнопкам «Хорошо». В один момент времени у пользователя есть только один тултип.

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

Создание документа

Эта страница есть в основном сценарии пользователя, поэтому ее было решено переверстать.

Страница до переверстки:

Страница после переверстки:

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

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

Юзабилити-тестирование

Мы тестировали на пользователях наш онбординг. Все пользователи с ним справились. Были незначительные трудности, связанные с формулировками. Пользователям было непонятно, зачем нужно заявление участника ЭДО, они с ним не сталкивались ранее. Когда мы добавили фразу о том, что заявление требует ФНС, у пользователей не осталось вопросов.

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

Бонус

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

Когда нужен онбординг

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

Типы онбордингов

  1. Самый плохой тип онбординга — туры без привязки к контексту, целые пошаговые страницы с разной информацией, блокирующие работу в сервисе. В этот момент пользователь еще не видел сервис. Он все забудет, когда приступит к работе. Это самый раздражающий тип онбордингов.
  2. Чуть лучше туры на тултипах, если они не блокируют работу в сервисе. Они возникают по очереди — закрыл один, тут же появился второй. Информация в тултипах не привязана к выполняемому действию. Когда пользователь доберется до использования этих функций, он уже забудет, что было написано в тултипах. Иногда сервисы позволяют включить такой онбординг заново. Но это по-прежнему неудобно. Какое число пользователей будут искать, где его включить и найдут?
  3. Если надо сделать онбординг — лучше делать подсказки контекстно в правильный момент времени. Когда мы знаем, что в данный момент нужно пользователю — это и стоит посоветовать. И ничего другого. Наш онбординг в Диадоке именно такой.
  4. Контекстное обучение новым фичам в сервисе — это хорошо. Это не про новых пользователей, но тоже про онбординг.
  5. Пользователи не читают большие инструкции. Они склонны сразу начать пользоваться сервисом. У этого есть название — Paradox of the Active User. Концепция предложена в начале 80-х в IBM User Interface Institute. С тех пор ничего в поведении людей не поменялось. У пользователей нет мотивации читать тексты. У них есть мотивация начать пользоваться чем-то. Прямо здесь и сейчас. Без лишних слов. Это мотивирует нас делать хорошие интерфейсы, которые понятны без слов и описаний. Что в общем-то хорошо.

И последнее. Важно, чтобы онбординг был:

  1. С минимальным отвлечением — коротко, быстро, мало, нечасто, по делу.
  2. С возможностью скрыть все это счастье и начать работу самому.