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

Есть момент, который переживал каждый, кто делал продукт. Макет согласован. Команда довольна: сетка ровная (https://courses.digitable.life/post/ux-design/06-visual-basics/), компоненты из системы (https://courses.digitable.life/post/ux-design/07-design-systems/), состояния прорисованы (https://courses.digitable.life/post/ux-design/08-interaction/), тексты вычитаны (https://courses.digitable.life/post/ux-design/09-microcopy/). Релиз. Через неделю в поддержку приходит: «А где скачать отчёт?» — при том, что кнопка «Скачать отчёт» находится ровно посередине экрана, размером 160 на 40 пикселей, с иконкой.

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

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

1. Что тест проверяет, а что не проверяет

Разграничим три разных вопроса, которые часто путают:

Юзабилити-тест отвечает только на второй вопрос. Он не скажет, нужен ли продукт, — про это исследования и https://courses.digitable.life/post/ux-design/02-personas-and-jtbd/. Он не скажет, какая из двух кнопок принесёт больше денег — для этого нужны тысячи пользователей и эксперимент (https://courses.digitable.life/post/product-management/05-mvp-and-experiments/). Он не заменяет QA: проверка соответствия требованиям — другая профессия и другой процесс (https://courses.digitable.life/post/testing/04-manual-testing/), и автотесты интерфейса (https://courses.digitable.life/post/frontend/15-frontend-testing/) ловят регрессии, а не непонимание.

Формальное определение (ISO 9241-11): usability — степень, в которой продукт может быть использован определёнными пользователями для достижения определённых целей с результативностью, эффективностью и удовлетворённостью в заданном контексте использования. Три слова «определёнными», «определённых», «заданном» — самое важное в этом определении. Юзабилити не свойство интерфейса. Это свойство пары «интерфейс + человек + задача + условия». Поэтому «удобный интерфейс» без указания, для кого и для чего, — пустая фраза.

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

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

2. Почему без теста мы систематически ошибаемся

Дело не в лени, а в трёх эффектах, которые нельзя отключить усилием воли. Проклятие знания: зная ответ, невозможно смоделировать состояние незнания. Классический эксперимент Элизабет Ньютон (Стэнфорд, 1990): «стучащие» отбивали пальцем ритм известной песни, «слушающие» угадывали; стучащие предсказывали 50% успеха, реально угадали 2,5%. В голове стучащего играла музыка, в реальности был стук по столу — ровно так же в голове дизайнера играет структура продукта, а у пользователя есть только пиксели. Ложный консенсус: мы переоцениваем долю людей, думающих как мы, отсюда «ну это же очевидно» — фраза, после которой стоит запланировать тест. Предвзятость подтверждения: мы замечаем то, что подтверждает наш вариант, поэтому «тест», который проводит автор макета без протокола, — процедура сбора подтверждений.

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

3. Виды тестов: четыре оси выбора

Формативный тест ведут во время проектирования: цель — найти и починить, выборка маленькая, результат — список проблем. Это 90% всех тестов и, вероятно, весь ваш рабочий репертуар. Суммативный (бенчмарк) отвечает на вопрос «стало ли лучше, чем было»: метрики, контрольная группа, десятки участников; он нужен, когда надо доказать эффект редизайна перед бизнесом.

Модерируемый тест дороже, но даёт понимание причин: можно спросить «а что вы ожидали увидеть?». Немодерируемый (Maze, UserTesting, Useberry и подобные) даёт объём и скорость, но вы получите только то, что попало в запись, и не сможете вытащить человека из тупика — а значит, часть сессий сгорит впустую. Практическое правило: немодерируемые тесты хороши для узких, хорошо сформулированных вопросов («найдут ли раздел», «поймут ли этот экран за 5 секунд»), модерируемые — для многошаговых сценариев (https://courses.digitable.life/post/ux-design/04-user-flows/), где важна причина.

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

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

4. Сколько людей на самом деле нужно

Самое цитируемое и самое искажаемое число в UX — «пять пользователей»; разберём его честно. Модель Нильсена и Ландауэра (1993) исходит из простого предположения: каждая проблема имеет вероятность p быть обнаруженной одним участником, участники независимы. Тогда вероятность найти проблему хотя бы одним из n участников равна 1 − (1 − p)^n.

def probability_of_finding(p: float, n: int) -> float:
    """Вероятность, что проблему с «заметностью» p увидит хотя бы один из n участников."""
    return 1 - (1 - p) ** n

# Средняя заметность проблемы у Нильсена и Ландауэра ~ 0.31
print([round(probability_of_finding(0.31, n), 2) for n in (1, 3, 5, 10, 15)])
# [0.31, 0.67, 0.84, 0.98, 1.0]

Отсюда знаменитый вывод: пятеро находят около 85% проблем, а дальше кривая выполаживается — и выгоднее починить найденное и протестировать заново, чем добирать участников. Логика верная, но держится на трёх допущениях, каждое из которых в жизни ломается:

1. p = 0.31 — среднее по конкретным исследованиям начала 90-х. Для «тихих» проблем (человек не замечает, что заполнил поле неверно) p может быть 0.05 — тогда пятеро найдут её с вероятностью 23%.
2. Аудитория однородна. Если у вас три разных роли — админ, оператор, клиент, — это три разных набора проблем. Пять человек нужны на каждый сегмент, иначе вы просто не увидите чужие сценарии.
3. Сложность продукта ограничена. Спул и Шрёдер (CHI 2001) на большом e-commerce показали, что пять пользователей находят заметно меньше 85% — там пространство сценариев огромно.

Самая аккуратная эмпирическая проверка — работа Лоры Фолкнер (2003): она набрала 60 участников, а потом случайно нарезала из них подвыборки. Пятёрки находили от 55% до 99% проблем — то есть среднее около 85% верно, но разброс огромен, и конкретно ваша пятёрка может оказаться неудачной. Десятки находили не менее 80%, двадцатки — не менее 95%.

Рабочий вывод, который стоит держать в голове:

• 5 человек на сегмент — разумный дефолт для формативного теста, если вы итерируете. Один раунд из пяти — это не «мы всё проверили», это «мы сняли верхний слой».
• 3 человека раз в две недели лучше, чем 12 человек раз в полгода: Стив Краг в Rocket Surgery Made Easy предлагает именно такой ритм — регулярность важнее размера раунда.
• Для чисел (доля успеха, время, SUS) нужно 20+, иначе доверительный интервал шире, чем эффект, который вы хотите измерить. Ниже посчитаем это явно.

5. Кого звать и как не испортить выборку

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

# screener.yaml — критерии отбора для теста экрана «Выставление счёта»
segment: "бухгалтер малого бизнеса"
target_n: 5
quotas:
  опыт: { "не пользовался": 2, "меньше 3 месяцев": 2, "больше года": 1 }
  устройство: { "ноутбук 13 дюймов": 3, "внешний монитор": 2 }  # частый экран по аналитике
must_have:
  - "выставлял счета минимум 3 раза за последний месяц"   # поведение, а не самооценка
  - "работает в компании до 30 человек"
exclude:
  - "работает в IT-компании"                              # профдеформация
  - "участвовал в наших тестах за последние 3 месяца"
  - "друзья и родственники команды"

Кого не берём и почему:

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

6. План теста: от вопроса к заданиям

Тест начинается не с заданий, а с вопроса, ради которого мы тратим неделю: формулировка «протестируем новый экран» — это отсутствие вопроса.

# test-plan.yaml
research_question: "Может ли бухгалтер, впервые увидевший новый экран счетов,
  выставить счёт постоянному клиенту без обращения в поддержку?"
decisions_it_affects:            # если этот список пуст — тест не нужен
  - "оставляем ли мастер из трёх шагов или делаем одну форму"
  - "нужен ли шаблон счёта на первом экране"
hypotheses:
  - { id: H1, text: "выбор шаблона спрятан за иконкой", confirm_if: "3 из 5 не открыли за 60 сек" }
  - { id: H2, text: "автосумма НДС непонятна", confirm_if: "участник пересчитывает вручную" }
tasks:
  - id: T1
    scenario: "Вам позвонил постоянный клиент ООО «Ромашка» и попросил счёт
      на те же услуги, что в прошлом месяце. Сделайте это."
    success_criteria: "счёт создан и отправлен, сумма совпадает"
    max_minutes: 5
participants: 5                  # 5 на сегмент, сессия 45 минут, разбор в тот же день

Обратите внимание на поле decisions_it_affects: если ни одно решение не зависит от результата, тест проводить не надо — вы просто соберёте материал для красивого отчёта. Порядок заданий: от общего к частному, от простого к сложному, но первое задание не должно быть самым важным — человек ещё привыкает к камере и голосу в наушниках. Одна сессия — 45–60 минут, не больше; дальше начинается усталость, и вы измеряете уже её. Реалистично это 3–5 заданий.

7. Как формулировать задания: разбор

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

Правила, которые стоит соблюдать буквально:

1. Никаких слов из интерфейса. Если в макете кнопка «Экспорт», в задании — «отправить коллеге», «открыть в Excel», «сохранить себе». Иначе вы тестируете поиск по совпадению строки, а не понимание. Это связано с https://courses.digitable.life/post/ux-design/09-microcopy/: тест на «чужих» словах — лучший способ проверить, насколько ваши формулировки совпадают со словарём пользователя.
2. Реальные данные, а не «Иванов Иван». Просите участника использовать свои реальные названия компаний, суммы, файлы — с ними всплывают проблемы длины строк, форматов и валидации.
3. Критерий успеха задан заранее и записан. Иначе после сессии начнётся спор, засчитывать ли «нашёл, но через поддержку».
4. Одно задание — одна цель. Составные («создайте счёт, потом измените его и отправьте») сливают находки в кашу.
5. Задание выдаётся текстом, а не проговаривается: интонация — это подсказка. Крупный текст на отдельной карточке или в чате.

8. Сессия: как вести и как молчать

Основной метод — think aloud (Эрикссон и Саймон, Protocol Analysis): участник проговаривает мысли по ходу действия. Важный нюанс: строгий протокол требует, чтобы ведущий не задавал вопросов во время задачи и напоминал только «продолжайте, пожалуйста, говорить». Как только вы спрашиваете «а почему вы так подумали?», человек переключается с выполнения на объяснение — и начинает рационализировать. Компромисс, которым обычно пользуются на практике: «думай вслух» во время задачи, а вопросы — после задачи, по свежим следам, при необходимости с перемоткой записи.

Вводная речь — не формальность, она снимает половину смещений:

«Спасибо, что пришли. Сегодня мы проверяем макет — не вас: здесь невозможно ошибиться, и если что-то непонятно, это проблема макета, именно её мы и ищем. Говорите вслух всё, что приходит в голову, включая недовольство, — критика полезнее похвалы. Я автор части этих экранов, но мне важна правда, а не комплименты, и я буду молчать, чтобы не подсказывать: это не невежливость. Вы можете прекратить в любой момент, вознаграждение останется в силе. Записываем экран и голос, запись видят четыре человека в команде. Хорошо?»

Что делает модератор во время задачи:

• Молчит. Правило трёх секунд: прежде чем что-то сказать, сосчитайте до трёх. В 70% случаев участник заговорит сам, и вы получите бесплатные данные.
• Возвращает вопрос («бумеранг» Крага). «А что будет, если я нажму?» → «А как вы думаете, что будет?» → «Давайте нажмём и посмотрим».
• Пишет только факты: что кликнул, куда посмотрел, что сказал дословно.
• Решает, когда прервать. Если человек буксует пятую минуту и явно расстроен — прекращаем задачу. Отметить «не справился» и сохранить человеку достоинство важнее, чем добить сценарий.

Запрещённые фразы — их стоит распечатать и повесить перед собой:

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

9. Каталог самообманов

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

Три самых дорогих разберём подробно. Демонд-характеристики (Орн, 1962): участник строит гипотезу о том, что от него хотят, и подыгрывает; симптом — сессия, где всё получилось идеально и человек хвалит каждый экран. Лекарство: прямое разрешение критиковать во вводной, отсутствие автора рядом с участником, задания без ценностной окраски (не «оцените наш новый удобный мастер», а «сделайте вот это»).

Эффект прототипа. В кликабельном прототипе (https://courses.digitable.life/post/ux-design/05-wireframes-and-prototypes/) работают не все элементы. Участник кликает в «мёртвую» зону, ничего не происходит — и винит себя, а не макет; вы записываете «не понял интерфейс», хотя проблема в заглушке. Лекарство: заранее составить список неработающих мест и правило реакции («здесь я говорю: представьте, что сохранилось»), а где возможно — тестировать на реальном коде, пусть и сыром.

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

10. Записи: факт против интерпретации

Единственное, что надо натренировать до автоматизма, — разделять две колонки.

Правило: в тикет и в отчёт идёт наблюдение, интерпретация помечается как гипотеза. Разница не педантизм: наблюдение проверяемо и переживёт спор, интерпретация — предмет обсуждения, и разработчик часто предложит объяснение лучше вашего. Для сведения данных удобна «радужная таблица» (rainbow spreadsheet, приём Томера Шарона): строки — находки, столбцы — участники, отметки заполняются прямо во время сессий.

Такая таблица делает две вещи. Во-первых, показывает частоту — четыре отметки в строке снимают вопрос «может, это он один такой». Во-вторых, дисциплинирует: чтобы поставить отметку, надо сформулировать проблему одинаково для всех участников, а это уже половина анализа.

11. Анализ и приоритизация находок

Сырых наблюдений после пяти сессий будет 60–120, из них проблем — 15–30; чинить все не нужно и нельзя. Серьёзность удобно оценивать по шкале Нильсена (0–4): 0 — не проблема; 1 — косметика, чинить, если останется время; 2 — мелкая, низкий приоритет; 3 — крупная, высокий приоритет; 4 — катастрофа, чинить до релиза. Оценивают трое-четверо независимо, потом сверяются: расхождения на два балла — сигнал, что проблема сформулирована размыто.

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

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

Что делать с находками дальше:

• Проблема в макете → правим макет и тестируем снова.
• Проблема в тексте → чиним формулировку (https://courses.digitable.life/post/ux-design/09-microcopy/); это самые дешёвые правки с самым большим эффектом, и они не требуют новой вёрстки.
• Проблема в структуре → это уже архитектура (https://courses.digitable.life/post/ux-design/03-information-architecture/), правка дорогая, стоит подтвердить отдельным tree-тестом.
• Проблема в реализации (медленно, скачет вёрстка, теряется фокус) → в бэклог разработки, с записью и таймкодом.
• Проблема в ожиданиях (человек хотел функцию, которой нет) → это не юзабилити, а продуктовый вход (https://courses.digitable.life/post/product-management/01-discovery-and-research/).

12. Числа на маленькой выборке: что честно, а что нет

Три метрики, которые действительно собирают в формативных тестах:

Доля успеха по задаче. Считается по заранее записанному критерию. Проблема в том, что на пяти участниках интервал огромен:

from math import sqrt

def adjusted_wald(successes: int, n: int, z: float = 1.96) -> tuple[float, float]:
    """Интервал для доли по методу adjusted-Wald (Агрести — Коулл).

    На маленьких выборках честнее обычной формулы: та при 5 из 5 даёт
    интервал нулевой ширины, что очевидно неверно.
    """
    n_adj = n + z ** 2                       # как будто добавили z^2 наблюдений
    p_adj = (successes + z ** 2 / 2) / n_adj
    margin = z * sqrt(p_adj * (1 - p_adj) / n_adj)
    return max(0.0, p_adj - margin), min(1.0, p_adj + margin)

print(adjusted_wald(4, 5))    # ~ (0.36, 0.98) — «80%» это «от трети до почти всех»
print(adjusted_wald(16, 20))  # ~ (0.58, 0.93) — уже можно о чём-то говорить

Отсюда правило: на пяти участниках пишите «4 из 5», а не «80%». Процент создаёт иллюзию точности, которой нет, и через месяц кто-нибудь вставит это «80%» в презентацию для совета директоров.

SEQ (Single Ease Question) — один вопрос сразу после задачи: «Насколько простой или сложной оказалась задача?» по 7-балльной шкале. Занимает 10 секунд и работает как маркер: среднее по индустрии около 5.5, значение 4 и ниже — сигнал разбираться. SUS (System Usability Scale), Джон Брук, 1986 — десять утверждений, счёт 0–100 (не проценты!); средний балл по сотням исследований около 68 — это примерно 50-й процентиль, ниже 68 хуже среднего продукта, выше 80 хорошо. Но SUS осмыслен на 12+ участниках и на работающем продукте, а не на прототипе, где половина утверждений неприменима.

Полный разговор про метрики, их связь с продуктовыми показателями и про то, как не измерять «удобство» в вакууме, — в следующей статье (https://courses.digitable.life/post/ux-design/12-metrics/) и в https://courses.digitable.life/post/product-management/08-analytics-and-decisions/.

13. Три разбора

Общий паттерн любого разбора: симптом → что на самом деле произошло → механизм → починка → как проверить, что починили. Полезно держать в голове типовую траекторию участника внутри задачи:

13.1. «Форма неудобная» — почему именно

Симптом: три из пяти участников не завершили оформление заявки, средняя длительность — 6 минут вместо ожидаемых полутора. Что было видно на записях:

1. Поле «Индекс» обязательное. Двое не знают свой индекс, уходят искать в другой вкладке, один не возвращается. Механизм: мы попросили данные, которых у человека нет в голове, и не дали способа их получить. Починка: индекс подставляется по адресу, поле не обязательно.
2. Валидация срабатывает на каждый символ. Человек вводит «+7», видит красное «неверный формат», пугается, стирает всё. Механизм: система обвиняет пользователя в незавершённости действия. Починка: валидировать по уходу из поля, а успешную валидацию показывать молча (https://courses.digitable.life/post/frontend/12-forms-and-validation/).
3. Ошибка сервера очистила форму. Один участник потерял 4 минуты работы и сказал «ну и ладно». Механизм: состояние формы жило только в DOM. Починка — на стороне разработки: черновик в локальном хранилище. В макете это обязано быть нарисовано как состояние, иначе никто не вспомнит.
4. Подписи внутри полей (placeholder вместо label). При заполнении подсказка исчезает, и на шаге проверки человек не понимает, что где. Плюс это ломает доступность (https://courses.digitable.life/post/accessibility/07-forms/).

Как проверить, что починили: тот же сценарий, те же критерии, новые участники. Не «стало красивее», а «5 из 5 завершили за 2 минуты».

13.2. «Кнопку не нашли» — четыре разных механизма

Одинаковый симптом, четыре разных диагноза, и лечатся они по-разному.

Баннерная слепота. Кнопка стоит в правом верхнем углу, оформлена ярко и обособленно — то есть ровно там и так, где люди научились игнорировать рекламу. Исследования Бенвея (1998) и последующие ай-трекинги NN/g показывают, что зоны, похожие на рекламные блоки, не попадают даже в периферийное внимание. Починка: переместить действие в контекст объекта, над которым оно совершается.

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

Иконка без подписи. Три горизонтальные линии, шестерёнка, «⋮» узнаваемы, всё остальное — ребус: иконка «поделиться» в разных ОС выглядит по-разному, и половина людей её не опознаёт. Починка: подпись рядом с иконкой — да, она занимает место, но отсутствие подписи занимает время пользователя.

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

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

13.3. «Пошли не туда» — проблема структуры, а не экрана

Симптом: четверо из пяти ищут «Отчёты» в разделе «Аналитика», хотя отчёты лежат в «Документах».

Это не проблема кнопки и не лечится цветом: это несовпадение вашей структуры с ментальной моделью пользователя (https://courses.digitable.life/post/ux-design/03-information-architecture/). Дизайн экрана здесь бессилен — можно сделать самую заметную кнопку в мире, но человек её не ищет, он ищет раздел. Правильный инструмент — tree testing: даёте только дерево разделов, без визуала, и просите найти, где бы человек искал нужное. Метрики: доля верных нахождений, доля прямых путей (без блужданий), первый клик. Если 4 из 5 идут в «Аналитику» — надо либо переименовывать, либо дублировать вход, либо менять структуру. Обратная операция — card sorting: даёте набор сущностей и просите сгруппировать; получаете словарь пользователя вместо внутреннего словаря компании.

Полезное эмпирическое наблюдение: по данным Бэйли и Уолфсон, при верном первом клике задача завершается успешно примерно в 87% случаев, при неверном — около 46%. Первый клик — очень сильный предиктор, поэтому дешёвый first-click тест часто заменяет полноценную сессию на ранней стадии.

14. Родственные методы: когда что дешевле

Два метода «без людей» дают много пользы на ранних стадиях. Когнитивный проход (cognitive walkthrough, Уортон и др.): идёте по сценарию шаг за шагом и на каждом шаге отвечаете на четыре вопроса. (1) Попытается ли человек добиться нужного эффекта — то есть понимает ли он, что вообще должен сейчас сделать? (2) Заметит ли он, что нужное действие доступно? (3) Свяжет ли он это действие с нужным эффектом? (4) Увидит ли он прогресс после действия? Каждое «нет» — гипотеза для теста.

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

15. Доступность на тестах

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

• Включать людей с инвалидностью в рекрут — хотя бы в один раунд из нескольких, а не «отдельным исследованием доступности когда-нибудь потом».
• Проводить сессии с ассистивными технологиями, на которых человек работает каждый день: свой скринридер, свои настройки, своя скорость речи. Тестировать «за него», включив VoiceOver впервые, бессмысленно — вы измерите свой навык.
• Проверять клавиатурный проход самим, до сессии: порядок фокуса, видимость индикатора, ловушки фокуса (https://courses.digitable.life/post/accessibility/04-keyboard-and-focus/). И не смешивать проверку соответствия WCAG (это чек-лист и аудит, https://courses.digitable.life/post/accessibility/09-testing-and-process/) и юзабилити-тест. Формально доступный интерфейс бывает мучительным: соответствие критериям — необходимое условие, а не достаточное.

На этапе макета большая часть барьеров закрывается ещё до всякого теста — контраст, размеры целей, состояния, порядок чтения: https://courses.digitable.life/post/ux-design/10-accessibility-in-design/. Подробная теория и практика проверок — в треке доступности (https://courses.digitable.life/post/accessibility/00-overview/), реализация в коде — во фронтенде (https://courses.digitable.life/post/frontend/00-overview/).

16. Совместная работа с разработкой

Юзабилити-тест — это точка, где дизайн и разработка либо начинают работать вместе, либо окончательно расходятся по окопам.

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

Пишите находки так, чтобы их можно было взять в работу. Тикет из отчёта — это:

# Пример находки в трекере
title: "P1, P2, P3, P5 не находят экспорт списка сделок"
observation: >
  4 из 5 участников искали экспорт в панели над таблицей 15-40 секунд,
  затем шли в поиск или в меню профиля. Экспорт находится в меню «Ещё»
  за иконкой из трёх точек в правом верхнем углу строки.  
evidence:
  - "запись P1, 04:12–04:51"
  - "запись P3, 06:30–07:15"
severity: 4          # блокирует ключевой сценарий
frequency: "4 / 5"
hypothesis: "Действие над всем списком ищут у списка, а не в меню строки"
proposed_fix: "Кнопка «Экспорт» в панели над таблицей, рядом с фильтрами"
owner: "дизайн — макет, фронтенд — верстка панели"
verify: "повторный тест того же задания, критерий: 5 из 5 за 20 секунд"

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

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

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

1. Макет — это один размер экрана, продукт — континуум. Даже идеальное совпадение на 1440 ничего не говорит про 1280, 1366 и окно в половину экрана. Правильная передача — это правила поведения (что сжимается, что переносится, что скрывается), а не координаты.
2. Реальные данные ломают композицию. Название компании в 60 символов, отрицательное число, пустой список, длинная немецкая локаль. Макет рисуют на удобных данных, и «пиксель в пиксель» просто консервирует эту удобную выдумку.
3. Токены и шкала важнее конкретных чисел. Если в системе шаг отступов 4, а в макете случайно оказалось 14, правильный результат — 16 из шкалы, а не 14 из макета (https://courses.digitable.life/post/ux-design/07-design-systems/).
4. Платформа имеет право на своё. Нативный контрол на iOS и Android выглядит по-разному, и это не дефект. Требовать одинакового рендера — тратить бюджет на борьбу с платформой.
5. Внимание — ограниченный ресурс. Час, потраченный на два пикселя, — это час, не потраченный на состояние ошибки, пустой экран или клавиатурный проход.

Что заменяет пиксель-перфект как цель: соответствие токенам и компонентам системы, полный набор состояний (https://courses.digitable.life/post/ux-design/08-interaction/), проверка на реальных данных и краевых случаях, поведение на промежуточных ширинах, доступность. Правильный вопрос ревью — не «совпало ли», а «ведёт ли себя так, как задумано, во всех состояниях и на всех размерах». Подробнее про формат передачи, аннотации и совместные ритуалы — в https://courses.digitable.life/post/ux-design/13-handoff-and-career/.

17. Вкусовщина и закономерности: где проходит граница

Честный разговор, которого обычно избегают. Часть решений в интерфейсе опирается на воспроизводимые закономерности, часть — на договорённость о стиле. Смешивать их — источник большинства бессмысленных споров.

Есть закономерности и данные: закон Фиттса (время попадания растёт с расстоянием и падает с размером цели — маленькие кнопки в дальних углах объективно хуже); закон Хика (время выбора растёт с числом равнозначных вариантов — меню на 40 пунктов без группировки медленное); пороги времени отклика 0.1 / 1 / 10 секунд; измеримые пороги контраста и размеров целей нажатия; закон Якоба (люди приносят ожидания из других продуктов); узнавание работает лучше припоминания, а иконка без подписи опознаётся плохо.

Вопрос стиля и договорённости: скругления углов, толщина линий, тени, «плоско или объёмно»; конкретный оттенок основного цвета при соблюдении контраста; иллюстрации, тон голоса, манера анимации; плотность интерфейса — она зависит от того, кто и как часто им пользуется, а не от «правильности».

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

18. Этика и данные

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

• Информированное согласие до начала: что будет происходить, что записывается, кто увидит запись, сколько она хранится, как её удалить. Согласие на видео с лицом — отдельно, по умолчанию оно не нужно. Право остановиться в любой момент без объяснений и без потери вознаграждения.
• Реальные данные участника — риск. В его рабочей системе будут клиенты, суммы, ФИО. Договоритесь заранее: этот экран не записываем, размываем или работаем в демо-аккаунте. Записи храним с ограниченным доступом и датой удаления, цитаты обезличиваем («P3», а не «Марина из ООО Ромашка»).
• Не превращайте тест в продажу. Если после сессии участнику предлагают купить, доверие следующих участников закончится очень быстро.
• Забота о состоянии человека. Участник, который «не справился», часто чувствует себя глупо. Задача ведущего — вернуть ему уверенность: «вы очень помогли, именно это мы и искали».

19. Ритм: как встроить тесты в процесс

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

«Четверг тестирования» (Краг). Раз в две недели, три участника: утро — сессии, обед — разбор, после обеда команда выбирает три правки до следующего раза. Никакого отчёта; главное свойство — предсказуемость, рекрут идёт фоном, и команда всегда знает, что материал будет.

RITE (Rapid Iterative Testing and Evaluation, Медлок и др., Microsoft Games User Research): правки вносятся между участниками, а не после раунда. Увидели блокер у первого — починили прототип к третьему — проверили. За один день можно снять несколько слоёв проблем. Требует, чтобы прототип менялся быстро, и потому отлично сочетается с дизайн-системой. Цикл всегда замыкается повторной проверкой того же задания по тому же критерию: правка, которую не перепроверили, — это надежда, а не результат.

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

Дальше это встраивается в общий ритм продуктовой команды — планирование, приоритеты, релизы: https://courses.digitable.life/post/product-management/00-overview/.

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

1. Тест без вопроса. «Покажем макет пользователям» — и потом никто не знает, что делать с результатом.
2. Задание, в котором есть ответ. Слова из интерфейса в тексте задания обесценивают сессию.
3. Автор макета ведёт сессию и защищает решения. Как минимум просите вести коллегу; как максимум — тренируйте нейтральность и пересматривайте свои записи со звуком: подсказки интонацией и «ага» слышно сразу.
4. Спор с участником. «Ну на самом деле это работает вот так» — после этой фразы данные закончились.
5. Выводы после первого участника. Один человек — гипотеза, а не находка. Исключение — потеря данных.
6. Проценты на пяти людях. «80% пользователей не справились» — при n=5 это «4 из 5».
7. Приоритизация по громкости. Кто ярче ругался, того и чиним. Нужны частота и серьёзность.
8. Отчёт вместо изменений. Тридцать слайдов, которые прочитали двое. Лучше — доска с находками и тикеты в общем трекере.
9. Проблемы прототипа записаны как проблемы дизайна. Составьте карту мёртвых зон заранее.
10. Тест только счастливого пути. Ошибки, пустые состояния и медленная сеть — самая урожайная часть сценариев (https://courses.digitable.life/post/ux-design/08-interaction/).
11. Один раунд на весь проект и однородная выборка. Найденное чинят, починенное перепроверяют; пять «соседей по опенспейсу» дают однородно оптимистичный результат.

Мини-итог

• Юзабилити-тест отвечает на один вопрос: справляется ли человек с задачей в нашем интерфейсе. Не «нравится», не «сколько процентов», не «нужен ли продукт».
• Задание — это ситуация с мотивацией и проверяемым результатом, без единого слова из интерфейса.
• «Пять пользователей» — разумный дефолт для формативного теста на сегмент и при итерациях, а не универсальная истина: разброс по данным Фолкнер от 55% до 99% найденных проблем.
• Главный навык модератора — молчать три секунды и возвращать вопрос участнику; записываем наблюдения, интерпретации помечаем как гипотезы и сводим в таблицу «находка × участник».
• Приоритет = частота × серьёзность, но единичная потеря данных чинится сразу.
• На маленькой выборке говорим «4 из 5», а не «80%»; для чисел нужны 20+ человек и доверительный интервал.
• Разработчик на двух сессиях полезнее отчёта на тридцать слайдов; в тикет идут наблюдение, запись, таймкод и критерий проверки.
• «Пиксель в пиксель» — не цель: цель в соответствии токенам, полном наборе состояний, поведении на реальных данных и промежуточных ширинах.
• Отделяйте закономерности (Фиттс, Хик, пороги контраста и отклика) от вкусовщины (скругления, оттенки, иллюстрации). Для первого — данные, для второго — владелец стиля.

Источники

• Jakob Nielsen, «Why You Only Need to Test with 5 Users» — исходная аргументация; читать вместе с критикой ниже.
• Laura Faulkner, «Beyond the five-user assumption: Benefits of increased sample sizes in usability testing», Behavior Research Methods, 2003 — эмпирическая проверка разброса на 60 участниках.
• Jared Spool, Will Schroeder, «Testing Web Sites: Five Users Is Nowhere Near Enough», CHI 2001.
• Steve Krug, «Rocket Surgery Made Easy» — практичная книга про тестирование своими силами, сценарии и демо-записи; его же «Don’t Make Me Think, Revisited» — про очевидность интерфейса.
• K. Anders Ericsson, Herbert Simon, «Protocol Analysis: Verbal Reports as Data» — теория «думай вслух».
• Jeff Sauro, James Lewis, «Quantifying the User Experience» — статистика для UX: доли, интервалы, размеры выборок; практические заметки — на MeasuringU.
• Tomer Sharon, «Validating Product Ideas» — среди прочего описание rainbow spreadsheet.
• NN/g: Usability Testing 101, 10 эвристик, шкала серьёзности проблем.
• Cathy Wharton et al., «The Cognitive Walkthrough Method: A Practitioner’s Guide», 1994; M. Medlock et al., «Using the RITE method to improve products», UPA 2002.
• ISO 9241-11:2018 — определение юзабилити; John Brooke, «SUS: A quick and dirty usability scale», 1996 — оригинал шкалы SUS.
• Optimal Workshop и Maze — инструменты для tree testing, card sorting и немодерируемых тестов; список меняется, принципы — нет.

Что дальше

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