~/wiki / ux-i-interfeisy / ierarhiya-metrik-produkta-dlya-dizaynera

Иерархия метрик продукта: как связать UX-решения с бизнес-показателями

Основной чат

Чат для вайбкодеров: новости, гайды, поиск исполнителей, маркетплейс и разбор реальных кейсов.

$ cd раздел/ $ join vibe dev
Иерархия метрик продукта: как связать UX-решения с бизнес-показателями - обложка

Дизайнер переделал онбординг. Пользователи стали проходить его быстрее. Дизайнер доволен. Продакт смотрит на выручку — она не выросла. «Зачем вы вообще это делали?»

Это классический разрыв между UX-метриками и бизнес-метриками. Дизайнер оптимизировал одно, бизнес ожидал другого. Никто не виноват — просто не было общего языка.

Иерархия метрик — это и есть тот общий язык. Система, которая показывает: вот бизнес хочет X, вот X складывается из Y и Z, вот Y напрямую зависит от того, что делает дизайнер.


Зачем вообще нужна иерархия

Метрики без иерархии — это набор цифр. Каждый смотрит на своё: маркетинг на CAC, продакт на retention, дизайнер на task completion rate. Цифры не противоречат друг другу, но и не складываются в картину.

Иерархия отвечает на вопрос «почему эта метрика важна». Не просто «retention вырос на 3%» — а «retention вырос на 3%, значит через полгода выручка вырастет примерно на X, потому что вот эта связь».

Три вещи, которые даёт иерархия:

Приоритизация. Когда ясно, что на что влияет, легко решить, что делать сначала. Не по ощущениям, а по цепочке.

Обоснование решений. «Я хочу переделать форму регистрации» — слабо. «Форма регистрации — узкое место в воронке, которое режет conversion rate, а CR напрямую влияет на revenue» — сильно.

Обнаружение конфликтов. Иногда оптимизация одной метрики вредит другой. Иерархия помогает увидеть это заранее.


Три уровня метрик

Любой продукт можно описать через три уровня метрик. Называют их по-разному, но суть одна.

Уровень 1: Бизнес-метрики

Это то, что считает CFO и CEO. Деньги, рост, устойчивость бизнеса.

  • Revenue / MRR / ARR — выручка, помесячная и годовая
  • Profit margin — маржинальность
  • LTV (Lifetime Value) — сколько денег приносит один пользователь за всё время
  • CAC (Customer Acquisition Cost) — сколько стоит привлечь одного пользователя
  • LTV/CAC ratio — основной показатель здоровья бизнеса (нормой считается 3:1 и выше)
  • Churn rate — процент пользователей, которые уходят за период

На этом уровне дизайнер обычно не работает напрямую. Но именно здесь нужно понимать, что считается успехом.

Уровень 2: Продуктовые метрики

Это то, что измеряет продуктовая команда. Показатели поведения пользователей в продукте.

  • DAU / MAU — ежедневные и ежемесячные активные пользователи
  • Retention Rate — какой процент пользователей возвращается (D1, D7, D30)
  • Activation Rate — дошли ли пользователи до момента ценности
  • Engagement — глубина использования продукта
  • NPS (Net Promoter Score) — готовность рекомендовать
  • Feature adoption — используют ли конкретные фичи

Здесь дизайнер уже влияет напрямую — через UX, информационную архитектуру, онбординг.

Уровень 3: UX-метрики

Это то, что измеряет дизайнер. Показатели качества конкретного взаимодействия.

  • Task success rate — процент пользователей, успешно выполнивших задачу
  • Time on task — сколько времени уходит на выполнение
  • Error rate — как часто пользователи ошибаются
  • SUS (System Usability Scale) — субъективная оценка удобства
  • HEART-метрики — Happiness, Engagement, Adoption, Retention, Task Success
  • Conversion rate в воронке — процент перехода между шагами

Это метрики конкретных экранов, флоу, компонентов.


Как связать уровни: дерево метрик

Иерархия работает как дерево. Верхний уровень — бизнес-метрика. Она декомпозируется в продуктовые метрики. Те декомпозируются в UX-метрики.

Вот пример для SaaS-продукта:

plaintext
Revenue
├── Новые платящие пользователи
│   ├── Трафик на сайт
│   ├── Conversion rate (landing → регистрация)
│   │   ├── Task completion rate на форме регистрации
│   │   └── Error rate на шагах формы
│   └── Activation rate (регистрация → первое ценное действие)
│       ├── Time to value (как быстро пользователь дошёл до ценности)
│       └── Onboarding completion rate
└── Удержание существующих пользователей
    ├── D30 Retention
    │   ├── DAU/MAU ratio
    │   └── Feature adoption rate ключевых фич
    └── Expansion revenue (апгрейды)
        ├── Использование premium-фич
        └── Частота использования

Это не единственный возможный вид дерева — он будет разным для разных продуктов и бизнес-моделей. Но принцип один: каждая верхнеуровневая метрика объясняется через нижнеуровневые.

Как читать дерево

Сверху вниз: «Что влияет на revenue? → Новые пользователи и retention. Что влияет на Conversion rate? → Task completion на форме регистрации и error rate».

Снизу вверх: «Мы улучшили error rate на форме регистрации. Что это значит для бизнеса? → Выше conversion rate → больше новых платящих → выше revenue».

Второй путь — это то, как дизайнер обосновывает свою работу бизнесу.


Практика: как строить дерево для своего продукта

Шаг 1: Зафиксируй главную бизнес-метрику

Это North Star Metric или просто главный KPI, который важен бизнесу прямо сейчас. Не три метрики и не «ну, нам важно всё» — одна.

Примеры: Monthly Recurring Revenue, количество активных пользователей, объём транзакций.

Шаг 2: Разложи её на компоненты

Любую метрику можно математически разложить. Revenue = Количество пользователей × ARPU. DAU = Новые пользователи + Вернувшиеся − Ушедшие. Retention = 1 − Churn.

Это не гипотезы — это математические тождества. Используй их как каркас.

Шаг 3: Для каждого компонента найди продуктовый драйвер

«Что в продукте влияет на этот компонент?» Retention обычно зависит от engagement с ключевыми фичами, от качества онбординга, от того насколько быстро пользователь достигает ценности.

Шаг 4: Для каждого продуктового драйвера найди UX-метрику

«Как это измерить в интерфейсе?» Engagement с фичей → feature adoption rate, time spent in feature. Качество онбординга → onboarding completion rate, time to completion, drop-off points.

Шаг 5: Проверь связи

Связь между уровнями должна быть логически обоснована. «Если task completion rate на онбординге вырастет, activation rate тоже должен вырасти» — это гипотеза, которую можно проверить.


Распространённые ошибки при построении иерархии

Ошибка 1: Слишком много метрик на каждом уровне

Если на уровне UX-метрик у вас 40 показателей — это не иерархия, это таблица данных. На каждом уровне должно быть 3–7 ключевых метрик.

Ошибка 2: Связи «по ощущениям»

«Мы думаем, что это влияет на то» — не годится. Связи должны быть либо математически выведены, либо подтверждены данными. Гипотезы нужно явно помечать как гипотезы.

Ошибка 3: Статичное дерево

Продукт меняется, фокус бизнеса меняется — и дерево метрик должно меняться. Ревизия раз в квартал — минимум.

Ошибка 4: Ориентация на то, что легко измерить

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

Ошибка 5: Путаница метрик и целей

Метрика — это измерение. Цель — это желаемое значение метрики. «Retention» — метрика. «Retention D30 ≥ 40%» — цель. Не перепутай их в дереве.


Дизайнер и метрики: три модели взаимодействия

В разных командах дизайнер работает с метриками по-разному.

Модель 1: Дизайнер получает метрики сверху

Продакт ставит задачу с метрикой: «Нужно поднять conversion rate на онбординге с 60% до 75%». Дизайнер решает задачу.

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

Модель 2: Дизайнер участвует в выборе метрик

Команда вместе решает, что считать успехом для конкретного проекта. Дизайнер предлагает UX-метрики, которые связаны с продуктовыми целями.

Плюсы: дизайнер понимает задачу целиком, метрики осмысленные. Минусы: требует зрелости команды и доверия.

Модель 3: Дизайнер самостоятельно строит и предлагает метрики

Дизайнер приходит к продакту с готовой цепочкой: «Я предлагаю изменить форму, это должно поднять task completion rate, что связано с activation rate, который напрямую влияет на revenue».

Плюсы: максимальное влияние и ответственность. Минусы: нужно глубокое понимание бизнеса и данных.

Третья модель — это уровень senior/lead дизайнера. Именно для неё нужна иерархия метрик.


Как разные типы продуктов строят иерархию

E-commerce

plaintext
GMV (Gross Merchandise Value)
├── Количество заказов
│   ├── Conversion rate (сессия → заказ)
│   │   ├── Add to cart rate
│   │   ├── Cart abandonment rate
│   │   └── Checkout completion rate
│   └── Повторные заказы
│       └── Retention rate покупателей
└── Средний чек
    ├── Средний размер корзины
    └── Upsell/cross-sell rate

Дизайнер здесь работает прежде всего с воронкой — от карточки товара до подтверждения заказа. Ключевые метрики: add to cart rate, checkout completion rate, cart abandonment rate по шагам.

SaaS (подписка)

plaintext
MRR (Monthly Recurring Revenue)
├── Новые подписки
│   ├── Trial-to-paid conversion
│   │   ├── Activation rate (trial → aha moment)
│   │   └── Engagement во время trial
│   └── Количество trial-регистраций
└── Удержание подписок
    ├── Churn rate
    │   ├── Feature adoption (используют ли ключевые фичи)
    │   └── Engagement trend (растёт или падает)
    └── Expansion revenue (апгрейды)

Ключевая задача дизайна в SaaS — ускорить путь пользователя к «aha moment» и обеспечить постоянный engagement с фичами, за которые он платит.

Маркетплейс (двусторонний)

Маркетплейс сложнее — здесь две стороны и метрики нужны для каждой.

plaintext
GMV
├── Сторона спроса (покупатели/заказчики)
│   ├── Conversion rate (поиск → заказ)
│   ├── Retention покупателей
│   └── Средний чек
└── Сторона предложения (продавцы/исполнители)
    ├── Supply quality (рейтинги, отзывы)
    ├── Retention поставщиков
    └── Time to fill (скорость закрытия заказа)

Дизайнер маркетплейса работает с двумя разными пользователями с разными задачами и часто с разными интерфейсами.


Когда метрики лгут: ловушки для дизайнера

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

Ловушка «хорошая метрика, плохой продукт»

Task completion rate 95% на форме — отлично. Но пользователи заполняли её по 12 минут и ненавидели каждую секунду. SUS-оценка 42/100.

Метрики не противоречат, но картина разная. Нужно смотреть на несколько связанных метрик вместе.

Ловушка «корреляция вместо каузальности»

Внедрили новый дашборд — retention вырос. Кажется, связь есть. Но одновременно запустили email-кампанию и улучшили мобильное приложение. Что именно повлияло?

Без контролируемых экспериментов (A/B-тестов) невозможно установить причинно-следственную связь. Корреляция — это гипотеза, не факт.

Ловушка «ванильных метрик»

Некоторые метрики выглядят хорошо по определению. «Нас лайкнули 10 000 раз» — и что? Количество лайков само по себе не объясняет, помогает ли продукт пользователям достигать целей.

Ванильные метрики — те, которые сложно связать с бизнес-результатом. В иерархию они не попадают.

Ловушка «оптимизации локального оптимума»

Улучшили форму регистрации — conversion rate вырос с 40% до 55%. Победа? Нет, если activation rate упал с 70% до 50%, потому что в продукт пошли нецелевые пользователи.

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


Метрики и дизайн-решения: как строить аргументацию

Когда дизайнер приходит с предложением к продакту или бизнесу, структура аргумента должна идти по иерархии метрик.

Слабый аргумент: «Я хочу переделать страницу оплаты, потому что она выглядит устаревшей».

Сильный аргумент: «На шаге оплаты у нас 38% drop-off. Это снижает checkout completion rate до 62%, что режет конверсию всей воронки. По нашим расчётам, поднятие checkout completion до 75% даст +18% к количеству заказов в месяц. Я предлагаю переработать шаг оплаты, начиная с упрощения формы и добавления индикатора безопасности».

Разница — в том, что второй аргумент идёт по дереву метрик сверху вниз. Бизнес-эффект понятен, предложение конкретно.


Как начать прямо сейчас

Если у вас ещё нет иерархии метрик, начать можно за один рабочий день.

Утро: Соберите данные. Возьмите любой аналитический дашборд и выпишите все метрики, которые там есть. Не оценивайте — просто соберите.

Обед: Поговорите с продактом или CEO. Один вопрос: «Какая метрика для нас сейчас самая важная?» Это ваш верхний уровень.

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

Вечер: Пройдитесь по дереву вместе с командой. Где связи неочевидны — поставьте вопрос. Где чего-то не хватает — добавьте.

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


Чеклист: иерархия метрик готова, если…

  • Есть одна ключевая бизнес-метрика сверху
  • Каждый уровень имеет не больше 5–7 метрик
  • Связи между уровнями объяснены (математически или через данные)
  • Для каждой UX-метрики понятно, как её измерить
  • Дизайнер может объяснить любое своё решение через цепочку метрик
  • Дерево обновляется раз в квартал или при смене фокуса бизнеса
  • Гипотезы о связях явно помечены как гипотезы
  • Команда согласована по иерархии (не только дизайнер её знает)

Что дальше

Иерархия метрик — это фундамент. На нём строится всё остальное: выбор North Star Metric, построение дашборда, A/B-тесты, аргументация дизайн-решений.

Следующий шаг — научиться выбирать одну главную метрику из всего дерева и не терять из виду остальные. Это тема North Star Metric — о ней отдельная статья в этой серии.


Как метрики меняются при масштабировании продукта

Иерархия метрик не постоянна. По мере роста продукта и бизнеса фокус смещается — и дерево метрик должно меняться вместе с ним.

Стадия: Product-market fit (0→1)

На этой стадии главный вопрос — работает ли продукт вообще? Создаёт ли он ценность для пользователей?

Ключевые метрики стадии:

  • Retention первых пользователей (есть ли хоть кто-то, кто возвращается?)
  • NPS (рекомендуют ли они продукт?)
  • Качественная обратная связь

На этой стадии Revenue — плохая главная метрика. Даже с плохим UX можно продать первым клиентам на энтузиазме. Это не доказывает, что продукт работает.

UX-метрики на этой стадии: Task success rate на ключевых сценариях и время до первого ценного результата.

Стадия: Growth (1→N)

Продукт работает, нужно масштабировать.

Фокус смещается на:

  • Acquisition efficiency (CAC, conversion funnel)
  • Retention at scale (удерживаем ли мы разнородную аудиторию?)
  • Activation (успевают ли новые пользователи увидеть ценность?)

UX-метрики фокусируются на воронке привлечения и онбординге — там самые большие потери при масштабировании.

Стадия: Maturity

Продукт зрелый, рост замедляется.

Фокус на:

  • Expansion revenue (больше от существующих пользователей)
  • Efficiency (снижение CAC, снижение стоимости обслуживания)
  • Defense (удержание перед конкурентами)

UX-метрики смещаются в сторону engagement и depth-of-use: используют ли пользователи весь потенциал продукта, а не только базовые функции.


Метрики и приоритизация дизайн-задач

Иерархия метрик — это не только теория. Это рабочий инструмент для принятия решений о том что делать.

Как использовать иерархию для приоритизации бэклога

У тебя есть 15 задач в бэклоге. Как выбрать с чего начать?

Шаг 1. Для каждой задачи определи: какую метрику она должна улучшить?

Шаг 2. Найди эту метрику в дереве. На каком уровне она находится?

Шаг 3. Каков потенциал улучшения? Если эта метрика вырастет на 10% — что происходит выше по дереву?

Шаг 4. Оцени усилие. Большое влияние + маленькое усилие = начинай отсюда.

Пример приоритизации

Бэклог задач:

  • A: Переделать главную страницу (влияет на: first impression, нет чёткой метрики)
  • B: Упростить форму заявки (влияет на: conversion rate → revenue)
  • C: Добавить тёмную тему (влияет на: satisfaction, косвенно retention)
  • D: Исправить ошибки в мобильной форме оплаты (влияет на: checkout completion → revenue)
  • E: Улучшить онбординг шаг 3 (влияет на: activation rate → retention → revenue)

Приоритизация через иерархию метрик:

  1. D (критическая ошибка в оплате, прямое влияние на revenue)
  2. B (конверсия напрямую в revenue)
  3. E (activation rate → retention → долгосрочный revenue)
  4. C (retention через satisfaction, косвенное влияние)
  5. A (влияние неизмеримо без конкретной метрики)

Это не идеальный алгоритм — но это намного лучше приоритизации «по ощущениям».


Как рассказывать о метриках разным аудиториям

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

Для CEO

Говори в терминах денег и рисков. Не «retention вырос», а «retention вырос на 3%, это транслируется в +Х рублей выручки через 6 месяцев по нашим расчётам».

CEO думает: «Это важно? Сколько стоит? Когда окупится?»

Для продакта

Говори о продуктовых метриках и гипотезах. «Activation rate 38%, это ниже бенчмарка в 55%. Предполагаем что причина в шаге 3 онбординга — там 42% drop-off. Предлагаем тест нового флоу».

Продакт думает: «Что делаем, почему именно это, как измеряем результат?»

Для разработчика

Говори о конкретных задачах и их приоритете. «Error rate на форме оплаты — 12%, это критично. Пользователи не могут ввести CVV на мобайле. Это блокирует конверсию».

Разработчик думает: «Что конкретно нужно исправить и насколько это срочно?»

Для других дизайнеров

Говори о дизайн-решениях и их обосновании. «Мы убрали поле "Телефон" из формы. Task completion rate вырос с 67% до 84%. Конкретная проблема была в том что пользователи не понимали зачем телефон нужен при онлайн-регистрации».

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


ИИ и иерархия метрик: как Claude помогает построить дерево

Построить дерево метрик с нуля — задача на несколько часов: нужно понять бизнес-модель, выписать метрики, найти связи. ИИ сокращает это до 20–30 минут.

Вот как это работает на практике.

Промпт: построить первое дерево метрик

plaintext
Я продуктовый дизайнер в [тип продукта: SaaS / e-commerce / маркетплейс / мобильное приложение].

Наша бизнес-модель: [например, подписка $29/мес, freemium с конверсией в платный план]
Главная бизнес-метрика: [например, MRR или количество активных подписчиков]

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

Покажи дерево в виде структуры с отступами. Для каждой UX-метрики укажи: как именно её измерить (инструмент или способ).

Claude вернёт дерево под вашу конкретную бизнес-модель — не абстрактный шаблон.

Промпт: найти слабые места в текущем дереве

plaintext
Вот наше текущее дерево метрик:
[вставь дерево]

Найди в нём:
1. Метрики без чёткой связи с бизнес-результатом
2. Уровни с пробелами (что-то важное не измеряется)
3. Метрики, которые легко «нагеймингуются» (хорошо растут без реального улучшения продукта)

Предложи конкретные исправления.

Промпт: перевести дизайн-задачу на язык метрик

Часто дизайнер знает, что хочет сделать, но не знает, как обосновать бизнесу.

plaintext
Я хочу переделать [конкретный экран или флоу].

Помоги мне выстроить аргументацию через метрики:
1. Какую UX-метрику это должно улучшить?
2. Как эта UX-метрика связана с продуктовыми KPI?
3. Как продуктовые KPI связаны с бизнес-метриками?
4. Предложи формулировку для разговора с CEO или CPO.

Контекст продукта: [кратко опиши]

Как использовать ИИ для регулярной ревизии дерева

Раз в квартал задай Claude:

plaintext
У нас изменился фокус: [например, раньше были в стадии роста, теперь переходим к монетизации / запускаем B2B-продажи / выходим на новый рынок].

Вот текущее дерево метрик:
[вставь дерево]

Какие метрики нужно добавить, убрать или поменять в приоритете под новый фокус? Объясни логику каждого изменения.

Это занимает 10 минут вместо воркшопа на полдня.

$ cd ../ ← назад к UX и интерфейсы