Я не считаю клики доказательством ценности новой функции

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

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

Почему клики легко обманывают команду

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

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

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

Начинать стоит с одного рабочего решения

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

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

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

Что смотреть вместо одного числа

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

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

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

Сначала наблюдение, потом масштабирование

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

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

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

Вопрос, который отрезвляет

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

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

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

Как не подменить пользу удобным отчётом

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

Я бы не противопоставлял цифры и разговоры с пользователями. У них разные роли. Цифры помогают увидеть масштаб и изменения во времени. Наблюдение объясняет, почему они появились. Если после релиза количество действий выросло, стоит посмотреть несколько конкретных путей: люди нашли новый удобный сценарий или им пришлось делать лишний шаг? Если ошибок стало меньше, нужно убедиться, что их не стали просто позже замечать.

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

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

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

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

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