«Улучшили UX» не значит «улучшаем продукт»: без связки сигналов и метрик вы просто полируете интерфейс.

Типичный сценарий: сделали меньше кликов, поправили форму, ускорили экран. В демо красиво, в отзывах тише. А в продуктовых метриках то ноль, то минус, то “плавает”. Самообман начинается там, где UX-сигналы меряют отдельно, а бизнес-эффект ожидают “по ощущениям”.

Почему так ломается: UX-изменение почти всегда влияет на один участок сценария, а продуктовые метрики зависят от всей цепочки. Плюс меняется состав трафика, люди идут другим маршрутом, часть ошибок становится “невидимой” (например, пользователь бросил попытку раньше, чем вы логируете ошибку). Если вы не построили причинную дорожку от действия к результату, метрика будет молчать или врать.

Минимальный стандарт, чтобы эффект был измеряемым:

  1. Сначала фиксируйте UX-сигнал как наблюдаемое событие, а не как “время на экране”. Нужно минимум: старт попытки, шаги, успех сценария, тип ошибки, отмена, повторная попытка. Время и лаги считаются только когда есть эти точки.

  2. Опишите связку “сигнал → продуктовая метрика” в одном предложении. Например: меньше ошибок в оплате должно увеличить долю успешных оплат, а не “улучшить конверсию” вообще. Один UX-объект — один ближайший продуктовый результат.

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

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

  5. Проверьте измерение до эксперимента. Логи событий стабильны, определения совпадают, “успех” не меняет смысл между версиями, нет систематических пропусков. Иначе A/B тестирует не UX, а телеметрию.

В правильной практике UX-сигналы живут рядом с продуктовыми метриками: вы видите, где именно стало лучше, и куда это (не) дошло по воронке. Обычно спорят про “время в интерфейсе”, но почти всегда важнее доля успешных завершений сценария и цена ошибок. Граница применимости простая: если изменение не трогает ключевой сценарий, не требуйте от него заметного сдвига в выручке или ретеншене.