Я считаю первый самостоятельный результат главным экраном B2B-продукта

У B2B-продукта почти всегда есть экран, который команда любит показывать на демо. Он аккуратный, быстрый и понятный тем, кто его собирал. Но я не считаю его главным, пока человек не получил в системе первый самостоятельный результат.

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

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

Почему список функций не отвечает на главный вопрос

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

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

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

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

Первый результат — не обязательно первый экран

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

В B2B-системе у разных ролей разные первые минуты. Бухгалтеру нужно сверить сумму. Менеджеру — не потерять клиента. Руководителю участка — увидеть, что смена может начать работу. Один общий «welcome-экран» редко помогает всем одинаково.

Я раскладываю старт не по страницам, а по трём вопросам:

• с каким реальным поводом человек открывает систему;
• какое решение он должен принять без помощи коллеги;
• какой видимый след останется после этого решения.

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

Проверка в реальной, а не идеальной ситуации

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

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

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

Как не спутать самостоятельность с одиночеством

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

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

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

Какие сигналы смотреть после выпуска

После релиза я бы не ограничивался числом входов или кликов. Эти цифры говорят, что экран открыли, но не объясняют, удалось ли человеку сделать дело.

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

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

С чего начать, если продукт уже большой

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

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

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

Что обычно мешает первому самостоятельному шагу

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

Вторая — скрытый язык команды. Внутри проекта слова «контрагент», «единица учёта» и «операционный контур» могут быть привычными. Человек из продаж может искать «клиента», а кладовщик — «позицию на складе». Термин не нужно упрощать любой ценой, но его смысл надо раскрыть там, где он влияет на действие.

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

Небольшой чек-лист перед выпуском

Перед тем как считать сценарий готовым, я бы проверил пять вещей:

1. Понятен ли повод открыть систему без отдельной инструкции?
2. Можно ли выполнить одно полезное действие за разумное число шагов?
3. Видно ли, что результат сохранился и что будет дальше?
4. Не требуется ли для этого помнить внутренние правила команды?
5. Можно ли корректно остановиться или передать дело, если чего-то не хватает?

Если хотя бы на два вопроса ответ «нет», я бы не добавлял ещё один обучающий ролик. Сначала стоит вернуть в продукт недостающее правило, контекст или обратную связь.

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

Для меня хороший B2B-продукт начинается с момента, когда пользователь закрывает задачу и не ищет, кому написать: «А что теперь?»