Я не называю каталог функций картой продукта: сначала ищу момент, когда клиент остаётся один

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

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

Функция и рабочий путь — разные вещи

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

Поэтому я начинаю не с инвентаризации модулей. Я беру один момент, который клиент повторяет регулярно, и проговариваю его человеческим языком: «утром руководитель открывает систему, видит отклонение и понимает, кому задать вопрос». Или: «новый сотрудник получает доступ, делает первый обязательный шаг и не просит коллегу показать всё по видеосвязи».

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

Где клиент остаётся один

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

Я бы посмотрел как минимум на пять таких точек.

• Первое необратимое действие. Отправка счёта, публикация документа, изменение тарифа, передача заказа. Человек должен понимать последствия и иметь возможность проверить ввод.
• Ожидание между шагами. Если задача ушла на согласование, не надо заставлять пользователя гадать, увидел ли её кто-то и когда вернётся ответ.
• Исключение. У товара нет цены, контрагент дублируется, лимит исчерпан. Хороший продукт не делает вид, что исключений не бывает.
• Возврат после паузы. Вчерашний черновик, незавершённое согласование и непонятный статус не должны превращать человека в археолога собственной работы.
• Смена роли. Когда задачу берёт коллега, новый человек должен увидеть контекст, а не только пустую карточку и чужой комментарий «разберись».

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

Не путать помощь с навязчивостью

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

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

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

Нельзя собрать путь только на встрече

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

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

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

Как я проверяю карту пути перед релизом

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

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

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

Что не нужно обещать клиенту

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

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

Метрика не заменяет разговор с клиентом

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

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

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

У пути должен быть хозяин

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

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

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

Что меняется в разговоре о развитии

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

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

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

Короткий список перед тем, как считать функцию готовой

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

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