![\"Схема](\"/assets/editorial/2022/user-research-2022-evidence-flow.svg\")
Команда получает просьбу «сделать форму понятнее» и сразу выбирает средство: добавить подсказку, поменять подпись, переставить поля. Через спринт появляется новый экран, но никто не может точно сказать, какую трудность он устраняет. Пользователь по-прежнему останавливается на том же шаге, а разработчики тратят время на поддержку решения, которое приняли до проверки проблемы.
\nСимптом здесь простой: задача содержит ответ, но не содержит наблюдаемого вопроса. Цена ошибки — не только лишняя разработка. Команда закрепляет предположение как факт, теряет исходный контекст и не может проверить результат после изменения. Поэтому пользовательское исследование нужно начинать с разделения утверждений: что увидели, откуда узнали, как это объясняем и что ещё надо проверить.
\nРабочая запись состоит из пяти уровней. Наблюдение описывает действие или высказывание без объяснения причины. Источник показывает, где это наблюдение можно сверить. Интерпретация предлагает возможное объяснение. Гипотеза связывает объяснение с ожидаемым результатом проверки. Решение или следующий опыт появляется только после этих уровней.
\nТакой порядок не превращает исследование в бюрократию. Он защищает от подмены. Фраза «люди не понимают поле, поэтому нужен tooltip» склеивает три разных шага. «Не понимают» требует источника. «Поэтому» выдаёт интерпретацию за доказанную причину. «Нужен tooltip» уже закрывает пространство альтернатив. Разделение возвращает вопрос: какое наблюдение подтвердит или опровергнет это объяснение?
\n| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| «Нужно сделать проще» | Решение записали вместо пользовательской трудности | Найти конкретный шаг, на котором возникает препятствие | Отложить макет и сформулировать вопрос |
| «Пользователь путается» | Наблюдение смешали с мотивом | Отделить буквальное действие от объяснений | Сохранить действие и добавить альтернативы |
| «Добавим подсказку» | Гипотезу приняли за готовый ответ | Назвать ожидаемое изменение поведения | Проверить прототип или другой обратимый вариант |
| «Так попросили» | Авторитет заменил источник | Уточнить контекст и доступность записи | Ограничить силу вывода |
| «Выпустим быстро» | Скорость подменяет критерий успеха | Проверить, что будет считаться улучшением | Выбрать малый шаг с понятным откатом |
Источник не обязан быть числом. Им может быть запись согласованного наблюдения, обращение в поддержку, результат тестовой сессии или артефакт, доступный команде. Но слова «все знают» источником не являются. Без контекста нельзя понять, кто видел ситуацию, в каком сценарии и что именно произошло. Один случай может быть важным сигналом, но он не доказывает частотность и не описывает всех пользователей.
\nИнтерпретация должна сохранять неопределённость. «Поле оставили пустым, потому что подпись непонятна» — слишком сильная формулировка, если зафиксировано только пустое поле. Надёжнее написать: «Поле оставили пустым; возможная причина — непонятная подпись, но возможны и другие причины». После этого гипотеза становится проверяемой: «Если подпись мешает понять назначение поля, участники будут чаще правильно объяснять его назначение в варианте с новой подписью». Это ещё не результат и не обещание эффекта.
\nНиже — учебный пример на JavaScript. Он не подключён к продукту, не читает аналитику и не описывает реальных участников. Модель полезна как минимальный контракт для записи: нельзя добавить наблюдение без источника, принять решение до гипотезы или стереть исходную запись при откате.
\nconst evidence = {\n observation: 'Обязательное поле осталось пустым',\n source: 'session-note-17',\n interpretation: 'Причина пока не установлена',\n hypothesis: 'Если подпись неясна, новая подпись изменит понимание поля',\n nextCheck: 'Показать два варианта подписи и попросить объяснить назначение поля',\n decision: 'defer-solution'\n};\n\nfunction canPlan(record) {\n return Boolean(\n record.observation &&\n record.source &&\n record.interpretation &&\n record.hypothesis &&\n record.nextCheck\n );\n}\n\nif (!canPlan(evidence)) {\n throw new Error('Нужны observation, source, interpretation, hypothesis и nextCheck');\n}Поле decision здесь намеренно равно defer-solution. Оно не означает, что работу отменили навсегда. Оно означает, что команда не выдаёт выбранный интерфейс за доказанный ответ. Следующий шаг должен узнавать больше, а не маскировать нехватку данных. Если проверка подтвердит гипотезу, команда сравнит варианты. Если опровергнет, она сохранит время на неправильный патч.
Отрицательный путь важен не меньше положительного. Источник может оказаться недоступен. Наблюдение может не отличаться от общей оценки. Гипотеза может не содержать условия, при котором она окажется неверной. В каждом случае остановите переход к реализации. Сохраните исходное наблюдение, явно запишите неизвестное и назначьте способ получить недостающий контекст.
\nRollback означает отмену решения, а не удаление неудобного свидетельства. Если команда уже выбрала подсказку, но не может связать её с проверяемой проблемой, отложите подсказку и вернитесь к карточке evidence. Не переписывайте наблюдение так, чтобы оно оправдывало выбранный компонент. Иначе процесс создаёт красивую историю вместо знания.
\ndefer-solution.Эта схема не выбирает метод исследования автоматически. Вопрос о понимании текста может потребовать проверки удобства, вопрос о причине ухода — другого источника и другого контекста. Один артефакт не даёт репрезентативности, не оценивает размер выборки и не доказывает влияние на конверсию. Учебный объект в примере не заменяет согласие участников, правила хранения данных и требования к приватности.
\nНе переносите единичное действие на всю аудиторию. Не называйте лог доказательством без владельца, определения события и контекста. Не добавляйте выдуманные цитаты, проценты и результаты, чтобы запись выглядела убедительнее. Если продукт обязан изменить экран по внешнему требованию, зафиксируйте это как ограничение. Обязательное решение всё равно не становится результатом исследования.
\nКарточка готова к обсуждению изменения, когда другой человек может открыть источник, отличить наблюдение от интерпретации, назвать условие, при котором гипотеза неверна, и повторить следующий опыт по записи. В тексте нет утверждения «пользователи хотят X», если источник показывает только действие Y. Есть явный отрицательный путь: что команда делает при недоступном источнике или опровергнутой гипотезе. До выполнения этих условий обсуждайте вопрос и следующий опыт, а не детали компонента.
\nПрактическая проверка занимает один проход по ближайшей задаче с готовым UI-ответом. Уберите решение из первой строки. Найдите наблюдение и источник. Если их нет, результат уже полезен: команда обнаружила, что проблема не подтверждена. Если они есть, добавьте альтернативу и обратимый следующий шаг. Готовность измеряется не уверенностью формулировки, а тем, можно ли проверить переход от наблюдения к действию.
\nКоманда получает просьбу «сделать форму понятнее» и сразу выбирает средство: добавить подсказку, поменять подпись или переставить поля. Через спринт появляется новый экран, но никто не может точно сказать, какую трудность он устраняет. Пользователь останавливается на том же шаге, а разработчики поддерживают решение, принятое до проверки проблемы.
\nСимптом здесь конкретный: задача содержит ответ, но не содержит наблюдаемого вопроса. Цена ошибки — не только лишняя разработка. Предположение закрепляется как факт, исходный контекст теряется, а результат нельзя сравнить с состоянием до изменения. Поэтому сначала нужно разделить наблюдение, возможную причину, способ проверки и решение.
\nПользовательское исследование начинается не с выбора компонента, а с вопроса, на который команда должна получить ответ. Практическая формулировка выглядит так: «На каком шаге человек не может выполнить задачу, что он делает вместо ожидаемого действия и какое наблюдение отличит одну причину от другой?» Пока этих частей нет, обсуждение tooltip, маски или нового текста преждевременно.
\nЭто не формальность. Фраза «люди не понимают поле, поэтому нужен tooltip» склеивает действие, причину и решение. Из пропущенного поля ещё не следует, что виновата подпись: человек мог не иметь значения, не заметить обязательность, не доверять форме или столкнуться с ошибкой сохранения. Проблема должна оставаться открытой ровно настолько, чтобы проверка могла опровергнуть первую догадку.
\nНаблюдение описывает то, что можно увидеть или открыть в исходной записи: шаг сценария, действие, текст сообщения, состояние интерфейса и контекст. Оно не должно содержать объяснение. «Поле “Номер договора” осталось пустым после отправки формы на мобильном экране» — наблюдение. «Пользователь не понял подпись» — уже интерпретация.
\n| Запись | Что она показывает | Чего она не доказывает | Следующий шаг |
|---|---|---|---|
| Поле пустое в записи отправки | Где возникло отклонение от сценария | Почему значение не введено | Проверить экран и контекст ввода |
| Цитата участника «я не знаю, что сюда писать» | Как человек объясняет затруднение | Частотность проблемы у всей аудитории | Сопоставить слова с действием в задаче |
| Сессия с прототипом новой подписи | Что произошло в конкретном тесте | Эффект в реальном потоке | Зафиксировать сценарий и сравнить варианты |
| Обращения в поддержку за период | Повторяющийся сигнал в канале поддержки | Причину без текста и контекста обращения | Отобрать записи и сформулировать вопрос |
| Готовый макет с подсказкой | Предложенный способ изменения | Наличие пользовательской проблемы | Вернуться к наблюдаемому симптому |
У наблюдения должен быть источник, который другой член команды может открыть: запись сессии, обезличенное обращение, событие аналитики с определением или снимок состояния. Один случай может быть ценным сигналом, но не показывает частотность. Связка «все знают» источником не является: из неё нельзя восстановить участника, сценарий и момент события.
\nПосле наблюдения запишите как минимум две возможные интерпретации. Для пустого поля это могут быть непонятное назначение, отсутствие нужного значения или проблема с фокусом и валидацией. Такой список не обязан быть полным. Его задача — не дать первой правдоподобной причине превратиться в установленный факт.
\nЗатем выберите гипотезу, которую можно опровергнуть. «Если подпись не объясняет назначение поля, то после нейтрального вопроса о задаче участники чаще назовут неверный смысл именно в текущем варианте» — проверяемое утверждение. «Новая подпись сделает форму удобнее» — обещание без условия и измеримого наблюдения. До проверки это не результат, а план узнать больше.
\nНиже — самостоятельный пример на JavaScript. В нём нет данных реального продукта и нет выдуманных участников. Объект задаёт минимальный контракт: вопрос, наблюдение, источник, альтернативы, гипотезу, метод и критерий решения должны быть заполнены до обсуждения конкретного компонента.
\nconst study = {\n question: 'Понимают ли люди назначение поля до отправки формы?',\n context: 'мобильная форма договора',\n observation: {\n action: 'отправка формы',\n symptom: 'поле contractNumber пустое',\n source: 'support-case-17'\n },\n alternatives: [\n 'подпись не объясняет назначение',\n 'у человека нет номера под рукой',\n 'ошибка фокуса скрывает обязательность'\n ],\n hypothesis: {\n condition: 'если причина в подписи',\n expected: 'участник не объяснит назначение поля без подсказки'\n },\n method: {\n name: 'moderated usability test',\n task: 'заполнить форму по нейтральному сценарию'\n },\n decisionRule: 'дообсудить вариант только после записи результата'\n};\n\nfunction readyForCheck(record) {\n return Boolean(\n record.question &&\n record.context &&\n record.observation?.action &&\n record.observation?.symptom &&\n record.observation?.source &&\n record.alternatives?.length >= 2 &&\n record.hypothesis?.condition &&\n record.hypothesis?.expected &&\n record.method?.name &&\n record.method?.task &&\n record.decisionRule\n );\n}\n\nif (!readyForCheck(study)) {\n throw new Error('Карточка не готова к проверке');\n}Функция проверяет готовность плана, а не истинность гипотезы. Она не читает аналитику и не сообщает, что подпись действительно виновата. После сессии нужно добавить результат: что сделал участник, какую формулировку использовал, где остановился и какая альтернативная причина осталась возможной. Иначе валидный объект будет только хорошо заполненным планом.
\nОдин и тот же симптом требует разных проверок. Если нужно понять, где человек останавливается, наблюдайте выполнение задачи. Если нужно узнать, как он описывает свою практику, задавайте вопросы о реальном опыте. Если нужно оценить распространённость уже понятной проблемы, пригодится количественный источник. Интервью не заменяет проверку действия, а число отправок формы не объясняет мотив.
\nВ официальном Service Manual GOV.UK советуют сначала договориться о целях и исследовательских вопросах, превратить необоснованные предположения в вопросы и выбирать методы по тому, что команда хочет узнать. Для отдельного раунда там же предлагают заранее зафиксировать проблемы, проверяемые предположения и информацию, необходимую для следующего решения. Это совпадает с рабочим контрактом выше, но сама карточка — прикладной формат этой статьи, а не нормативный стандарт.
\n
Перед сессией зафиксируйте задачу участника, стартовое состояние, нейтральную инструкцию, критерий наблюдаемого результата и способ записи. Не подсказывайте ответ формулировкой вроде «найдите поле с непонятной подписью»: такая инструкция уже сообщает гипотезу. Наблюдатель записывает действие и цитату отдельно, чтобы позже не принять своё объяснение за слова участника.
\nЕсли проверяется прототип, убедитесь, что сценарий проходит от начала до конца, а нужные состояния доступны участнику. Запишите версию прототипа и условия запуска. Для работы с людьми нужны согласие и правила хранения заметок; в примере эти процессы не реализованы. Официальное руководство GOV.UK отдельно указывает на доступность прототипа, проверку сценариев заранее, учёт потребностей участников и согласие.
\nКритерий успеха задаётся до просмотра результата. Например, команда может решить: «открываем обсуждение подписи, только если участники не могут объяснить назначение поля в текущем варианте и новая формулировка устраняет именно это затруднение». Порог, состав участников и решение о выпуске зависят от проекта. Не выдавайте учебное правило за универсальную статистическую границу.
\nИсточник может оказаться недоступен, запись — неполной, а гипотеза — неотличимой от альтернатив. В этом случае результатом является не «ничего не узнали», а точная граница: проблема наблюдалась, причина не подтверждена, следующий источник или опыт назначен. Остановите переход к реализации, сохраните исходную запись и не переписывайте её под уже выбранный компонент.
\nЕсли новая подпись улучшила объяснение поля в прототипе, это ещё не доказывает, что она снизит число незавершённых отправок в реальном потоке. Понадобится отдельная проверка поведения и заранее определённый способ сравнения. Если тест не подтвердил гипотезу, не называйте его неудачным: он сэкономил работу на изменении, для которого не было достаточной причины.
\nКарточка исследования не делает выборку репрезентативной и не заменяет продуктовую аналитику, проверку доступности или согласие участников. Единичное действие показывает сигнал, но не масштаб проблемы. Результат интервью описывает рассказ человека, но не автоматически подтверждает его поведение. У каждого вывода должны быть источник, контекст и граница применимости.
\nМетод также не обязан привести к изменению интерфейса. Иногда выясняется, что проблема находится в данных, правах, тексте ошибки или бизнес-правиле. Если внешний срок требует выпустить изменение, это ограничение проекта, а не доказательство пользовательской причины. Зафиксируйте его отдельно и не переписывайте наблюдение под обязательный релиз.
\nКарточка готова к обсуждению изменения, если другой инженер может открыть источник, пересказать наблюдение без добавленной причины, назвать минимум одну альтернативу, повторить следующий опыт и объяснить, какое наблюдение изменит решение. В тексте нет утверждения «пользователи хотят X», когда источник показывает только действие Y. Есть явный stop: что делать при недоступном источнике, отрицательном результате или несовпадении версии прототипа.
\nМинимальная проверка — взять ближайшую задачу с уже предложенным UI и убрать решение из первой строки. Если остаются только «сделать проще» и ссылка без контекста, работа ещё не готова к макету. Если найдено наблюдение, добавьте альтернативы и обратимый способ проверки. Готовность измеряется не уверенностью формулировки, а тем, может ли другой человек воспроизвести переход от наблюдения к действию.
\n