![\"Маршрут](\"/assets/editorial/2022/user-research-2022-diagnosis-rollback.svg\")
Команда приносит на планирование готовый макет: переставить поле, добавить подсказку и выпустить изменение в ближайшем спринте. На вопрос «что сейчас не получается у человека?» звучит ответ «пользователи путаются». Источника нет. Неясно, где это наблюдали, что именно сделал человек и что команда приняла за причину.
\nЦена ошибки — не только потраченные часы. Команда может выпустить лишний элемент, усложнить экран и сохранить исходную преграду. После релиза она не сможет честно сказать, что изменилось: новая подсказка могла совпасть с сезонностью, другой версией трафика или просто не попасть в тот сценарий, где возникала трудность.
\nТезис: исследование пользовательской проблемы начинается с разделения уровней. Сначала зафиксируйте наблюдение и его источник. Затем назовите возможные объяснения. После этого сформулируйте гипотезу и способ её проверить. Решение — один из результатов проверки, а не исходная точка. Если связка не складывается, остановить фичу безопаснее, чем сделать предположение убедительнее.
\nФраза «люди не понимают форму, поэтому нужна всплывающая подсказка (tooltip)» смешивает несколько утверждений. «Поле осталось пустым» может быть наблюдаемым фактом, если известно, где это увидели. «Человек не понял назначение поля» — уже интерпретация. «Нужна всплывающая подсказка» — решение. Ни одно из следующих утверждений автоматически не следует из предыдущего.
\nНачните с глагола и контекста. Что человек сделал? На каком шаге? В каком состоянии экрана? Что система показала? Какой результат ожидался? Записывайте буквальный признак, а не диагноз. «Три карточки из учебной выборки сохранились без значения в обязательном поле» точнее, чем «пользователи не умеют заполнять форму». Объём и способ получения такой записи тоже важны: единичный просмотр не становится общей закономерностью.
\nИсточник нужен для повторной проверки. Им может быть заметка с согласованной сессии, запись обращения в поддержку, доступный аналитический сигнал или специально проведённый тест. Источник не добавляет факту репрезентативность сам по себе. Он только показывает, откуда взялось наблюдение и какие границы у него есть.
\nУдобно хранить разбор в шести блоках: observation, source, scope, interpretations, hypothesis и decision. Эти имена не требуют отдельного инструмента. Они задают порядок мышления и не позволяют спрятать решение внутри описания проблемы.
const caseNote = {\n observation: 'В учебной карточке поле "Срок" осталось пустым.',\n source: 'Учебный разбор прототипа, запись R-04.',\n scope: 'Один сценарий заполнения; это не оценка частоты.',\n interpretations: [\n 'Подпись не объясняет ожидаемый формат.',\n 'Поле появляется не в тот момент.',\n 'Значение не нужно для текущей задачи.'\n ],\n hypothesis: {\n condition: 'Если подпись не объясняет ожидаемый формат,',\n expected: 'участник попросит пояснение или остановится на этом поле.',\n falsifier: 'участник назовёт назначение и формат без подсказки.'\n },\n decision: {\n status: 'defer-solution',\n nextCheck: 'Проверить понимание подписи на прототипе без подсказки.'\n }\n};Пример учебный. Он не содержит интервью, продуктовой аналитики, персональных данных или результата реального теста. Запись R-04 — условный идентификатор. Код не запускает исследование и не вычисляет частотность. Он только показывает, как не смешивать то, что увидели, с тем, что пока предполагаем, и где записать отрицательный исход.
Важна и последовательность. Нельзя принять решение «выпустить подсказку», если нет ни наблюдения, ни источника. Нельзя назвать гипотезу подтверждённой, если опыт ещё не проведён. Можно заранее описать ожидаемый признак и условия, при которых гипотеза окажется неверной. Это делает следующий шаг проверяемым.
\n| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| «Надо сделать проще» | Решение подменило описание трудности | Попросить конкретный шаг, контекст и источник | Отложить макет и сформулировать вопрос |
| «Пользователь путается» | Наблюдение смешали с мотивом | Сверить буквальное действие и возможные альтернативы | Сохранить факт, не утверждать причину |
| Поле часто пустое | Неизвестны знаменатель, сценарий и обязательность | Разделить состояния формы и проверить источник сигнала | Не объявлять проблему общей без контекста |
| «Так попросили» | Запрос приняли за доказательство | Уточнить, кто, когда и в какой задаче это сказал | Назвать ограничение источника и задать вопрос |
| Нужно выпустить срочно | Операционное ограничение выдали за вывод исследования | Проверить обратимость и отдельно записать риск | Сделать минимальный обратимый шаг или остановить решение |
Допустим, в учебном прототипе человек не заполнил поле «Срок». Возможны разные причины: подпись непонятна, формат ожидается в другом виде, поле появляется слишком поздно или значение сейчас не нужно для его задачи. Один и тот же симптом допускает несколько объяснений. Если сразу добавить подсказку, команда проверит только собственную догадку.
\nСформулируйте проверку так, чтобы она различала варианты. Например: показать тот же прототип без подсказки и попросить человека выполнить задачу своим способом. Наблюдаемый критерий — не ответ на вопрос «понравился ли экран», а действие: смог ли человек назвать назначение поля, выбрать формат и понять, что произойдёт после сохранения. Если участник просит помощь, запишите момент и точную формулировку затруднения. Если не просит, это не доказывает, что проблема отсутствует во всех контекстах.
\nМожно выбрать другой метод. Существующий сигнал поддержки подходит для вопроса о повторяющихся обращениях, но не объясняет каждую причину. Лог показывает событие, но не мотив. Интервью помогает узнать контекст, но не измеряет частоту. Тест прототипа показывает выполнение конкретной задачи, но не гарантирует поведение в боевом контуре. Метод выбирают по вопросу, а не по привычке команды.
\nСлабую запись часто пытаются усилить деталями: придумывают цитату, добавляют процент, называют человека «типичным пользователем» или превращают один случай в тренд. Это не улучшает исследование. Такие детали нельзя проверить по исходному материалу, а решение получает ложный вес.
\nУчебные данные тоже должны оставаться учебными. Если пример нужен для объяснения структуры, прямо укажите его границу. Не называйте синтетическую карточку реальным участником. Не приписывайте макету эффект. Не сообщайте, что конверсия выросла, если в статье нет измерения. Корректное «неизвестно» полезнее точного числа без источника.
\nЕсть и отрицательный путь. Иногда изменение нужно выпустить по юридической, операционной или договорной причине, даже если пользовательская проблема не исследована. Это допустимое ограничение решения, но не доказательство потребности. Разделите две записи: почему выпуск обязателен и что ещё неизвестно о пользовательском опыте. После этого определите минимальный риск, обратимость и следующий способ узнать больше.
\nДо релиза отказ от необоснованного макета — это остановка или статус defer-solution, а не rollback. После релиза rollback означает вернуть предыдущее поведение или отключить изменение по заранее известному безопасному пути. В обоих случаях сохраните вопрос, источник, неопределённость и условие возврата. Остановите решение, если источник недоступен, если одну интерпретацию выдали за факт, если гипотеза не имеет отрицательного исхода или если опыт проверяет только вкус команды.
Остановка не должна превращаться в вечное ожидание идеального исследования. Задаче не нужен большой план: достаточно следующего малого опыта, который различает две причины, или честного статуса «пока неизвестно». Если такого опыта нет, кодировать решение рано. Если изменение уже выпущено и риск высок, сначала выберите обратимый откат с проверяемым критерием восстановления, а не необратимую перестройку экрана.
\ndefer-solution, а не «готово к разработке».Разделение уровней не делает источник качественным автоматически. Оно не устраняет смещение выборки (bias), не задаёт размер выборки и не заменяет согласие на участие, защиту персональных данных или правила хранения записей. Эти вопросы зависят от продукта, риска и выбранного метода.
\nНаблюдение поведения не равно объяснению мотива. Слова участника не равно измерение частоты. Сигнал аналитики не равно доказательство удобства. Даже повторяемый симптом не выбирает UI-решение без проверки контекста. Поэтому вывод статьи должен оставаться уже, чем исходный вопрос: «в этом сценарии обнаружен такой-то признак», а не «все пользователи сталкиваются с проблемой».
\nУчебный код выше также имеет узкую границу. Он показывает схему записи на литералах и не подключён к исследовательскому хранилищу, трекеру, аналитике или системе согласий. Его нельзя использовать как готовый процесс и нельзя считать запуском исследования. Боевое решение требует отдельной политики доступа, удаления, аудита и связи с первичными материалами.
\nРазбор готов к решению, когда в нём есть одна пользовательская задача, наблюдаемый симптом, доступный источник, границы источника, минимум две интерпретации, проверяемая гипотеза, метод и отрицательный исход. Для решения указаны обратимость и причина выбора. Для остановки указаны недостающий факт и следующий вопрос. Ни один учебный пример не выдан за результат реального исследования.
\nПроверка проста: другой инженер или дизайнер читает запись без устного пояснения и отвечает на три вопроса. Что произошло? Откуда это известно? Какой результат изменит решение? Если он видит только готовый макет и уверенное объяснение, проблема ещё не исследована. Если он может повторить путь от факта к следующему опыту, материал готов для обсуждения.
\n