Эффективный онбординг

Эффективный онбординг

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

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

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

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

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

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

Вопрос: есть команда из трёх человек

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

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

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

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

Стакан UX-писателя всегда наполовину полон.

Не «Информация исчезнет через 5 дней», а «Информация будет доступна ещё 5 дней».

Не «Договор расторгнут», а «Нужен новый договор».

Не «Заплатите, иначе услуга будет приостановлена», а «Чтобы продолжать пользоваться, заплатите до 7 марта».

Не «Услуга доступна не чаще 2 раз в год», а «Можно пользоваться 2 раза в год».

В мире и так много негатива и коронавируса, зачем ещё в приложениях нагнетать?

Подтягивать слабые стороны или усиливать сильные?

Подтягивать слабые стороны или усиливать сильные?

В триатлоне, как ясно из названия, три дисциплины: плавание, велогонка и бег.

Я — начинающий спортсмен, и у меня любительский уровень бега, езды на велосипеде и практически нулевое плавание. Если хотите, подписывайтесь на меня в Страве (https://www.strava.com/athletes/chulakov).

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

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

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

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

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

Итак, фокусировка на своей сильной стороне является эффективным решением с точки зрения развития бизнеса. А фокус внешних коммуникаций на сильной стороне является отличным решением в пиаре. Это называют позиционированием.

Безусловная и непонятная директива

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

Это — безусловная и непонятная директива. Такими директивами обычно общаются непродуктивные ребята, когда приходят с решениями вместо проблем (см. Фичреквесты, которые не стоит выполнять (https://t.me/pmdaily/98)).

Если вы сами начнёте приходить к продуктовым коллегам с решениями вместо проблем — вас начнут валидировать так же, как непродуктовых коллег извне: задавать кучу вопросов о том, что на самом деле у вас болит, проверять болит ли вообще, или может вам просто фичу захотелось.

Будьте подробными: рассказывайте о том, почему пришли к тем или иным решениям. Не «давай перенесём кнопку наверх», а «Эта кнопка — ключевой call-to-action на странице, а я боюсь, что новые пользователи сразу её не увидят» Так вы не только уменьшите количество переписки в трекере, но ещё и опытом с коллегами поделитесь.

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

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

Нашла интервью (https://www.thatexplainsthings.com/the-invisible-voice/) о нейтральном голосе с Сарой Ричардз. Сара руководила контент-дизайном gov.uk, сайта правительства Великобритании. Интервью вот о чем:

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

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

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

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

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