Команда получает просьбу «сделать форму понятнее» и сразу выбирает средство: добавить подсказку, поменять подпись или переставить поля. Через спринт появляется новый экран, но никто не может точно сказать, какую трудность он устраняет. Пользователь останавливается на том же шаге, а разработчики поддерживают решение, принятое до проверки проблемы.
\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