Я смотрю на первые десять минут пользователя раньше, чем на список функций
Я не считаю первые десять минут пользователя мелочью. В этот момент человек не изучает продукт «на будущее». Он пытается понять: получится ли у меня сделать свою работу без чужой помощи или я опять попал в длинную инструкцию.
У нового сервиса есть очень короткий кредит доверия. Пользователь пришёл не любоваться настройками. Он хочет отправить счёт, собрать заявку, увидеть остатки, согласовать документ — то есть закончить конкретное дело. Если продукт заставляет сначала заполнить двадцать полей, выбрать тариф, посмотреть экскурсию и только потом попробовать главное действие, доверие кончается раньше, чем начинается работа.
Первый шаг — не знакомство с интерфейсом
В продуктовой работе я сначала ищу первый полезный результат. Не первый экран и не первую кнопку, а момент, когда у человека появляется что-то сделанное: созданная задача, понятный отчёт, отправленный заказ, сохранённый клиент.
Это похоже на ключ от новой квартиры. Человеку важно не рассмотреть металл и не выслушать историю замка. Важно открыть дверь. Всё остальное можно объяснить потом.
Из-за этого хороший старт часто выглядит проще, чем его пытаются сделать. Вместо общего тура по разделам — один сценарий. Вместо пустого рабочего стола — безопасный пример. Вместо вопроса «настройте всё» — вопрос «что вы хотите сделать сейчас?».
Это не значит, что сложный продукт нужно притворно упростить. В учёте, производстве или B2B-сервисе по-настоящему важны права, справочники и правила. Но их стоит вводить тогда, когда пользователь уже видит, зачем они нужны. Иначе настройки воспринимаются как плата за вход, а не как инструмент.
Я проверяю не клики, а остановки
Иногда команда говорит: «Онбординг есть, пользователь прошёл пять шагов». Для меня это ещё ничего не доказывает. Человек может честно нажать «далее» и закрыть вкладку. Гораздо полезнее увидеть, где он остановился и что пытался сделать перед этим.
Обычно я разбираю три точки:
- какое дело привело человека в продукт;
- какой минимум данных ему нужен для первого результата;
- в какой момент он вынужден спросить коллегу или поддержку.
Последняя точка особенно важна. Вопросы к поддержке не всегда означают плохой продукт. Но если пять разных людей спрашивают, где начать работу, это уже не задача поддержки. Это сигнал, что продукт не объяснил своё первое действие.
В статье о готовности продукта к обычному рабочему дню я писал о проверке реального сценария вместо красивой демонстрации. Первые десять минут проверяются так же: не на встрече с командой, а в спокойной попытке нового человека решить свою задачу.
Пустой экран — это тоже ответ
Пустые разделы часто кажутся аккуратными: нет лишнего шума, всё ждёт данных клиента. Но для нового пользователя пустой экран отвечает довольно жёстко: «теперь сам догадайся, что здесь должно появиться».
Я предпочитаю давать человеку опору. Это может быть один демонстрационный заказ, шаблон процесса, подсказка рядом с первым действием или короткая фраза о том, что появится после нажатия. Главное — не превратить подсказку в экскурсовода, который не отстаёт.
Хорошая проверка простая: можно ли убрать подсказку после первого результата? Если да, она помогла. Если без неё нельзя работать дальше, значит, она закрывает дыру в самом сценарии.
Не все пользователи начинают одинаково
У собственника, оператора и администратора может быть один продукт, но первые полезные действия разные. Собственник хочет увидеть картину и решить, стоит ли включать команду. Оператору нужно провести конкретную операцию. Администратор настраивает правила, без которых другие не смогут работать.
Поэтому один универсальный старт нередко получается удобным только для команды, которая его проектировала. Я не пытаюсь сделать три разных продукта. Достаточно честно выбрать роль в начале или дать вход из контекста: приглашение в проект, ссылка на задачу, импорт первого списка.
Это продолжение мысли о том, что настройка полезна, только когда делает правило понятнее. Роль пользователя — тоже правило. Если она спрятана, продукт начинает спрашивать одно и то же у всех.
Что не стоит показывать в начале
Есть вещи, которые команда любит показывать слишком рано: длинный список возможностей, редкие интеграции, сложные права, все варианты экспорта. Они важны, но не помогают человеку сделать первый шаг. Более того, они создают ощущение, что перед ним слишком большой выбор и ошибиться легко.
Я обычно задаю к каждому элементу один неприятный вопрос: если убрать его с первого экрана, помешает ли это получить первый полезный результат? Если нет, элемент можно отложить. Это не прятки и не манипуляция. Это порядок, в котором новый человек получает знания: сначала контекст, потом действие, затем более тонкая настройка.
Полезно отличать обучение от проверки. Например, просьба пригласить коллегу на второй минуте часто нужна не пользователю, а продуктовой команде: так хочется быстрее увидеть рост. Но пока человек сам не понял ценность, приглашение будет выглядеть как лишняя обязанность. То же относится к обязательному заполнению профиля, выбору всех уведомлений и просмотру видеоинструкции.
Как заметить проблему без сложной аналитики
Не обязательно сразу строить воронку из десятков событий. Можно неделю смотреть на несколько простых признаков: сколько новых пользователей дошли до первого результата, сколько вернулись на следующий рабочий день, какие вопросы повторяются в поддержке. Важно смотреть на сочетание, а не на одну красивую цифру.
Если люди быстро создают первый объект, но не возвращаются, возможно, результат не встроен в их регулярную работу. Если не создают вообще, нужно разбирать начало сценария. Если создают только с помощью менеджера, продукту не хватает ясности. Эти выводы не заменяют исследования, зато подсказывают, где именно его проводить.
Такой разбор близок к проверке спроса: не стоит объявлять функцию удачной только потому, что её включили. Полезнее увидеть, изменила ли она привычный день пользователя. Именно этим отличается активный продукт от витрины возможностей.
С чего я бы начал проверку
Не с редизайна и не с новой серии подсказок. Я бы взял пять недавних пользователей и для каждого восстановил путь от первого входа до первого результата. Без оценок «нравится — не нравится». Только факты: что хотел сделать, что увидел, где свернул, кого позвал.
Дальше полезно выписать три вещи:
- одно действие, которое даёт человеку реальную пользу раньше всего;
- данные, без которых это действие невозможно;
- всё, что можно отложить до момента после результата.
Так часто выясняется, что продукту не нужен большой проект «по улучшению онбординга». Нужна одна другая последовательность: сначала дело, потом пояснение, затем настройка.
Приоритизация здесь важнее количества идей. В разборе дорогих исключений в SaaS я говорил о цене редких, но болезненных случаев. В старте продукта цена другая: если человек не получил первый результат, неважно, насколько хороши функции, которые он так и не открыл.
Вывод
Первые десять минут не должны рассказывать о продукте всё. Они должны дать человеку повод вернуться завтра. Для этого достаточно провести его к одному понятному результату, не потребовать лишних решений и не оставить одного перед пустым экраном.
Когда этот момент собран честно, дальнейшее обучение становится спокойнее. Пользователь уже не пытается понять, зачем ему сервис. Он разбирается, как получить от него больше.
Обсудим?