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

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

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

• Онбордингу редко уделяют внимание, сравнимое с уделяемым «основным» фичам продукта, что иронично, учитывая, что онбординг — единственная часть продукта, с которой столкнётся абсолютно каждый пользователь. Странно вкладывать силы в привлечение людей, но не в их удержание.
• Если даже человек прошёл все экраны онбординга, заполнил некий «прогрессбар знакомства» с продуктом, или ему просто показали, как воспользоваться определённой фичей, это не значит, что он будет всем эти пользоваться, тем более долгосрочно.
• Хороший онбординг меньше занят проведением человека через конкретные шаги, важные для бизнеса, и больше тем, как создать у человека приятные моменты, ощущаемые как «успех» с продуктом. Экраны с пошаговым объяснением могут в этом помочь, но обычно в их основе всё же желание бизнеса что-то показать, а не потребности человека.
• Онбординг — это проведение за ручку от фичи к фиче, сценария к сценарию, совмещённое с внимательным слушанием того, что нужно самому пользователю (то есть, какие именно фичи и сценарии нужно показывать). Хороший онбординг начинается с попытки понять, что ищет и чего пытается достичь человек, и создаёт у человека ощущение, что с вашим продуктом он как раз на верном пути.
• Когда человек пробует новый продукт, он на что-то надеется. Хорошо бы понять, на что, и построить онбординг вокруг реализации этой надежды. Если у вас, например, аналитическая система, то человек ей пользуется не ради отчётов, а чтобы получить повышение, доказать свою компетентность коллегам. Иногда можно просто спросить у человека, чего именно он хочет достичь. Когда вы узнаете ответ, удивитесь, сколько всего захотите поменять в своём онбординге. Текст, который написан во всяких онбординговых экранах, должен не описывать фичи, а помогать понять, как люди достигнут с их помощью своих целей.
• Очень полезно опрашивать человека, который только стал вовлечённым пользователем, о том, как именно он прошёл этот путь. Прямо буквально понять, что он делал, какие данные откуда импортировал, в каком формате.
• Онбординг не кончается, когда человек покупает продукт или переходит на платный тариф. Даже когда человек уже стал «платником», может оказаться, что он ещё не получает особой пользы от продукта. Пользователя ещё надо «активировать», то есть довести до конкретных действий, которые заставят его почувствовать пользу от продукта.
• Важно понимать, как принимают решения ответственные за бюджет и технологии, чтобы хотя бы в той части не было затыков.
• Иногда бывает, что в онбординге учат пользоваться какой-то функцией, потому что без этого объяснения она непонятна. А надо сделать понятной.
• Если у вас есть триальная версия, вам нужно убедиться, что за её время человек смог почувствовать пользу продукта. Вы должны понимать, какую проблему человек пытается решить, и помочь ему с этим уже во время триала. В идеале он должен получить то самое вдохновляющее чувство «успеха», что у него что-то там получилось.
• Иногда путь до этого момента длинный, например от идеи сдать комнату до получения первых денег. Но можно хотя бы намекнуть на будущую радость: Эйрбнб показывает «ожидаемый ежемесячный доход» сразу на основе расположения и типа жилья.
• Компьютерные игры — чемпионы в онбординге. Они сразу ведут человека за руку по всему веселью и дают почувствовать вкус успеха.
• Хорошие шаблоны и настройки по умолчанию помогают сократить путь до искомого радостного ощущения.
• На экранах с пользовательскими данными предусмотрите хорошие пустые состояния, которые подскажут, помогут человеку с заполнением.
• Если у вас предусмотрен какой-то «тур» по продукту, дайте человеку возможность начать его позже, когда он сам захочет.
• Когда человек решает переехать с какого-то продукта на ваш, на его решение влияют четыре силы: 1) желание избавиться от проблем, связанных со старым продуктом; 2) надежда на новые возможности с вашим продуктом; 3) инерция, нежелание переучиваться; 4) переживания из-за рисков, связанных с новым продуктом. Для успеха онбординга вы должны усиливать те из них, что работают на вас, и помогать преодолеть те, которые работают против вас.
• Делайте ясные обещания типа «Сэкономьте 15%, потратив 15 минут на работу».
• Люди не любят выглядеть дураками. Они могут переживать, что неумелое использование вашего продукта покажет их такими внешнему миру. Например, они через вашу систему случайно отправят рассылку не тем людям. Поэтому важно, чтобы люди ощущали, что их никто не видит, пока они только пробуют. Нужны всякие тестовые и деморежимы, где всё «понарошку».
• Думайте, как ваш онбординг видят разные люди, которые сталкиваются с продуктом, особенно по мере роста продукта. Если шаг вашего онбординга предлагает ввод данных корпоративной банковской карты, то на нём отвалятся все, кто не имеют к ней доступа (это большинство из тех людей, которые потенциально могли бы стать проводниками вашего продукта в этой компании). Аналогичная проблема может быть, если где-то нужно импортировать закрытые данные. В начале «Интеркома» было нормально предлагать мелким стартапам вставить код на Джаваскрипте на страницу, а сегодня большинство клиентов бы не справились с этим.
• Очень сложно заново получить внимание тех, кто отвалился вот так на полупути, особенно учитывая, что заманить их надо на самый скучный шаг типа ввода тех самых данных банковской карты или, скажем, создание АПИ-ключа. Частая ошибка — моделирование онбординга как строгой последовательности шагов. Всегда должен быть способ пропустить сложное. Всегда стоит предполагать, что прохождение какого-то шага — это работа другого человека; не того, кто сейчас смотрит на наш продукт.
• Элементы интерфейса, связанные с онбордингом, должны быть частью дизайн-системы, иначе все эти подсказки, попапы, велком-скрины и временные подписи выходят из под контроля.
• Не нужно вываливать на человека сразу всё, что вы хотите рассказать. Нет смысла учить пользователя хитрым сочетаниям клавиш в продукте, где он ещё не создал свой первый документ.
• Онбординг, связанный с новыми штуками, не должен мешать пользоваться существующими.
• Чем дольше вы ведёте кого-то за руку, тем меньше его мозг будет работать. Если кормить кормить ребёнка с ложечки постоянно, то она так и не научится держать вилку с ножом. (Видимо мысль тут в том, что избыточное разжёвывание всех фич приводит к тому, что люди ничем так и не научаются пользоваться).
• Думайте об удержании пользователей больше, чем о конверсии. Можно настроить могучую конверсию разными хитростями, но устойчивый бизнес получается, когда пользователи остаются с вами надолго.
• Вместо того, чтобы фокусироваться на запуске новых фич, думайте о том, как делать, чтобы люди начинали активно пользоваться новыми фичами.
• Постоянно регистрируйтесь сами как новые пользователи своего продукта. Хорошо бы, чтобы это было частью чьей-то работы — убеждаться, что всё хорошо и логично работает.

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

Дизайнер говорит, что её попросили добавить экран с картой России, чтобы было видно, где именно сбой произошёл. И у неё вопрос: где должна открываться панель с деталями сбоя, когда тыкаешь на какое-то предприятие на карте — слева, справа или в попапе над картой?

Я говорю: погоди, а зачем карта? «Ну, так попросили, хотят видеть на карте». Зачем? «Им удобно видеть на карте». Но с чего они взяли, что им удобно, если пока такого вида нет? Что они рассчитывают увидеть на карте? Какой важный аспект сбоя раскроется при отображении на карте? Какую роль там играет именно географическое расположение предприятий? Часовой пояс? Близость к столице региона? Климат? Непонятно. «Это хороший вопрос», — говорит дизайнер.

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

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

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