Исследования пользователей: интервью, наблюдение, анализ данных

Форма выставления счёта. Шесть полей, ничего необычного. Аналитика показывает: до кнопки «Выставить счёт» доходит 46% тех, кто открыл экран. Команда собирается обсудить.

Дизайнер говорит, что форма визуально перегружена и нужно разбить её на два шага. Разработчик — что дело в валидации ИНН, она правда строгая. Продакт — что 46% это нормально, у всех так. Руководитель — что надо просто сделать кнопку заметнее. Через сорок минут спора принимается компромисс: разбить на два шага, кнопку покрасить, валидацию ослабить. Релиз через три недели. Конверсия становится 44%.

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

Эта статья — про то, как добывать такие фразы. Она открывает трек (https://courses.digitable.life/post/ux-design/00-overview/) намеренно: информационная архитектура, потоки, вайрфреймы, визуальный язык — это ответы. Исследование даёт вопросы, на которые они отвечают. Без него дизайн превращается в перебор вариантов, у которого нет критерия остановки.

1. Зачем это инженеру, а не только «исследователю»

В компаниях с отдельной ролью user researcher инженер редко ходит на интервью. Это дорогая ошибка. Стоимость исправления ошибки растёт по мере продвижения по циклу разработки — идея полувековой давности, качественно верная до сих пор, даже если конкретные множители из ранних работ Боэма спорны.

Второй аргумент прямее. Разработчик, который час смотрел, как бухгалтер вставляет адрес из 1С и получает ошибку валидации, напишет другой парсер — не потому, что ему поручили, а потому, что он видел. Это единственный известный способ передать контекст без потерь: пересказ в тикете теряет 90% того, что было в комнате.

Смежные роли делают ту же работу под другими именами: продакт называет это discovery (https://courses.digitable.life/post/product-management/01-discovery-and-research/), системный аналитик — выявлением требований (https://courses.digitable.life/post/systems-analysis/01-elicitation/). Методы общие, фокус разный: аналитик выясняет, что система должна делать, дизайнер — как человек будет с ней справляться.

2. Чего исследование не может

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

Люди не знают, почему делают то, что делают. Ричард Нисбетт и Тимоти Уилсон в обзоре «Telling More Than We Can Know» (Psychological Review, 1977) собрали эксперименты, где испытуемые уверенно объясняли причины своего выбора — и объяснения систематически не совпадали с реально действовавшим фактором. Мозг не имеет доступа к процессу принятия решения, только к результату, и достраивает правдоподобную историю. Следствие: вопрос «почему вы выбрали этот тариф?» даёт не причину, а сочинение на тему. Ценность в нём есть — это модель, которой человек пользуется, — но это не причинно-следственная информация.

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

Память искажает опыт систематически. Люди запоминают пик переживания и его конец, а не среднее и не длительность — эффект peak-end (Psychological Science, 1993). Пользователь, у которого сорок минут всё было мучительно, а в конце получилось, скажет «в целом нормально». И не соврёт.

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

3. Карта методов: две оси, четыре квадранта

Самая полезная классификация принадлежит Кристиану Рореру (NN/g). Две оси: что мы собираем — слова или поведение, и какого рода данные — качественные (почему) или количественные (сколько).

Читать карту нужно так: ни один квадрант не самодостаточен. Аналитика видит миллион человек, но не знает ни одного. Интервью знает человека, но не знает, сколько таких. Наблюдение видит настоящее поведение, но в единичных случаях. Опрос собирает много слов, а слова — самый ненадёжный материал из всех. Отсюда рабочая связка, к которой сходятся зрелые команды: количественное отвечает на «где и сколько», качественное — на «почему», наблюдение — на «что происходит на самом деле».

4. Исследование начинается не с метода, а с решения

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

# research-plan.yaml — умещается на страницу, иначе это не план, а декорация
decision: "Переделываем шаг ввода реквизитов или вкладываемся в автозаполнение по ИНН"
deadline: "решение 17 марта, значит данные нужны к 13 марта"
known: ["конверсия шага 46 процентов, стабильна полгода",
        "поле ИНН — самый частый источник ошибок валидации в логах"]
unknown: ["почему бросают именно здесь: не знают ИНН, не понимают формат или ищут в другом месте",
          "откуда вообще берут реквизиты в момент заполнения"]
methods:
  - { что: "запрос по событиям формы", зачем: "локализовать поле", объём: "90 дней" }
  - { что: "наблюдение на рабочем месте", зачем: "увидеть источник данных", объём: "4 человека" }
  - { что: "интервью после наблюдения", зачем: "понять модель и историю", объём: "8 человек" }
not_doing: ["опрос по базе: не ответит на «почему», а времени съест две недели"]
success_criteria: "называем три причины обрыва и оцениваем долю каждой хотя бы порядком величины"

Блок not_doing защищает от исследования, которое разрастается, потому что «раз уж мы всё равно говорим с людьми, спросим заодно про…». Заодно спросить можно один вопрос, а не восемь. И ещё одно правило планирования: анализ идёт параллельно полевой части. Расшифровывать восемь интервью в конце — надёжный способ потерять неделю и половину контекста.

5. Интервью

5.1 Главное правило: прошлое вместо будущего

Единственный надёжный материал в интервью — рассказ о конкретном случае, который уже произошёл. Всё остальное — оценки, предположения, вежливость.

Механика проста: если человек может ответить, не вспоминая, — вопрос плохой. Хороший заставляет лезть в память, иногда открывать почту или календарь; пауза перед ответом — признак, что вы спросили правильно.

Отдельная ловушка — вопрос про важность без цены. «Насколько для вас важна безопасность?» — все скажут «очень». «Вы бы согласились ради этого вводить код из СМС при каждом входе?» — ответы разъедутся. Настоящий приоритет виден только там, где за него надо чем-то заплатить: временем, деньгами, удобством.

5.2 Структура разговора

Шестьдесят минут — рабочий формат. Сорок пять — минимум, за который человек успевает перестать отвечать «правильно». Полтора часа — верх для большинства людей.

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

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

# guide.yaml — темы, а не сценарий; порядок подстраивается под собеседника
warmup:  ["Чем вы занимаетесь и как выглядит обычный день"]
context: ["Кто ещё участвует в выставлении счетов? Что делаете вы, что они?",
          "Какими программами пользуетесь? Покажите, что сейчас открыто"]
stories: ["Расскажите про последний счёт. С чего всё началось?",
          "Был случай, когда пришлось переделывать? Что случилось?",
          "Расскажите про самый неудобный счёт за последнее время"]
depth:   ["Вы сказали «пришлось лезть в 1С» — что вы там искали?",
          "Что произошло дальше?", "А если бы этого способа не было?"]
close:   ["О чём я не спросил, а стоило бы?", "Кто ещё делает это иначе, чем вы?"]
never_ask: ["нравится ли интерфейс", "стали бы вы пользоваться", "как бы вы это сделали"]

5.3 Как выглядит хорошая сессия изнутри

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

5.4 Разбор: как рушится интервью

Обобщённый фрагмент, который стоит прочитать дважды.

— Мы думаем сделать автоподстановку реквизитов по ИНН. Вам было бы удобно? — Ну да, наверное, удобно. — А если бы и адрес сам подставлялся? — Да, было бы отлично.

Что получено: ничего. Два вопроса, два вежливых «да», ноль фактов. Интервьюер выложил гипотезу на стол на первой минуте, участник понял, чего от него ждут, и подыграл. Хуже того — команда унесёт с совещания «пользователи подтвердили, что им нужна автоподстановка». Тот же участок, переигранный:

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

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

5.5 Два приёма из литературы

Метод критических инцидентов (Джон Фланаган, Psychological Bulletin, 1954) — просить рассказать не про типичный случай, а про запомнившийся крайний: самый удачный и самый провальный раз. Память хранит крайности лучше среднего, а крайние случаи очерчивают границы, в которых должен работать продукт.

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

5.6 Как записывать

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

6. Наблюдение: то, чего не бывает в рассказах

Интервью даёт модель человека о своей работе. Наблюдение даёт саму работу. Различие обычно шокирующее.

Дисциплинированная форма метода — контекстное исследование (contextual inquiry) Хью Байера и Карен Хольцблатт («Contextual Design», Morgan Kaufmann). Базовая метафора — мастер и подмастерье: вы не эксперт, приехавший оценивать, а ученик, пришедший смотреть, как работает мастер. Четыре принципа:

1. Контекст — наблюдать там, где работа происходит. Шум, телефон, второй монитор, коллега за спиной — это не помехи, это условия задачи.
2. Партнёрство — не интервью и не тест: вы вдвоём разбираетесь, как устроена работа. Прерывать можно, но чтобы понять, а не чтобы направить.
3. Интерпретация вслух — «правильно я понимаю, что этот файл открыт, потому что оттуда постоянно нужен номер договора?». Проверять догадки на месте дешевле, чем через неделю.
4. Фокус — у вас есть тема, всё остальное отпускаете, иначе за три часа узнаете про корпоратив и ничего про счета.

6.1 Разбор: почему форма «неудобная»

Вернёмся к форме из вступления и посмотрим, что дал каждый метод.

1. Ошибка сверху. Сообщение «проверьте правильность заполнения» без указания поля. Аналитика этого не покажет — с точки зрения событий человек просто нажал «отправить» и остался на странице. Видно только в наблюдении: он читает сообщение, перечитывает все поля сверху вниз дважды, потом закрывает вкладку. Чинится привязкой ошибки к полю и переводом фокуса на первое проблемное; про формулировки — https://courses.digitable.life/post/ux-design/09-microcopy/, про техническую сторону — https://courses.digitable.life/post/frontend/12-forms-and-validation/.

2. Поле ИНН. Здесь аналитика сильна: точно говорит, где обрыв, и даёт долю. Причину дало интервью: у ИП ИНН двенадцатизначный, а маска сделана под юрлицо. Ни один участник не сформулировал это сам — все говорили «оно не принимает мой номер».

3. Адрес. Чистая находка наблюдения. В рассказе человек «вводит адрес». В реальности копирует блок из другой системы вместе с переносами и индексом, вставляет и получает ошибку — а если валидатор режет по первому переносу, молча теряет часть данных. В интервью такое не всплывает никогда: человек не считает вставку из буфера отдельным действием, о котором стоит рассказывать.

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

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

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

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

7. Анализ данных: факты, которые уже есть

До того как звать людей, стоит вычерпать то, что уже лежит в компании. Это бесплатно и часто сразу сужает вопрос. Базовая вещь — воронка по шагам сценария (подробно про метрики UX — https://courses.digitable.life/post/ux-design/12-metrics/, про продуктовые — https://courses.digitable.life/post/product-management/02-metrics/).

-- Воронка шага «реквизиты»: где обрываются сессии
WITH steps AS (
    SELECT session_id,
        MAX(CASE WHEN event = 'invoice_step_opened' THEN 1 ELSE 0 END) AS opened,
        MAX(CASE WHEN event = 'field_focus' AND field = 'inn' THEN 1 ELSE 0 END) AS inn_focus,
        MAX(CASE WHEN event = 'field_valid' AND field = 'inn' THEN 1 ELSE 0 END) AS inn_ok,
        MAX(CASE WHEN event = 'invoice_submitted' THEN 1 ELSE 0 END) AS submitted
    FROM events
    WHERE ts >= now() - INTERVAL '90 days'
    GROUP BY session_id
)
SELECT SUM(opened) AS "открыли", SUM(inn_focus) AS "дошли до ИНН",
       SUM(inn_ok) AS "прошли ИНН", SUM(submitted) AS "отправили",
       ROUND(100.0 * SUM(inn_ok) / NULLIF(SUM(inn_focus), 0), 1) AS "процент по ИНН"
FROM steps;

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

// Событий должно хватать, чтобы восстановить сюжет сессии без записи экрана.
type FieldEvent = {
  event: 'field_focus' | 'field_valid' | 'field_invalid' | 'field_paste';
  field: string;
  attempt: number;     // какая по счёту попытка ввода в это поле
  dwellMs: number;     // «трудность» поля без сохранения содержимого
  errorCode?: string;  // какой валидатор сработал, а не текст сообщения
};

function trackField(el: HTMLInputElement, send: (e: FieldEvent) => void): void {
  let enteredAt = 0, attempt = 0;
  const dwell = () => performance.now() - enteredAt;

  el.addEventListener('focus', () => {
    enteredAt = performance.now();
    send({ event: 'field_focus', field: el.name, attempt: ++attempt, dwellMs: 0 });
  });
  // Вставка из буфера — сильный сигнал: данные приходят из другой системы
  el.addEventListener('paste', () =>
    send({ event: 'field_paste', field: el.name, attempt, dwellMs: dwell() }));
  el.addEventListener('blur', () => {
    const ok = el.checkValidity();
    // ВАЖНО: значение поля не отправляем никогда — только факт и код ошибки
    send({ event: ok ? 'field_valid' : 'field_invalid', field: el.name, attempt,
           dwellMs: dwell(), errorCode: ok ? undefined : el.dataset.errorCode });
  });
}

Комментарий про значение поля — не формальность: там персональные, а иногда и платёжные данные (https://courses.digitable.life/post/security/15-privacy-and-compliance/). Факта, длительности и кода ошибки достаточно, чтобы восстановить сюжет. Другие источники, которые уже оплачены: записи сессий (промежуточный жанр между аналитикой и наблюдением — настоящее поведение в масштабе, но спросить «что вы сейчас пытались сделать?» нельзя, смотреть надо глазами, а поля обязательно маскировать); логи внутреннего поиска — прямой список того, какими словами люди называют ваши сущности и чего не находят в навигации (https://courses.digitable.life/post/ux-design/03-information-architecture/), особенно запросы с нулевым результатом; обращения в поддержку — ценность не в отдельном тикете, а в частотном разборе формулировок и в переписках, где сотрудник объясняет обходной путь (каждый такой путь — ненаписанная функция); данные соседних систем — CRM и биллинг показывают последствия, которых фронтенд не видит: сколько счетов переделали, отменили, отправили в ручную обработку.

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

8. Триангуляция: как получить вывод, которому можно верить

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

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

9. Сколько людей и когда останавливаться

Для качественного исследования ориентир даёт работа Гэста, Банса и Джонсона (Field Methods, 2006): на однородной выборке 12 интервью дали 92% всех кодов, причём 73% появились уже в первых шести. Слова «однородная» и «узкая тема» здесь оба важны. Практический критерий — насыщение: останавливаемся, когда очередное интервью не приносит новых тем. Это считается буквально.

"""Насыщение: сколько новых кодов приносит каждое следующее интервью."""

def saturation_curve(sessions: list[set[str]]) -> list[tuple[int, int, int]]:
    """sessions — сессии, каждая это множество кодов (тем), отмеченных при разборе.
    Возвращает (номер сессии, новых кодов, всего кодов).
    Сложность: O(n * k) по времени, O(k) по памяти — n сессий, k различных кодов."""
    seen: set[str] = set()
    out = []
    for i, codes in enumerate(sessions, start=1):
        new = codes - seen
        seen |= codes
        out.append((i, len(new), len(seen)))
    return out


sessions = [
    {"реквизиты из письма", "маска ИНН", "переделка счёта"},
    {"реквизиты из письма", "скан вместо файла", "маска ИНН"},
    {"копирование из прошлого счёта", "маска ИНН", "переделка счёта"},
    {"реквизиты из письма", "скан вместо файла"},
    {"копирование из прошлого счёта", "клиент-физлицо"},
    {"реквизиты из письма", "маска ИНН"},
    {"копирование из прошлого счёта", "скан вместо файла"},
]
print([(n, new, total) for n, new, total in saturation_curve(sessions)])
# 1: +3 (3) · 2: +1 (4) · 3: +1 (5) · 4: +0 (5) · 5: +1 (6) · 6: +0 (6) · 7: +0 (6)

Три интервью подряд без новых тем — сигнал остановиться по этому сегменту. Слово «сегмент» решающее: бухгалтер, предприниматель-одиночка и оператор колл-центра дают три кривые насыщения, а не одну. Смешав их в один список, вы получите вечно растущий график и вывод «нужно ещё двадцать интервью». Для количественной части арифметика другая: погрешность доли при выборке n примерно 1 / sqrt(n) — на 100 ответах около 10 процентных пунктов, на 400 около 5, на 1000 около 3. Значит, разница «42% против 46%» на двухстах ответах не значит ничего. Введение в эту арифметику — MeasuringU Джеффа Сауро. И правило, экономящее больше всего времени: три человека раз в две недели лучше, чем двадцать раз в полгода — исследование ценно не отчётом, а тем, что успевает повлиять на решение.

10. Как исследование врёт

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

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

11. Опросы: почему это сложнее, чем кажется

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

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

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

12. От заметок к находкам

Сырые заметки бесполезны — их никто не прочитает. Задача анализа: превратить шесть часов разговоров в десяток утверждений, которыми можно пользоваться. Рабочая процедура — аффинити-группировка: каждый факт и каждая цитата выносятся на отдельный стикер, стикеры группируются по смыслу без заранее заданных категорий, и уже у групп появляются названия. Делать это надо вдвоём-втроём и обязательно с разработчиком: две пары глаз ловят разные группы, а участие в группировке заменяет чтение отчёта. Алгоритмически это ручная кластеризация с трудоёмкостью около O(n²) по числу стикеров, поэтому больше 300–400 за раз не берут: сначала группируют внутри каждой сессии, потом объединяют группы между сессиями.

Формат находки, который работает лучше всего, состоит из четырёх обязательных частей:

finding: "Реквизиты приходят готовым блоком из внешнего источника, а форма ждёт ручного ввода по полям"
evidence:
  observed: "6 из 8 участников вставляли данные из буфера, 4 — целым блоком"
  quote: "«Я стёр всё и набрал руками, раза три так было» (П3, 00:14:20)"
  data: "события field_paste на шаге реквизитов — 71 процент сессий"
scope: "затрагивает всех, кто получает реквизиты письмом; по CRM это около 60 процентов новых счетов"
implication: "нужен разбор вставленного блока, а не более строгая маска; при неудаче разбора — заполнить распознанное и подсветить остальное"
confidence: "высокая по причине, средняя по доле"

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

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

13. Исследование и разработка: что и как передавать

Здесь трек про UX смыкается с инженерной работой, и здесь же больше всего трения.

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

Находка — это ограничение, а не задание на пиксели. Хорошая передача звучит как «поле адреса принимает многострочную вставку с переносами и не теряет данные при частичном разборе», а не «сделайте поле шире». Первое — требование, проверяемое тестом; второе — решение, придуманное на ходу и не связанное с причиной.

Отсюда почти всегда спорная тема: «пиксель в пиксель» — плохая цель, и причины у этого технические.

• Макет описывает намерение при одном наборе условий. В макете название компании занимает строку, в базе оно в 900 символов; в макете сумма из шести цифр, в жизни из двенадцати. «Как в макете» не отвечает, что делать с этими случаями. «Название переносится максимум на две строки, дальше многоточие, полное значение — в подсказке» отвечает.
• Рендеринг не под контролем ни у кого. Версии браузеров, подстановка шрифтов, системный масштаб, зум 200%, пользовательские стили и размер шрифта в ОС легально меняют картинку. Интерфейс, совпадающий с макетом только при 100% в одном браузере, — сломанный, а не эталонный.
• Локализация и данные ломают ширины. Немецкий текст длиннее русского на 20–30%, арабский идёт справа налево.
• Пиксельная сверка съедает бюджет обсуждения. Час спора о четырёх пикселях отступа — это час, не потраченный на состояние ошибки, которого в макете вообще нет.

Правильная цель формулируется иначе: соответствие системе, а не картинке. Отступы берутся из шкалы токенов, цвета — из палитры, компонент — из библиотеки (https://courses.digitable.life/post/ux-design/07-design-systems/). Тогда «в макете 12, в коде 16» — не дефект вёрстки, а вопрос «какой шаг шкалы здесь правильный», решаемый за минуту. А дефектами считаются вещи, ломающие задачу пользователя: пропущенное состояние загрузки, потерянный фокус, нечитаемый контраст, необработанная ошибка. Разбор процесса передачи — в https://courses.digitable.life/post/ux-design/13-handoff-and-career/, состояния и обратная связь — в https://courses.digitable.life/post/ux-design/08-interaction/. Исследование помогает и в спорах о приоритетах: «это затрагивает 60% новых счетов, вот запрос» работает на планировании лучше, чем «пользователям неудобно», — не потому, что менеджеры бездушны, а потому, что им нужно чем-то обосновать выбор между двумя задачами.

14. Кого нет в вашей выборке

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

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

Что из этого следует для макетов — контраст, размеры целей, порядок фокуса, видимые состояния — в https://courses.digitable.life/post/ux-design/10-accessibility-in-design/. Техническая сторона подробно раскрыта в отдельном треке: https://courses.digitable.life/post/accessibility/00-overview/, особенно https://courses.digitable.life/post/accessibility/05-screen-readers/ и https://courses.digitable.life/post/accessibility/09-testing-and-process/. Здесь важно одно: кого не было в исследовании, того не будет и в дизайне, и никакая проверка контраста в конце этого не исправит.

15. Этика, согласие и персональные данные

Информированное согласие — не галочка, а понятное объяснение: что записываем, зачем, кто увидит, сколько храним, как отозвать. Устного согласия в начале звонка достаточно для внутреннего исследования, но зафиксировать его в записи нужно обязательно; на показ фрагментов вне команды требуется отдельное согласие. Данные участников — персональные данные: имя, должность, компания, голос, лицо, экран с рабочей почтой. Значит — минимизация, псевдонимизация в заметках (П1, П2, а не «Марина из Ромашки»), срок хранения и удаление по расписанию. В российской юрисдикции это 152-ФЗ, в европейской — GDPR; практическая сторона — https://courses.digitable.life/post/security/15-privacy-and-compliance/.

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

16. Где закономерность, а где вкусовщина

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

Слой первый: воспроизводимые закономерности. Их немного, они про моторику и восприятие, и они работают. Закон Фиттса (1954): время наведения растёт логарифмически с отношением расстояния к размеру цели — отсюда крупные кнопки, углы и края экрана как «бесконечно большие» цели, близость связанных действий. Закон Хика (1952): время выбора растёт логарифмически с числом равновероятных вариантов — отсюда группировка, а не просто «меньше пунктов»; закон про простой выбор из известных вариантов, а не про сканирование незнакомого меню. Эффекты позиции и выделения: первые и последние элементы списка запоминаются лучше, выделяющийся — лучше однородных. Пороги времени отклика: около 0,1 с — ощущение мгновенности, около 1 с — сохранение потока мысли, около 10 с — предел удержания внимания; эти числа стабильны десятилетиями и прямо диктуют, где нужен индикатор загрузки (https://courses.digitable.life/post/ux-design/08-interaction/).

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

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

И миф, который стоит похоронить лично: «семь плюс-минус два» пунктов в меню. Работа Миллера (1956) — про объём кратковременной памяти при удержании несвязанных элементов, а не про количество пунктов навигации, которые человек видит глазами и не обязан запоминать. Ограничивать меню семью пунктами «по Миллеру» некорректно; ограничивать по осмысленной группировке правильно, но обоснование другое. Отдельная оговорка: предпочтение и производительность расходятся. Люди регулярно называют «более приятным» вариант, на котором работали медленнее и с большим числом ошибок. Поэтому нельзя проектировать по опросам предпочтений и поэтому нужен юзабилити-тест с задачами (https://courses.digitable.life/post/ux-design/11-usability-testing/). NN/g сформулировали это резко: First Rule of Usability? Don’t Listen to Users — слушайте не то, что говорят, а смотрите, что делают.

17. Как сделать это привычкой, а не проектом

Исследование, которое проводится «когда будет время», не проводится никогда. Что работает:

• Ритм вместо больших раундов. Тереза Торрес в «Continuous Discovery Habits» (producttalk.org) предлагает еженедельный контакт с пользователями силами тройки «продакт + дизайнер + разработчик». Один разговор в неделю за год даёт полсотни интервью — больше, чем любой квартальный проект, и распределённо по моментам принятия решений.
• Постоянный доступ к людям. Узкое место любого исследования — рекрутинг; решается заранее: список согласившихся, договорённость с поддержкой о переадресации желающих, виджет «поговорить с командой» в продукте.
• Репозиторий находок. Отчёты в PDF умирают через неделю. Живёт база находок с тегами по разделам продукта и сегментам, где каждая запись — четыре поля из раздела 12 плюс ссылка на запись. Инструмент вторичен; первично то, что перед новой задачей туда заглядывают.
• Правило пятиминутки. На груминге у любой заметной задачи спрашивается: «что мы знаем о том, как это происходит сегодня?» Если ответ «ничего», задача не отменяется, но в неё закладываются два разговора. И каждое исследование однажды закрывается числом: метрика после релиза сдвинулась или нет (https://courses.digitable.life/post/ux-design/12-metrics/). Без этого исследование остаётся жанром, а не инструментом, и первым попадает под сокращение.

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

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

19. Мини-итог

1. Исследование начинается с решения, которое вы примете иначе, и заканчивается находкой в формате «наблюдение + свидетельство + масштаб + следствие».
2. Люди не знают причин своих действий, не предсказывают своё поведение и помнят пики и концовки. Поэтому: конкретное прошлое, а не будущее; «покажите», а не «расскажите»; поведение, а не оценка.
3. Данные отвечают «где и сколько», интервью — «почему», наблюдение — «что происходит на самом деле». Вывод одного метода — гипотеза; подтверждённый двумя — находка.
4. Критерий остановки — насыщение по сегменту, а не общее число участников: три сессии без новых тем достаточно.
5. Смещения лечатся только процедурой: гипотезы записаны заранее, сессию ведёт не автор, разбор вдвоём, доля проверяется запросом.
6. Разработчик на сессии полезнее отчёта. В разработку передаются ограничения и проверяемые требования, а не координаты: «пиксель в пиксель» расходует внимание на то, что не влияет на задачу пользователя.
7. Кого не позвали в исследование, того не окажется в дизайне — это относится и к пользователям вспомогательных технологий, и к тем, кто уже ушёл.

Источники

• Rob Fitzpatrick. The Mom Test — momtestbook.com; Steve Portigal. Interviewing Users — Rosenfeld Media
• Erika Hall. Just Enough Research — A Book Apart; Hugh Beyer, Karen Holtzblatt. Contextual Design, Morgan Kaufmann
• Teresa Torres. Continuous Discovery Habits — producttalk.org; Jeff Sauro, James Lewis. Quantifying the User Experience — measuringu.com
• Christian Rohrer. When to Use Which User-Experience Research Methods; NN/g. Diary Studies, First Rule of Usability
• R. Nisbett, T. Wilson. Telling More Than We Can Know, 1977; J. Flanagan. The Critical Incident Technique, 1954
• G. Guest, A. Bunce, L. Johnson. How Many Interviews Are Enough?, 2006
• P. Fitts. The information capacity of the human motor system, 1954; W. Hick. On the rate of gain of information, 1952; G. Miller. The Magical Number Seven, 1956
• ISO 9241-210:2019 «Human-centred design for interactive systems» — iso.org

Что дальше

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

Персоны и Jobs To Be Done: как понять, для кого и зачем