70% удаляют приложение после первого экрана. Как сделать онбординг который оставляет

Пользователь скачал приложение, открыл, посмотрел первый экран — и удалил. Не потому что продукт плохой. Потому что за первые 30 секунд он не понял, зачем это всё, что от него хотят и что он за это получит.

Онбординг — это не три экрана с иллюстрациями и кнопкой «Далее». Это первая сделка между продуктом и человеком: ты вкладываешь внимание, мы возвращаем ценность. Если сделка непонятна — её закрывают удалением иконки. И большинство команд проигрывают именно здесь, не на ретеншене, не на монетизации, а на самом первом касании.

Дальше — разбор того, как онбординг ломается, как он устроен, когда работает, и что конкретно проверять, прежде чем катить его в прод.

## Почему онбординг — это не «вступительные экраны»

Слово «онбординг» сильно дискредитировано. В голове у большинства это карусель из 3-4 слайдов: иллюстрация, заголовок, подзаголовок, «Далее». Иногда — обязательная регистрация в самом начале. Иногда — запрос пуш-уведомлений до того, как пользователь вообще что-то сделал.

На самом деле онбординг — это путь от установки до момента, когда пользователь получил первую ощутимую ценность. Этот путь может длиться 20 секунд, а может растягиваться на неделю — зависит от продукта. Но границы такие:

• Начало: первый запуск, ещё ничего не понятно.
• Конец: пользователь сделал то, ради чего скачивал, и понял, что это работает.

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

### Анти-паттерн: «расскажем про себя на старте»

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

В метриках это видно как огромный drop-off между экранами карусели — от 15 до 40% теряется буквально на свайпах.

## Сначала — момент ценности, потом всё остальное

Главный вопрос, на который должна отвечать команда перед проектированием онбординга: что такое «первая ценность» в нашем продукте и насколько быстро мы можем её отдать?

Это называют по-разному: aha-момент, time-to-value, first key action. Суть одна — момент, в который пользователь говорит себе «о, понятно, это работает, мне это надо».

Примеры из живых продуктов:

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

### Как найти свой момент ценности

На ревью продукта полезно прогнать команду через короткое упражнение:

1. Опишите одной фразой, зачем человек скачал ваш продукт.
2. Найдите минимальное действие, которое доказывает, что продукт это умеет.
3. Посчитайте, сколько шагов отделяет первый запуск от этого действия.
4. Уберите всё, что не обязательно на этом пути.

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

## Принцип «отложенных обязательств»

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

Базовое правило: сначала дай, потом проси.

### Чеклист «что можно отложить»

• Регистрация — можно ли пустить в продукт анонимно и попросить аккаунт позже, когда есть что терять?
• Email/телефон — нужен прямо сейчас или достаточно при первом сохранении?
• Пуш-уведомления — есть ли смысл просить до того, как пользователь понял, зачем они ему?
• Геолокация — реально нужна на старте или только при конкретном действии?
• Платные планы — показываем пейволл до или после первой ценности?
• Заполнение профиля — это блокер или можно постепенно?

### Вопросы для ревью онбординга

• На каком экране пользователь впервые получает что-то полезное?
• Сколько обязательных полей до этого момента?
• Что произойдёт, если убрать любой из промежуточных шагов — продукт сломается или нет?
• Какие запросы разрешений можно перенести в контекст («дайте доступ к камере, когда нажмёте на сканер»)?

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

## Как диагностировать свой онбординг за час

Когда команда говорит «у нас плохой онбординг», обычно никто не знает, где именно он плохой. Ощущение есть, цифр нет. Чтобы перейти от ощущений к решениям, достаточно одного дня и пары инструментов.

### Шаг 1. Нарисуйте реальный путь, а не задуманный

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

Почти всегда выясняется, что в макетах в Figma путь короче, чем в реальном приложении. Между этими двумя реальностями и живут половина проблем.

### Шаг 2. Снимите цифры по каждому шагу

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

На ревью часто всплывает один и тот же паттерн: один экран теряет в два раза больше остальных. Это и есть точка приложения усилий. Не переделывайте всю воронку — почините слабое звено.

### Шаг 3. Пройдите путь чужими руками

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

Что записывать:

• Где он остановился и перечитал.
• Где нажал не туда.
• Где задал вопрос вслух — это значит, экран не отвечает сам.
• Где попытался свайпнуть, а свайпа не было (или наоборот).

## Типичные ошибки, которые видно на макете

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

### Ошибка: «один экран — одна функция, без контекста»

Дизайнер собирает онбординг как набор отдельных экранов: приветствие, разрешения, регистрация, тур. Каждый экран сам по себе нормальный. Связи между ними — нет. Пользователь не понимает, зачем он на третьем шаге, если первый его ни к чему не подвёл.

Лечится сценарным просмотром: расставьте экраны в ряд и прочитайте их как историю. Если получается «нажми — нажми — нажми — нажми», истории нет.

### Ошибка: запрос разрешений без объяснения

Системный диалог iOS или Android — это не часть вашего интерфейса. Вы не контролируете его текст и кнопки. Если показать его сразу, без своего экрана-объяснения («зачем нам камера»), процент отказов вырастает заметно. На макете это часто пропускают — потому что системного диалога в Figma не видно.

### Ошибка: пейволл вместо ценности

Платный экран до того, как пользователь понял продукт — почти всегда плохая идея. Исключение — продукты, где платная функция и есть продукт (например, специализированные ИИ-инструменты). Во всех остальных случаях пейволл уместен после первого «вау».

### Ошибка: онбординг, который не возвращается

Часто всё внимание уходит на первый день. А на третий пользователь открывает приложение и не помнит, что делать. Хороший онбординг растянут: первая сессия даёт ценность, вторая — учит чему-то новому, третья — закрепляет привычку. Это называют growth loops или secondary onboarding, и в макетах об этом обычно забывают.

## Чеклист для ревью макета онбординга

• На каждом экране ясно, что произойдёт после нажатия кнопки.
• Везде, где есть системный диалог, перед ним стоит свой объясняющий экран.
• Между установкой и первой ценностью не больше 5-6 экранов.
• Каждый обязательный шаг можно объяснить пользователю одной фразой «зачем».
• У пользователя есть выход — можно пропустить, отложить, вернуться.
• Есть состояние «пользователь вернулся на второй день» — что он увидит?
• Регистрация стоит после первой ценности или, как минимум, есть гостевой режим.
• Пуш и геолокация запрашиваются в контексте, а не списком на старте.

## Как работать с этим в команде

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

Здесь работает простой приём: на встрече по онбордингу повесить на стену один вопрос — «когда пользователь поймёт, что наш продукт работает?» — и любой шаг до этого момента защищать отдельно. Не «давайте добавим», а «давайте докажем, что без этого нельзя».

Короткий итог: онбординг чинят не в Figma, а в голове команды. Сначала договариваются, что такое первая ценность, потом считают шаги до неё, потом убирают всё, что мешает, и только потом начинают рисовать. В обратном порядке получается красиво, но не работает.

## Продвинутые сценарии: онбординг не один

Как только команда соглашается, что онбординг — это путь к первой ценности, всплывает неприятная правда: путей несколько. Маркетолог, который пришёл из контекстной рекламы, и студент, который скачал по совету друга, — это разные люди с разными ожиданиями. Один универсальный флоу обслуживает их одинаково плохо.

### Сегментация на входе

Самый дешёвый способ сегментировать — спросить. Один экран с 3-5 вариантами «зачем вы здесь» решает половину задачи. Дальше пользователь видит онбординг, в котором первая ценность совпадает с его ответом.

Главное — не превращать этот экран в анкету. Если вопросов больше двух, человек считает, что его уже эксплуатируют. И уходит до того, как продукт что-то показал.

### Возврат и реактивация

Онбординг — это не только первая сессия. Если человек поставил приложение, прошёл три экрана и закрыл — у вас ещё есть пара дней, чтобы вернуть его. Здесь работают не пуши «мы соскучились», а пуш с конкретным следующим шагом из того места, где он остановился.

На макетах это почти всегда забывают. Покажите в Figma не только «первый запуск», но и сценарий «вернулся через 48 часов, не закончив онбординг». Что он увидит? Тот же экран? С нуля? С места остановки? Каждый ответ — отдельная гипотеза.

### B2B и сложные продукты

В B2B пользователь часто не сам решает, нужен ли ему продукт. Его выбрал руководитель, и онбординг для него — это не «вау», а «как поскорее закрыть и начать работать». Здесь работает не история, а скорость: минимум экранов, максимум возможности скипнуть, отдельный путь для администратора и для рядового члена команды.

## Где здесь AI и как им не сломать онбординг

Сейчас почти каждый второй онбординг включает что-то «умное» — генерацию контента, персонализированные рекомендации, ассистента. Это даёт новый класс ошибок.

### Риск: пустой AI на первом экране

Если ваш продукт — это AI-инструмент, у него почти всегда есть проблема холодного старта. Пользователь открывает приложение, видит поле ввода и… не знает, что туда написать. Хороший онбординг для AI-продукта — это не тур по интерфейсу, а 2-3 готовых примера, которые можно запустить в один тап и увидеть результат на своих данных.

### Риск: «волшебство» без объяснения

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

### Figma, MCP и генерация вариантов

Сейчас удобно подключать к Figma модели через MCP и просить сгенерировать варианты онбординга — другие тексты, другой порядок шагов, другой угол подачи. Это полезно как способ быстро размножить гипотезу, но опасно как способ принять решение. Модель не знает вашу первую ценность и легко собирает красивый, но пустой флоу.

Рабочая практика: использовать AI для расширения вариантов («дай мне 5 формулировок ценности под этот сегмент»), а выбор и сборку оставлять команде. И обязательно прогонять сгенерированные экраны через тот же чеклист, что и нарисованные руками.

## Как проверять качество онбординга

Онбординг сложно мерить «на глаз» — у каждого в команде своё ощущение. Поэтому полезно зафиксировать 3-4 числа, на которые смотрите регулярно.

• Доля дошедших до первой ценности (а не до конца тура).
• Время от установки до первой ценности.
• Доля вернувшихся на второй и седьмой день.
• Где именно отваливаются — на каком экране, не на каком шаге воронки в целом.

Если хотя бы одно из чисел двигается после изменений — гипотеза работала. Если все четыре стоят — вы перекрашивали кнопки.

### Вопросы для ревью перед релизом

• Можем ли мы сформулировать первую ценность одной фразой, на которую согласна вся команда?
• Сколько обязательных шагов между установкой и этой ценностью? Каждый защищён?
• Что увидит пользователь, который вернулся на второй день, не закончив?
• Где в флоу мы решаем за пользователя, и понятно ли ему это?
• Какой шаг мы уберём первым, если метрика просядет?

## Как объяснять решение команде

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

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

И ещё одно: фиксируйте решения письменно. Через три месяца придёт новый продакт и спросит, почему здесь нет email-капча на старте. Если ответа нет — он появится. И онбординг снова станет длиннее.

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

## Чеклист готовности онбординга

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

• Первая ценность сформулирована одной фразой, понятной не только команде продукта
• От установки до этой ценности — не больше трёх обязательных шагов
• Каждый обязательный шаг защищён аргументом «без него не работает», а не «так принято»
• Есть отдельный путь для админа и для рядового участника, если продукт командный
• Есть путь для возврата на второй день: пользователь не начинает заново
• Регистрация и оплата не стоят раньше момента, где видна польза
• Запросы разрешений (пуши, гео, контакты) привязаны к моменту, где они объяснимы
• Любой шаг тура можно скипнуть, и это не ломает дальнейший опыт
• Пустые состояния не выглядят как «здесь ничего нет», а подсказывают первое действие
• Если есть AI — на первом экране лежат готовые примеры, а не пустое поле
• Видно, какие данные пользователь отдал, и есть способ это откатить
• Заведены 3-4 метрики, на которые команда смотрит регулярно, и они подключены до релиза

## Анти-паттерны, которые встречаются чаще всего

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

### Тур по интерфейсу вместо первой ценности

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

### Анкета на 7 вопросов «чтобы лучше вас понять»

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

### Принудительная регистрация до того, как видна польза

«Введите email, чтобы продолжить» на втором экране — это просьба о доверии, которое ещё не заработано. Дайте сначала прожить мини-ценность, потом просите контакт. Конверсия в регистрацию после ценности всегда выше, чем до.

### Пуш-разрешение на первом запуске

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

### Прогресс-бар, который врёт

«Шаг 2 из 4» — а потом внезапно появляется ещё три экрана. Доверие к флоу падает мгновенно. Либо честно показывайте все шаги, либо не показывайте счётчик.

### Один путь для всех

Админ команды и приглашённый участник проходят одинаковые экраны. Админу не хватает контроля, участнику — лишние вопросы про настройку рабочего пространства, которое уже создано. Любая B2B-история разваливается на этом.

### Пустой экран после онбординга

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

## Вопросы для ревью с командой

Эти вопросы полезно задавать не дизайнеру, а всей группе: продакту, разработке, поддержке. Если ответы расходятся — это и есть результат ревью.

• Какую одну вещь должен унести пользователь из первого сеанса?
• Что произойдёт, если он закроет приложение на третьем экране и вернётся через неделю?
• Какой шаг мы добавили «на всякий случай», и кто за него отвечает?
• Где в флоу мы скрываем сложность, а где честно её показываем?
• По какой метрике мы поймём, что онбординг стал хуже, а не лучше?
• Что в этом флоу не переживёт смену продакта через полгода?

## Короткий практический итог

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

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