Метрики UX: что измерять, как связать с продуктовыми показателями

Сцена, знакомая почти каждому. Команда три недели переделывала форму заявки: убрала два поля, переписала подписи, развела шаги. Релиз. Через неделю продакт открывает дашборд: конверсия из «открыл форму» в «оплатил» — 11,4 % против 11,2 % до релиза. Разница в пределах шума. Кто-то произносит «ну, значит, редизайн ничего не дал», и три недели работы уходят в категорию «переставили пиксели».

Дальше происходит одно из двух. Либо дизайнер защищается словами про «удобство» и «современный вид» — и проигрывает, потому что против цифры словами не спорят. Либо команда решает больше не трогать форму: «мы пробовали, не работает». Обе реакции — следствие одной ошибки: измерили не то и не на том уровне. Форма из примера — второй шаг из пяти, и на конечную конверсию влияет цена, доставка, способ оплаты и то, что половина трафика пришла с промо-рассылки. Изменение на своём шаге вполне могло быть заметным: доля дошедших до конца формы выросла с 61 % до 79 %, медианное время заполнения упало вдвое, обращения в поддержку с темой «не принимает ИНН» исчезли. Просто эти числа никто не собирал, потому что план измерения не написали до релиза.

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

Зачем дизайнеру метрики

Метрика решает три задачи и ни одной больше.

Обнаружение. Где-то ломается, но жалуется меньшинство, а уходит молча большинство: без метрик вы узнаёте о проблеме через полгода из отчёта поддержки или не узнаёте вовсе. Локализация. Проблема известна («заявки падают»), место — нет; разбивка по шагам, полям и сегментам сужает «где-то в оформлении» до «поле ИНН, десктоп, самозанятые». Проверка. Мы изменили макет: стало лучше или мы просто привыкли к своей версии? Метрика — единственная защита от эффекта авторства.

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

И сразу главный риск. Закон Гудхарта в формулировке Мэрилин Стрэтерн: «Когда мера становится целью, она перестаёт быть хорошей мерой». Поставьте команде цель «снизить время на задачу» — появится соблазн убрать подтверждение удаления. Время упадёт, число случайных удалений вырастет. Поэтому у каждой целевой метрики есть контрметрика (guardrail), ловящая побочный ущерб. Без пары «цель + ограничитель» метрика опасна.

Ландшафт: что вообще можно измерить

Две оси. Первая: измеряем поведение (что человек сделал) или отношение (что сказал). Вторая: в лаборатории (мало людей, много контекста, задачи задаём мы) или в поле (много людей, контекста нет, задачи их собственные).

Вывод из картинки: ни один квадрант не самодостаточен. Аналитика покажет, что 41 % бросают шаг, но не скажет почему; тест на восьми людях объяснит почему, но не скажет, это 41 % или 4 %.

Отдельно про NPS, вокруг которого спорят регулярно: вопрос «насколько вероятно, что вы порекомендуете нас другу» устойчиво коррелирует с чем угодно на больших выборках и почти бесполезен для правки макета: он не привязан ни к задаче, ни к экрану, ни к моменту. Джаред Спул разобрал проблемы метрики в тексте «Net Promoter Score Considered Harmful». Разумная позиция: пусть NPS живёт как трендовый показатель для менеджмента, а дизайнерские решения принимайте по задачным метрикам.

Лестница метрик: от клика до денег

Частая ошибка — защищать макет бизнес-метрикой напрямую («мы улучшили карточку, значит вырастет выручка»). Между кнопкой и выручкой четыре уровня, и на каждом растёт шум.

• Уровень 1 — сигналы. «Нажал», «промахнулся», «увидел ошибку в поле», «вернулся назад». Реагируют мгновенно, шума мало, но и смысла мало: рост кликов сам по себе ничего не значит.
• Уровень 2 — задачные метрики. Человек сделал то, зачем пришёл: заявка отправлена, отчёт выгружен. Это и есть UX в измеримом виде; влияние дизайна прямое.
• Уровень 3 — продуктовые показатели. Конверсия воронки, возвраты, обращения в поддержку, время до первой ценности. Здесь дизайн соседствует с маркетингом, ценой и качеством данных.
• Уровень 4 — бизнес. Выручка, LTV, отток. Влияние есть, атрибуция слабая: за квартал произошло ещё пятнадцать вещей.

Правило, экономящее нервы: обещайте уровень 2, показывайте уровень 3, не берите уровень 4 в одиночку. «Ожидаем рост доли завершённых заявок с 61 % до 75 %, что при текущем трафике даёт примерно +340 заявок в месяц» — проверяемо. «Редизайн увеличит выручку на 10 %» — лотерея, в которой вы проиграете даже с хорошим макетом.

Дерево метрик: как связать кнопку с выручкой

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

Дерево полезно тремя свойствами.

Оно вскрывает арифметику. Сквозная конверсия — произведение шагов: $0{,}92 \cdot 0{,}61 \cdot 0{,}88 \cdot 0{,}74 \approx 0{,}366$. Поднять второй шаг с 0,61 до 0,75 — это сквозная 0,45, то есть +23 % заявок при том же трафике. Расчёт делается за пять минут и превращает «мне кажется, форма плохая» в «вот сколько стоит форма».

Оно показывает потолок. Третий шаг уже 88 % — там максимум +5 п. п., и то с боем. Спринт, потраченный на шаг с потолком в 5 % вместо шага с провалом в 39 %, — ошибка приоритизации, а не вкуса. И оно защищает от подмены: когда продакт говорит «нам нужна выручка», дерево отвечает — выручка = трафик × конверсия × чек, дизайн живёт в конверсии шагов, вот наши узлы. Дерево строят один раз на продукт и уточняют по мере появления данных; узлы должны совпадать с шагами из пользовательских потоков — иначе потом не сойдётся.

HEART: рамка, чтобы не забыть половину

Модель предложили в Google (Rodden, Hutchinson, Fu, CHI 2010, статья).

Ценность HEART не в буквах, а в приложенном процессе Goals → Signals → Metrics: сначала цель словами, затем наблюдаемый сигнал, и только потом метрика с формулой и знаменателем. Пример — функция «массовая загрузка накладных» в бухгалтерском сервисе.

Последняя строка важнее остальных. Не нужно заполнять все пять букв. Для бухгалтерского инструмента «вовлечённость» — вредная цель: чем меньше времени человек проводит в импорте, тем лучше. Engagement осмыслен там, где время внутри = ценность (медиа, обучение), и вреден для инструментов. Нет метрики — пишите «не применимо» и объясняйте почему. Второй нюанс — знаменатель: «доля успешных загрузок» может считаться от загрузок, сессий, аккаунтов или попыток, и это четыре разные метрики с разным поведением. Знаменатель фиксируется письменно, иначе через квартал два человека принесут два числа и будут оба правы.

Задачные метрики: успех, время, ошибки, усилие

Центральный слой для дизайнера; набор идёт из ISO 9241-11 — результативность, эффективность, удовлетворённость.

Доля успешных задач

Самая простая и самая информативная метрика: успешные попытки, делённые на все попытки. Тонкости: что считать успехом, решается до замера и записывается («нашёл тариф» — это «открыл страницу» или «назвал цену вслух»?); бинарно проще и защищено от вкусовщины, уровнями (полный успех / с трудом / провал) информативнее, но требует письменного критерия; успех с подсказкой модератора — это провал.

На маленькой выборке голая доля обманчива: 4 из 5 — это не «80 %». Нужен доверительный интервал; для малых выборок работает скорректированный интервал Уолда (Agresti–Coull) — к успехам прибавляем 2, к попыткам 4.

$$\hat p = \frac{x + 2}{n + 4}, \qquad \hat p \pm z \cdot \sqrt{\frac{\hat p \left( 1 - \hat p \right)}{n + 4}}$$

"""Доля успешных задач с доверительным интервалом (Agresti-Coull)."""
import math

def success_rate_ci(successes: int, trials: int, conf: float = 0.95) -> tuple[float, float, float]:
    z = {0.90: 1.645, 0.95: 1.960, 0.99: 2.576}[conf]   # без scipy ради трёх чисел
    p = (successes + 2) / (trials + 4)                  # скорректированная оценка
    half = z * math.sqrt(p * (1 - p) / (trials + 4))
    return p, max(0.0, p - half), min(1.0, p + half)    # оценка и границы в долях

for s, n in [(4, 5), (16, 20), (160, 200), (1600, 2000)]:
    p, lo, hi = success_rate_ci(s, n)
    print(f"{s}/{n}: оценка {p:.0%}, интервал {lo:.0%}..{hi:.0%}, ширина {hi - lo:.0%}")

4/5:        оценка 67%, интервал 36%..97%, ширина 62%
16/20:      оценка 75%, интервал 58%..92%, ширина 35%
160/200:    оценка 79%, интервал 74%..85%, ширина 11%
1600/2000:  оценка 80%, интервал 78%..82%, ширина 4%

Смотрите на первую строку: «4 из 5 справились» означает «где-то между третью и почти всеми». Отсюда правило: пять человек — отличная выборка, чтобы найти проблемы, и негодная, чтобы назвать число. Рекомендация Нильсена «тестируйте на пяти пользователях» — про поиск проблем, а не про измерение. Для интервала ± 10 п. п. нужно 20–40 человек, для ± 5 п. п. — сотни; ориентиры собраны у MeasuringU.

Время на задачу

Считать надо медиану или геометрическое среднее, а не арифметическое: распределение времени скошено вправо, и один человек, отошедший за кофе, утащит среднее на 40 %.

$$\bar t_g = \left( \prod_{i=1}^{n} t_i \right)^{1/n} = \exp\left( \frac{1}{n} \sum_{i=1}^{n} \ln t_i \right)$$

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

Ошибки

Считайте не только «ошибки системы», но и ошибки пользователя по типам: промахи (slips — намерение верное, действие сорвалось: нажал не туда, ввёл в соседнее поле) лечатся размерами, отступами и порядком (см. доступность на этапе дизайна); заблуждения (mistakes — человек не понял, что делает) лечатся текстом, структурой и обратной связью. Разделение важно, потому что решения разные. Метрика «число ошибок валидации на успешную отправку» тонко ловит качество формы: она растёт задолго до того, как просядет конверсия.

Субъективные шкалы

SEQ (Single Ease Question) — «насколько сложным или простым было выполнение задачи», 7 баллов, сразу после задачи. Дёшево, чувствительно, отлично работает в паре с успехом; средний ориентир по индустрии — около 5,5 из 7 (MeasuringU). SUS (System Usability Scale), John Brooke, 1986 — 10 утверждений с чередованием полярности:

$$S = 2{,}5 \cdot \left( \sum_{i \in \text{нечётные}} (x_i - 1) + \sum_{i \in \text{чётные}} (5 - x_i) \right)$$

Результат от 0 до 100, но это не проценты. Среднее по сотням исследований — около 68, значение 80+ считается хорошим (разбор). Ценность SUS — в сопоставимости: своя версия против прошлой, своя против конкурента. UMUX-Lite — два вопроса вместо десяти, хорошо коррелирует с SUS и удобно встраивается прямо в продукт.

Когда какую: SEQ — после каждой задачи в тесте; SUS или UMUX-Lite — после сессии либо раз в квартал по продукту; CSAT — точечно после конкретного взаимодействия.

Продуктовые метрики, которые зависят от дизайна

Не все продуктовые числа реагируют на макет. Реагируют эти:

• конверсия шага, а не воронки целиком. Дизайнер отвечает за переходы между экранами, которые нарисовал; конверсия из показа рекламы в покупку — не его зона;
• доля повторных операций — человек переоформляет, редактирует сразу после создания, отменяет и создаёт заново. Почти всегда след непонятного интерфейса;
• обращения в поддержку с UX-тегами — самая недооценённая метрика и прямая денежная оценка непонятности: 400 обращений в месяц по теме «не проходит ИНН» при стоимости обращения 300 руб. — это 120 000 руб. в месяц, то есть уже разговор на языке бюджета;
• время до первой ценности (TTFV) — от регистрации до первого настоящего результата; хорошо реагирует на онбординг и пустые экраны (см. взаимодействие и состояния);
• возвраты к задаче — не «DAU», а доля вернувшихся к этой задаче в следующем периоде: инструментальные продукты живут возвратами, а не временем на сайте;
• сигналы боли из записей сессий: rage clicks (три и более быстрых клика в точку — неактивная кнопка без объяснения, отсутствие отклика), dead clicks (заголовок выглядит как ссылка, картинка как кнопка), U-turn (зашёл и сразу вышел — плохое имя в навигации, см. информационную архитектуру), поиск по странице через Ctrl+F сразу после загрузки, скролл вверх-вниз без кликов;
• производительность: LCP, INP и CLS — это UX-метрики, просто их обычно ведёт фронтенд. Скачок макета при загрузке — промах мимо кнопки, а не «технический показатель»: веб-производительность и Web Vitals дают удобный общий язык с разработкой.

Разбор 1: «пользователь не нашёл кнопку»

Жалоба поддержки: «люди не могут выгрузить отчёт». Кнопка на месте, всё работает.

Как это выглядит в данных: страница отчёта открывается 12 000 раз в месяц, событие report_export_click — 900 раз. Внутренний поиск по слову «выгруз» — 1 400 запросов, 62 % из них с этой же страницы. Глубина скролла: 84 % не доходят до низа, а кнопка живёт под таблицей. Rage clicks — на заголовке колонки «Экспорт формата», который выглядит как кнопка.

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

Разбор 2: форма, которая теряет треть

Ради таких случаев и вводят пофайловую аналитику. Что снимать по каждому полю: достигли (фокус впервые попал в поле), заполнили (поле покинуто непустым), ошибка валидации (сколько раз и какая именно), время в поле (медиана от фокуса до ухода), возвраты в поле, отказ (сессия закончилась здесь). События ставятся на focus, blur, на показ ошибки и на отправку. Важно: текст ошибки — это свойство события; без кода ошибки вы знаете, что ошибка была, но не знаете какая, а формулировки — половина проблемы (см. текст в интерфейсе).

-- Пофайловая диагностика формы: доходимость, ошибки, медианное время в поле
WITH f AS (
    SELECT session_id, ts, event_name,
           properties ->> 'field'      AS field,
           properties ->> 'error_code' AS error_code
    FROM events
    WHERE event_name IN ('form_field_focus', 'form_field_blur', 'form_field_error')
      AND properties ->> 'form_id' = 'lead_step2'
      AND ts >= now() - INTERVAL '28 days'
),
spans AS (   -- время от фокуса до ближайшего blur в той же сессии
    SELECT fo.field, EXTRACT(EPOCH FROM min(bl.ts) - fo.ts) AS sec
    FROM f fo
    JOIN f bl ON bl.session_id = fo.session_id AND bl.field = fo.field
             AND bl.event_name = 'form_field_blur' AND bl.ts > fo.ts
    WHERE fo.event_name = 'form_field_focus'
    GROUP BY fo.field, fo.ts
)
SELECT r.field,
       count(DISTINCT r.session_id)                                     AS reached,
       round(100.0 * count(DISTINCT e.session_id)
                   / count(DISTINCT r.session_id), 1)                   AS error_rate_pct,
       max(e.error_code)                                                AS top_error,
       (SELECT round(percentile_cont(0.5) WITHIN GROUP (ORDER BY sec)::numeric, 1)
          FROM spans s WHERE s.field = r.field)                         AS median_sec
FROM f r
LEFT JOIN f e ON e.session_id = r.session_id AND e.field = r.field
             AND e.event_name = 'form_field_error'
WHERE r.event_name = 'form_field_focus'
GROUP BY r.field
ORDER BY error_rate_pct DESC;

Результат из иллюстрации даёт два разных диагноза, которые сводная конверсия смешивала в один:

1. Поле ИНН: 41 % ошибок, медиана 38 секунд. Маска принимает 10 цифр, у индивидуальных предпринимателей их 12. Дефект правила валидации и подписи. Правка: принимать оба формата, показать пример прямо в подписи, проверять контрольную сумму, а не длину.
2. Между ИНН и комментарием теряется треть. Эти люди не ошибались — они ушли. Дело не в валидации, а в готовности продолжать: поле читается как «сейчас начнётся бухгалтерия». Правка на уровне сценария: спрашивать ИНН после подтверждения заявки, когда цена уже известна, или подставлять его по названию компании из справочника.

Одна цифра «конверсия формы 46 %» эти случаи не различает — и команда полгода полировала бы валидацию, не трогая причину половины потерь. Техническая сторона форм — маски, режимы валидации, состояния — разобрана во фронтенде.

Разбор 3: конверсия выросла, а денег не прибавилось

Команда упростила оформление подписки: убрала шаг с выбором тарифа, поставила дефолтом «Про». Конверсия в оплату выросла с 4,1 % до 5,3 %. Праздник. Через два месяца: возвраты выросли втрое, отток на втором месяце — с 8 % до 19 %, поддержка завалена «я не понял, за что списали». Выручка на когорту — ниже прежней.

Классическая прокси-ловушка: оптимизировали шаг, а не результат. Лечится заранее — тремя договорённостями. У целевой метрики есть контрметрики: возвраты, отток первого месяца, обращения «неожиданное списание», доля даунгрейдов. Решение принимается по OEC — согласованной комбинации, а не по одной цифре: «успех = рост оплат при том, что возвраты не выросли больше чем на 1 п. п., а отток второго месяца не вырос». И метрика измеряется на горизонте, где проявляется ущерб: если возврат возможен 14 дней, недельный эксперимент его физически не увидит.

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

Разбор 4: средняя температура

Метрика по всем пользователям сразу почти всегда врёт, потому что усредняет несравнимые группы. Обязательные разрезы: новые и опытные (онбординг влияет только на новых, их доля мала, и провал не виден в общем числе); устройство и размер экрана — классика жанра: на десктопе конверсия формы 71 %, на мобильном 38 %, среднее 54 %, и катастрофы никто не замечает; роль и сегмент (самозанятый против ООО, врач против администратора, бесплатный тариф против платного); язык и регион — длина строк ломает кнопки, и метрика падает только там; скорость соединения (медленная сеть плюс отсутствие состояния загрузки = двойные отправки); пользователи вспомогательных технологий — об этом ниже. Общее правило: прежде чем радоваться или горевать по поводу средней, разложите её на 3–5 разрезов. Половина «загадочных» метрик объясняется тем, что внутри сидят две разные популяции.

Инструментирование: события — часть макета

Здесь дизайн встречается с разработкой, и здесь чаще всего всё разваливается: событие, которое не поставили, невозможно посчитать задним числом. Поэтому план измерения — часть передачи макета, наравне с состояниями и токенами. Ещё три вещи стоит понимать про сам конвейер данных (интерфейс → SDK → коллектор → хранилище → витрина). События теряются: блокировщики, закрытая вкладка до отправки батча, оффлайн — потери от 10 до 30 %; абсолютные числа занижены, а отношения (конверсии) устойчивее, потому что потери примерно одинаковы на обоих концах, поэтому сверять события с биллингом «в лоб» бессмысленно. Клик — не результат: «нажал кнопку» не означает «получилось», нужны пары attempt и success/error, иначе «не пробовал» неотличимо от «пробовал и не смог». Свойства важнее событий: одно событие form_field_error со свойствами field, error_code, attempt_number заменяет двадцать разных событий и не требует переделки при добавлении поля.

Модель данных, к которой обычно приходят:

Ключевая сущность здесь — TASK_ATTEMPT. Сырые события живут в аналитике, но дизайнеру нужен слой «попытка выполнить задачу»: у неё есть начало, конец, успех и ошибки. Именно на нём считаются те самые задачные метрики, которые в лаборатории считают вручную, — и только так лабораторные числа становятся сравнимыми с продакшеном. Сам план событий (tracking plan) удобно держать текстом рядом с макетом:

# analytics/lead-form.yaml — план измерения к макету «Заявка, шаг 2»
form_id: lead_step2
owner: design@example.com          # владелец определения метрики
linked_design: figma/lead/step2    # ссылка на макет и его состояния

events:
  - name: form_view          # форма видна не менее чем на 50 %
    properties:
      entry_point: {type: enum, values: [catalog, promo, direct]}
  - name: form_field_focus   # фокус впервые попал в поле, в том числе с клавиатуры
    properties:
      field: {type: string, required: true}
  - name: form_field_error   # пользователю ПОКАЗАНА ошибка валидации
    properties:
      field:          {type: string, required: true}
      error_code:     {type: string, required: true}   # inn_length, inn_checksum, ...
      attempt_number: {type: int, required: true}
      trigger:        {type: enum, values: [blur, submit, live]}
  - name: form_submit_attempt                          # до ответа сервера
  - name: form_submit_success
    properties:
      duration_ms: {type: int, required: true}         # от form_view до успеха
  - name: form_submit_error
    properties:
      error_code: {type: string, required: true}
      source:     {type: enum, values: [client, server, network]}

metrics:                                                 # знаменатель зафиксирован явно
  field_completion_rate: form_field_blur_nonempty / form_field_focus
  error_rate_per_field:  form_field_error / form_field_focus
  form_success_rate:     form_submit_success / form_view
guardrails: [support_tickets_tag_inn, duplicate_submissions_rate]   # не должны расти

Такой файл решает три проблемы разом: разработчик знает, что ставить; аналитик — как считать; человек, который придёт через год, понимает, что означало число. Дисциплина именования — минимум такой: сущность_событие в snake_case, единый словарь имён свойств, без пробелов и локализованных строк в идентификаторах (см. руководство Segment). Про качество данных в целом — трек data engineering.

Эксперименты: когда A/B, а когда нет

Метрика без гипотезы превращается в «смотрим на дашборд». Полезно держать явный цикл.

Узел «План» перед правкой — самое ценное здесь. Если ожидаемый эффект записан заранее («ждём рост доходимости с 61 % до 72 % за две недели, контрметрика — обращения по теме ИНН»), результат нельзя переинтерпретировать задним числом. Без этого команда всегда найдёт метрику, которая выросла, и объявит успех.

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

$$n = \frac{2 \left( z_{1-\alpha/2} + z_{1-\beta} \right)^2 \cdot \bar p \left( 1 - \bar p \right)}{\delta^2}$$

где $\delta$ — минимальный детектируемый эффект (MDE) в долях, $\bar p$ — базовая конверсия.

"""Сколько наблюдений на группу нужно, чтобы увидеть эффект."""
import math

Z_ALPHA, Z_BETA = 1.96, 0.84        # alpha = 0.05 двусторонний, мощность 80 %

def sample_size(baseline: float, mde_abs: float) -> int:
    p = baseline + mde_abs / 2      # baseline и эффект — в долях, не в процентах
    return math.ceil(2 * (Z_ALPHA + Z_BETA) ** 2 * p * (1 - p) / mde_abs ** 2)

base = 0.112
for rel in (0.30, 0.15, 0.10, 0.05):        # относительный прирост
    mde = base * rel
    print(f"эффект +{rel:.0%} отн. ({mde * 100:.2f} п. п.): {sample_size(base, mde)} на группу")

эффект +30% отн. (3.36 п. п.): 1559 на группу
эффект +15% отн. (1.68 п. п.): 5884 на группу
эффект +10% отн. (1.12 п. п.): 12972 на группу
эффект +5%  отн. (0.56 п. п.): 50811 на группу

Главный практический вывод: если продукт видит 400 заявок в месяц, A/B-тест на конверсию не сработает никогда — не потому что дизайн плох, а потому что физика. Кто-нибудь обязательно предложит «остановить тест, когда p-value станет меньше 0,05»: это подглядывание (peeking), которое поднимает долю ложных срабатываний с заявленных 5 % до 20–30 %. Либо считайте размер выборки заранее и не подглядывайте, либо берите методы последовательного анализа. Что делать при малом трафике? Измерять выше по лестнице: не сквозную конверсию, а доходимость до шага, ошибки валидации, время — такие метрики «толще», эффект в них больше и виден на меньшей выборке. Юзабилити-тест на 8–12 людях с задачными метриками ответит «стало ли понятнее», пусть и без строгих процентов. Пре/пост-сравнение до и после релиза не изолирует сезонность, кампании и другие релизы: годится при крупном эффекте и отсутствии посторонних изменений, но подаётся как ограничение, а не как эксперимент. Обратный тест (holdback) — выкатить на 90 %, оставив 10 % на старой версии.

Обо что спотыкаются ещё: novelty и primacy (новое привлекает внимание, привычное сопротивляется — обоим нужно 1–2 недели, чтобы улечься); недельная сезонность (длительность теста — целое число недель); множественные сравнения (проверили двадцать метрик — одна «значимо» выросла случайно; главная метрика объявляется заранее). И не всё вообще тестируется: изменения бренда, крупные перестройки навигации, редкие сценарии, всё, что касается доверия и денег. Подробнее — MVP и эксперименты и книга Kohavi, Tang, Xu «Trustworthy Online Controlled Experiments».

Доступность в метриках

Соблазн померить доступность одним числом велик и вреден. Нельзя измерить напрямую: долю пользователей скринридеров (они не отдают себя аналитике, а определение по User-Agent — миф и нарушение приватности) и «уровень доступности продукта» одним индексом. Что измерять можно и полезно: число нарушений автопроверки на страницу (axe, Lighthouse) в динамике — грубо, но ловит регрессии; доля компонентов дизайн-системы с нарисованными и задокументированными состояниями фокуса, ошибки, отключённости; доля пар «текст/фон» в токенах, проходящих порог контраста — считается скриптом; задачные метрики на пользователях вспомогательных технологий — выборка маленькая, но именно она показывает реальные барьеры; доля сессий с клавиатурной навигацией (были нажатия Tab до первого клика); обращения в поддержку с тегом доступности и скорость на слабых устройствах.

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

Метрики дизайн-системы

Систему тоже надо измерять, иначе она превращается в библиотеку, которой не пользуются (см. дизайн-системы): покрытие — доля экранов, собранных из компонентов без отсоединённых копий; доля кастомных компонентов в новых макетах (растёт — системе чего-то не хватает); число уникальных значений в проде — сколько разных оттенков серого, кеглей и радиусов реально встречается в собранном приложении (отличная метрика расхождения макета и кода); время сборки типового экрана; время закрытия запроса на новый компонент; дефекты доступности в компонентах — они тиражируются на все продукты сразу.

Где данные, а где вкус

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

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

Есть закономерность с оговорками. Закон Фиттса, закон Хика, ограничения рабочей памяти, эффект позиции в списке, узнавание вместо припоминания. Источник гипотез, а не готовых ответов: параметры зависят от контекста, устройства и опыта человека.

Измеримо, но не в короткой перспективе. Доверие, ощущение качества, узнаваемость бренда, эстетико-юзабилити-эффект (красивое воспринимается как более удобное — эффект реальный и воспроизводимый, но он не устраняет проблемы, а маскирует их). Меряется длинными исследованиями, а не A/B-тестом за неделю.

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

И про честность с числами. Дизайнер, приносящий «конверсия выросла на 18 %» без интервала, без размера выборки и без контрметрик, ничем не лучше дизайнера, приносящего «стало красивее». Правильная форма: «доходимость до отправки выросла с 61 % до 74 %, интервал 70–78 %, n = 1 240, за две недели; обращения по теме ИНН упали с 400 до 60 в месяц; средний чек не изменился». Такое утверждение можно проверить и оспорить — значит, ему можно верить.

Метрики и передача в разработку

Всё измерение упирается в один вопрос: доехало ли решение до пользователя. Поэтому план измерения — часть передачи макета, а не отдельный ритуал аналитика. Что дизайнер отдаёт в разработку (подробно — в следующей статье про хендофф):

1. Все состояния, а не только «когда всё хорошо»: загрузка, пусто, ошибка, частичные данные, длинный текст, отсутствие прав.
2. Правила поведения: что при 320 px, что при переполнении, что при медленной сети, куда уходит фокус после закрытия модалки.
3. Токены, а не пиксельные значения: space.md, color.action.primary.bg — имена, которые есть в коде.
4. План событий (тот самый YAML): что снимаем, с какими свойствами, какие метрики и контрметрики из этого считаются.
5. Пороги качества: целевые LCP/INP/CLS для экрана, максимальное время отклика на действие (см. взаимодействие и состояния).

Почему «пиксель в пиксель» — плохая цель

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

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

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

«Пиксель в пиксель» разрушает сотрудничество. Разработчик, которому вернули задачу из-за 3 px, перестаёт приносить вопросы вида «а что здесь при пустом списке?» — а именно эти вопросы спасают продукт. Стоимость испорченного контакта выше стоимости любой неровности.

Правильная цель формулируется иначе: сборка соответствует правилам и проходит по метрикам. Отступы — из токенов, состояния — все нарисованные, события — по плану, контраст и размеры целей — по порогам, Web Vitals — в бюджете. Отклонения по существу («потерялось состояние ошибки», «фокус не виден», «не снимается событие ошибки валидации») — дефекты, их заводят; отклонение в 2 px — замечание, и живёт оно в бэклоге полировки, если вообще нужно. Полезный ритуал после релиза — дежурство первых 48 часов: дизайнер вместе с разработчиком смотрит на новые события и первые записи сессий. Половина проблем ловится в первые сутки — событие не приходит, состояние не показывается, ошибка выглядит не так, как в макете. Через неделю это уже «вроде работает».

Панель дизайнера: что смотреть регулярно

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

Типичные ошибки

1. Метрика придумана после релиза — тогда всегда найдётся выросшая. План измерения пишется до правки.
2. Одна цифра вместо разреза — средняя конверсия скрывает провал на мобильных, у новичков и у пользователей вспомогательных технологий.
3. Обещан бизнес-эффект («редизайн даст +10 % выручки») — это нельзя ни сдержать, ни проверить.
4. Нет контрметрик — оптимизировали шаг, испортили результат: меньше подтверждений, больше ошибочных операций.
5. Клик засчитан за успех — нужны пары attempt/success/error, иначе «не пробовал» неотличимо от «не смог».
6. Среднее арифметическое времени и проценты на пяти людях — скошенное распределение требует медианы, а на n = 5 интервал шире половины шкалы.
7. Подглядывание в A/B и тест длиной в три дня — оба способа гарантированно получить неверный ответ.
8. NPS как дизайнерская метрика — не привязан ни к задаче, ни к экрану, для правки макета бесполезен.
9. События снимает «кто-нибудь» — без владельца определения через квартал никто не помнит, что означает число.
10. Метрика вместо наблюдения — цифра говорит «где», а «почему» покажут только люди: исследования и юзабилити-тестирование.
11. Дашборд вместо решения — метрика, по которой за квартал не принято ни одного решения, это работа впустую; выключайте её.

Мини-итог

• Метрика нужна для обнаружения, локализации и проверки — не для оценки красоты и не для отчётности ради отчётности.
• Между кнопкой и выручкой четыре уровня: обещайте задачные метрики, показывайте продуктовые, не берите бизнес-результат в одиночку. Дерево метрик превращает «форма плохая» в «+14 п. п. на втором шаге дают +23 % заявок».
• HEART полезен процессом Goals → Signals → Metrics, а не пятью буквами; незаполненная категория — нормальный ответ.
• Задачные метрики: успех с доверительным интервалом, время медианой, ошибки по типам, усилие через SEQ/SUS. Пофайловая аналитика формы различает «ошиблись» и «ушли» — два разных диагноза с разными решениями.
• У целевой метрики всегда есть контрметрика; без неё оптимизация ломает продукт по соседству. События — часть передачи макета: план измерения пишется вместе с состояниями и токенами.
• A/B-тест требует трафика; при малом объёме измеряйте выше по лестнице и проверяйте на людях, честно называя ограничения.
• Разделяйте «есть порог», «есть закономерность» и «мне нравится»: смешивать эти категории — способ проиграть спор дважды.
• «Пиксель в пиксель» не влияет ни на одну метрику и разрушает сотрудничество; цель — соответствие правилам, состояниям, порогам и плану измерения.

Источники

• Rodden K., Hutchinson H., Fu X. «Measuring the User Experience on a Large Scale», CHI 2010 — оригинал HEART.
• Sauro J., Lewis J. «Quantifying the User Experience: Practical Statistics for User Research» — основная книга по количественным методам в UX.
• MeasuringU: SUS, SEQ, размеры выборки.
• Kohavi R., Tang D., Xu Y. «Trustworthy Online Controlled Experiments» — эксперименты без самообмана.
• Tullis T., Albert B. «Measuring the User Experience» — каталог метрик и способов их считать.
• NN/g: «Success Rate: The Simplest Usability Metric», «Confidence Intervals», «Why You Only Need to Test with 5 Users»; Spool J. «Net Promoter Score Considered Harmful».
• Web Vitals, Segment: naming conventions for clean data и ISO 9241-11 (определения результативности, эффективности, удовлетворённости).

Что дальше

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