{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Блоги: заметки с тегом Онбординг", "_rss_description": "Автоматически собираемая лента заметок, написанных в блогах на Эгее", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": false, "_itunes_explicit": "no", "home_page_url": "https:\/\/blogengine.me\/blogs\/tags\/onbording\/", "feed_url": "https:\/\/blogengine.me\/blogs\/tags\/onbording\/json\/", "icon": false, "authors": [ { "name": "Илья Бирман", "url": "https:\/\/blogengine.me\/blogs\/", "avatar": false } ], "items": [ { "id": "137665", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/questions-dump\/", "title": "Свалка вопросов", "content_html": "

Я рассказывал, почему плохо встречать пользователя онбордингом<\/a>, и показывал, как хорошо сделано в Телеграме, что информация о новых фичах появляется в отдельном чате, который можно посмотреть, когда дойдут руки.<\/p>\n

Вот похожий паттерн в «Настройке» у Эпла:<\/p>\n

\n $\"\"$ \n<\/div>\n

Вместо того, чтобы задавать мне десяток вопросов перебивающими друг друга диалогами, как они делают в большинстве случаев, тут они собирают вопросы в один экран, где с ними можно разбираться по желанию. Это я заскриншотил после того, как один из вопросов уже снял.<\/p>\n

Назовём такой паттерн «Свалка вопросов». Когда свежеустановленная программа хочет доступ к микрофону, геолокации и чему-то там ещё, хорошо бы ей тоже собрать все свои требования в одном понятном месте.<\/p>\n", "date_published": "2025-10-06T10:12:06+05:00", "date_modified": "2025-10-06T10:11:57+05:00", "tags": [ "Онбординг", "пользовательский интерфейс" ], "author": { "name": "Илья Бирман", "url": "https:\/\/ilyabirman.ru\/meanwhile\/", "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764" }, "_date_published_rfc2822": "Mon, 06 Oct 2025 10:12:06 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "137665", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": null, "og_images": [] } }, { "id": "132997", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/think-on-29\/", "title": "Думаем дальше № 29 — «Засунули в банку с музыкой без предупреждения» c Мишей Нозиком", "content_html": "

С Мишей Нозиком обсуждаем техно, оркестровую классику и немножко живопись, а также онбординги и радость открытия в интерфейсах.<\/p>\n

Все выпуски подкаста:
\n Эпл<\/a> · Ютюб<\/a> · Я.Музыка<\/a> · Мейв<\/a> · РСС для подкастного приложения<\/a><\/p>\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
0:00<\/td>\n Что интересного в техно и в классике<\/td>\n <\/tr>\n
10:08<\/td>\n Музыка — это не язык<\/td>\n <\/tr>\n
13:02<\/td>\n Что значит «музыка работает»? Движение, эмоции, охреневание<\/td>\n <\/tr>\n
16:20<\/td>\n Про академическое пение и пение вообще<\/td>\n <\/tr>\n
20:36<\/td>\n Техно и сюжет<\/td>\n <\/tr>\n
27:38<\/td>\n Типографическая композиция против шрифтового логотипа<\/td>\n <\/tr>\n
30:30<\/td>\n Слушаем Малера и Стравинского с открытым ртом (прям с кусочками аудио, тут лучше слушать на оригинальной скорости)<\/td>\n <\/tr>\n
32:57<\/td>\n Значение исполнения и композитора<\/td>\n <\/tr>\n
35:50<\/td>\n Влияние «момента» на восприятие музыки<\/td>\n <\/tr>\n
38:19<\/td>\n Мелодия и альтернативные исполнения произведений<\/td>\n <\/tr>\n
42:55<\/td>\n Когда нравится любая картина, лишь бы на ней были медведи в сосновом бору. Параллели с живописью<\/td>\n <\/tr>\n
47:26<\/td>\n Онбординги и радость открытия<\/td>\n <\/tr>\n
56:01<\/td>\n Ситуация во Вкусвилле<\/td>\n <\/tr>\n
58:10<\/td>\n Высший пилотаж — создавать условия для эврики<\/td>\n <\/tr>\n
1:03:38<\/td>\n Канал для ненапряжного обучения фичам и распространения знаний о продукте<\/td>\n <\/tr>\n
1:10:26<\/td>\n Как неудачный стартовый экран отрубает аудиторию<\/td>\n <\/tr>\n
1:13:45<\/td>\n Изменение координат кучки объектов в Фигме<\/td>\n <\/tr>\n<\/table>\n", "date_published": "2024-11-29T18:34:51+05:00", "date_modified": "2024-12-18T11:17:37+05:00", "tags": [ "Думаем дальше", "музыка", "Онбординг" ], "author": { "name": "Илья Бирман", "url": "https:\/\/ilyabirman.ru\/meanwhile\/", "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764" }, "_date_published_rfc2822": "Fri, 29 Nov 2024 18:34:51 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "132997", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": null, "og_images": [] } }, { "id": "122516", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/onboarding\/", "title": "Онбординг", "content_html": "
\n $\"\"$ \n<\/div>\n
Часто при запуске приложения нас встречает экран, призванный рассказать о приложении в целом или о недавно добавленных фичах. Экран может состоять из нескольких страниц, которые нужно просмотреть по очереди. Как правило, есть кнопка, чтобы пропустить это всё и перейти к основному интерфейсу приложения. Обычно это называют «онбординг».<\/p>\n
Делать так — плохая практика.<\/p>\n
Утверждение может показаться вам абсурдным, ведь онбординги делают очень многие. К сожалению, вопросом «а не фигню ли мы делаем?» в основном даже не задаются. В моей практике бывало, что я спрашивал, зачем это, и слышал: «ну как, это ж онбординг!». Люди даже не замечали, что это не отвечает на мой вопрос — настолько сильно́ убеждение, что надо делать именно так.<\/p>\n
Давайте разберёмся, что плохого в онбординге, какую задачу он призван решать, и как решать эту задачу хорошо.<\/p>\n
Если совсем коротко, то онбординг появляется не вовремя, мешает воспользоваться приложением, а когда информация из него действительно понадобится, её уже будет не найти. Это вызывает фрустрацию и закрепляет привычку пропускать сообщения, не читая. Лучше элементы обучения делать частью интерфейса и предусматривать в нём постоянное место для информирования об обновлениях.<\/p>\n
Рассказ о приложении в целом<\/h3>\n
Сначала рассмотрим онбординг с рассказом о приложении в целом.<\/p>\n
В наиболее тупом случае это реклама: страницы онбординга нахваливают приложение и его фичи. Но рекламировать приложение, которое человек уже и так установил и запустил, глупо: мы уже получили искомое внимание; пора переставать за него бороться и начать конвертировать его в пользу. Сам пользователь также имеет ожидания от приложения, хочет начать им пользоваться, и вынужден с раздражением преодолевать нашу преграду. Так что рекламу нужно просто убрать.<\/p>\n
В чуть менее тупом случае онбординг пытается обучать тому, как пользоваться приложением: вот так у нас заказать пиццу, вот так сделать перевод за рубеж; нажмите вот тут, и случится вот это. Если пользователь это и так знает, то это снова просто раздражающее препятствие на пути к цели. Если же пользователь не знает, то мы ставим его в идиотское положение: получается, ему сейчас нужно внимательно это прочитать и запомнить, чтобы потом применить полученные знания в настоящем интерфейсе, которого он даже ещё не видел. Невозможно даже оценить, насколько внимательным нужно быть и как тщательно запоминать: может, в реальном интерфейсе я и без этого разберусь?<\/p>\n
Просто представьте, какой это абсурд: вы купили новую стиральную машину, а вам насильно вручают инструкцию и говорят: «вы можете её выкинуть, но если потом что-то будет непонятно, никто не поможет». А что, там без инструкции не разобраться? Не знаем. Ну, а нельзя просто, чтобы инструкция лежала в коробке, и я её возьму, если понадобится? Нет, нельзя: нужно или прочитать сейчас, или выкинуть.<\/p>\n
Тут стоит внимательно проанализировать основной интерфейс. Как сделать его понятнее без обучения? А если без обучения не обойтись, то как его организовать, чтобы оно не мешало пользоваться приложением? Может, где-то нужно добавить текстовые подсказки. Может, в сложных местах нужна кнопочка-вопросик, за которой прячется более подробное пояснение. А может, вообще нужен собственный обучающий канал на Ютюбе, на который ведут всякие ссылки из интерфейса.<\/p>\n
Рассказ об обновлении<\/h3>\n
Теперь рассмотрим онбординг с рассказом об обновлении.<\/p>\n
Здесь те же проблемы стоят ещё острее. Если при первом запуске у человека часто нет ожиданий, то вот давно установленное приложение человек запускает с конкретной целью: проверить трекинг доставки или оплатить коммуналку. Скорее всего, у него есть «план»: он помнит, в какой угол сейчас нажмёт, что там появится, куда именно он перейдёт дальше. И вдруг вместо привычного интерфейса он видит рассказ о новых фичах, который прямо сейчас ему совершенно не нужны!<\/p>\n
В такой ситуации желание просто пропустить этот экран ещё сильнее, а значит о новшествах многие пользователи просто не узнают. И снова, не потому что они им не нужны, а потому что они им не нужны в этот момент. Если ваше приложение живое и регулярно обновляется, то постоянные рассказы об обновлениях будут бесить, а привычка пропускать их будет закрепляться с каждым разом всё сильнее.<\/p>\n
Чтобы держать пользователей в курсе изменений, хорошо предусмотреть в приложении постоянное место для этого. Мой любимый пример — Телеграм:<\/p>\n
\n $\"\"$ \n<\/div>\n
Дизайнеры ловко воспользовались тем, что это мессенджер, и присылают пользователю рассказы об обновлениях сообщениями в одном из чатов. Когда заходишь в приложение, видишь эти сообщения наравне другими. Можешь сначала поболтать с людьми и почитать каналы, а уж потом и про сам Телеграм разузнать. О каждой фиче ещё и рассказывают отдельным сообщением с красивым видосом. Сообщение можно переслать кому-то, кому, на ваш взгляд, фича будет полезна — рекламный эффект бесплатно усиливается. И, конечно, никто не мешает вернуться к этим сообщениям в любое время позже. Собственно, я так и поступил, чтобы сделать эти скриншоты.<\/p>\n
Даже если у вас не мессенджер, можно найти какое-то постоянное место для рассказа о новых штуках. А чтобы люди не забывали туда зайти, можно зажигать красный кружочек, когда появляется непрочитанное. Самое главное, чтобы остальные функции приложения были доступны даже пока человек всё не прочитал.<\/p>\n
Хороший интерфейс и хороший бизнес<\/h3>\n
Мы начинаем курс пользовательского интерфейса<\/a> с темы человечности: интерфейс должен быть для человека, а не наоборот. Когда интерфейс стоит на пути и бесит, это плохой интерфейс. В лекции о привычках<\/a> я рассказываю о проблемах с окнами подтверждений и блокирующими сообщениями, частным случаем которых является онбординг. Они закрепляют привычку ничего не читать и со всем соглашаться.<\/p>\n
Однако как и окна подтверждения и несмотря на похожие проблемы, такие экраны-онбординги очень распространены. Дело в том, что в продуктовой разработке редко стоит задача «сделать пользователя довольным». Как правило, ответственные за продукт смотрят на другие метрики. Допустим, онбординг смотрят 10% людей и в результате продажи растут на 1%. Кого тогда волнует, что онбординг бесит и мешает остальным? Выигрыш оказался больше, чем проигрыш, ну и отлично.<\/p>\n
Как-то мне написал Егор, аналитик из Яндекса:<\/p>\n
\n
Считаешь ли ты, что а\/б-тест может точно ответить на этот вопрос? Половине новых пользователей мы показываем онбординг, половине не показываем, после этого смотрим на две метрики: конверсия первой сессии в заказ и время от запуска приложения до заказа. Если конверсия с онбордингом выше, а время до заказа не вырастает (то есть время, которое пользователь тратит на чтение онбординга, он отыгрывает потом), то согласился бы ты с тем, что онбординги имеют право на жизнь? И как ты вообще относишься к валидации продуктовых гипотез при помощи а\/б-тестов?<\/p>\n<\/blockquote>\n
Я и без теста соглашусь. Но этот тест в лучшем случае докажет, что лучше рассказать о приложении онбордингом, чем никак. А я говорю, что можно рассказать лучше, чем онбордингом.<\/p>\n
Валидация продуктовых гипотез — это не совсем про хороший интерфейс. Иногда можно ухудшить интерфейс, но поднять метрики: снизив информативность для принятия невыгодного человеку решения; запутав в вариантах; усложнив отписку. Хороший интерфейс иногда важен для успеха продукта, а иногда — нет, достаточно посмотреть на Фейсбук или Букинг.ком. Я бы не хотел иметь ничего общего с созданием этих очень успешных продуктов.<\/p>\n
В большом продукте с прагматичным менеджментом онбординг может быть действительно наиболее подходящим решением. Он никак не взаимодействует с остальным приложением, не добавляет никаких новых логических связей, его можно «просто поставить», за него даже может отвечать отдельная команда. Это намного проще, быстрее и дешевле, чем думать, как улучшить образовательные свойства самого продукта.<\/p>\n
Но не все бизнесы работают на выжимание метрик любой ценой. У некоторых другая система ценностей, где-то качество и удовольствие пользователей имеют значение. Иногда получается подумать, а не просто сделать как все.<\/p>\n
Я вижу, что часто онбординг делают вовсе не из прагматичных соображений, приведённых выше, а просто потому что искренне считают что это хорошая практика. Никто даже не смотрит вот эти метрики, не пытается сравнивать раздражение пользователей и выигрыш в конверсии — просто ставят заставку потому что прям ну очень хотят рассказать про новые фичи. И в таких случаях, когда я рассказываю о минусах, люди с удовольствием включаются в обсуждение альтернатив.<\/p>\n
Да, сделать хорошо обычно сложнее, чем сделать как придётся, но и эффект может оказаться больше.<\/p>\n
А можно ещё вопрос<\/h3>\n
— Илья, всё логично, но у нас появилась действительно крутая фича, над которой мы работали два года. Мы даже сняли видеоролик про неё! Мы хотим поставить его в онбординг, потому что нам важно, что его посмотрели все-все-все!<\/p>\n
Здорово, что вы сделали действительно крутую фичу, гордитесь ею и хотите всем рассказать! Если вы поставите её в онбординг, вы просрёте эту возможность. Как рассказать о фиче так, чтобы все были в восторге? Уделите этому вопросу хотя бы долю того внимания, которое вы уделили самой фиче.<\/p>\n", "date_published": "2023-08-22T15:33:54+05:00", "date_modified": "2023-09-06T13:34:57+05:00", "tags": [ "Онбординг", "пользовательский интерфейс", "привычка", "телеграм", "человечность" ], "author": { "name": "Илья Бирман", "url": "https:\/\/ilyabirman.ru\/meanwhile\/", "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764" }, "_date_published_rfc2822": "Tue, 22 Aug 2023 15:33:54 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "122516", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": null, "og_images": [] } } ], "_e2_version": 4079, "_e2_ua_string": "Aegea 11.0 (v4079e)" }