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

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

И вот стоит техпис посреди огромного опенспейса и не понимает, куда идти, где искать. Информация на портале для сотрудников не помогла. Хорошо, что специалист был самостоятельный, всех нашел, всё разрулил. А что бы сделали вы после такого онбординга?

Онбординг или самовыживание?

Онбординг точно должен быть — это наше мнение.

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

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

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

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

Когда инструкции не нужны

Любому ли сервису нужны инструкции? Мы считаем, что нет.

Вот минимум три случая, когда инструкции можно не писать:

✅ Понятный интерфейс. Только не по мнению разработчиков: такой вывод можно сделать после UX-тестов и когда мало обращений в поддержку. Более понятным делают интерфейс, например, подсказки прямо в нем, эдакие мини-инструкции, но встроенные в интерфейс. А иногда и они не нужны, если сервис простой, и дизайнер хорошо спроектировал интерфейсы.

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

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

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

Какие еще кейсы можете назвать? Или считаете, что инструкции нужны всегда?

#давайте_лайфхак

Что есть, то есть... 😁
Кидайте свои мемчики о работе в комментарии 🙂

#давайте_мем

Где искать вопросы для FAQ

Вот несколько очевидных и не очень источников вопросов для раздела «Вопросы и ответы».

✅ Пройдите все сценарии как пользователь. В процессе фиксируйте возникающие вопросы и сомнения.

✅ Покажите коллегам не из продукта. Можно и друзьям, если они согласятся и NDA позволяет. Главное – незамыленный взгляд.

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

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

✅ Почитайте отзывы в магазинах приложений. Если вы работаете над приложением, которое есть в AppStore и Google Play, мониторьте отзывы там. Пользователи часто пишут в них о возникающих проблемах и непонятных моментах.

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

Есть еще идеи? Делитесь в комментариях.

#давайте_практику

Как писать вопросы и ответы в FAQ. Вредные советы

Создаём раздел вопросов и ответов по вашему продукту, продолжаем тему.

Если вы хотите, чтобы читатель точно убежал со странички вопрос-ответов, сделайте вот что:

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

✅ Спрашивайте не как пользователь, а как адвокат на суде — «В какие сроки осуществляется возврат денежных средств по отмененным заказам?».

✅ Пишите про пользователя в третьем лице, ему же будет приятно читать формулировки вроде «Пользователю нужно отправить заявку».

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

✅ Задавайте закрытые вопросы, а отвечайте как на открытые, это же так логично. «Можно ли оплачивать заказ картой?» — «В нашем сервисе можно оплачивать заказы наличными, СБП, улыбкой, по QR-коду, стикером, картой, чеками и бонусами».

#давайте_практику

Как понять, что скриншоты в инструкции не нужны?

И снова мы про скрины. Давайте поговорим о том, на что обратить внимание, чтобы решить, нужны ли в нашей инструкции скрины из интерфейса.

Сложность интерфейса. Если он простой и неперегруженный, скрины скорее всего вообще не нужны.

Целевая аудитория. Для суперопытных пользователей скрины будут лишними и вызывать только раздражение. Больше вашу инструкцию пользователи не откроют.

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

А сколько скринов в ваших инструкциях?

#давайте_практику

Ура! Питерские техписы теперь тоже могут попасть на профессиональное мероприятие. Если вы из Санкт-Петербурга, регистрируйтесь скорее) мы уверены, будет очень интересно😉

#давайте_анонс