{
  "index": 183,
  "slug": "editorial-2022-12-practice-user-research",
  "title": "Как проверить пользовательскую проблему до изменения интерфейса",
  "excerpt": "Команда часто начинает с готового UI-решения, хотя проблема ещё не описана. Разбираем цепочку от наблюдения до проверяемого следующего шага и показываем, когда изменение нужно отложить.",
  "contentHtml": "<p>Команда получает просьбу «сделать форму понятнее» и сразу выбирает средство: добавить подсказку, поменять подпись, переставить поля. Через спринт появляется новый экран, но никто не может точно сказать, какую трудность он устраняет. Пользователь по-прежнему останавливается на том же шаге, а разработчики тратят время на поддержку решения, которое приняли до проверки проблемы.</p>\n<p>Симптом здесь простой: задача содержит ответ, но не содержит наблюдаемого вопроса. Цена ошибки — не только лишняя разработка. Команда закрепляет предположение как факт, теряет исходный контекст и не может проверить результат после изменения. Поэтому пользовательское исследование нужно начинать с разделения утверждений: что увидели, откуда узнали, как это объясняем и что ещё надо проверить.</p>\n<h2>Тезис: сначала зафиксируйте проблему, потом выбирайте интерфейс</h2>\n<p>Рабочая запись состоит из пяти уровней. Наблюдение описывает действие или высказывание без объяснения причины. Источник показывает, где это наблюдение можно сверить. Интерпретация предлагает возможное объяснение. Гипотеза связывает объяснение с ожидаемым результатом проверки. Решение или следующий опыт появляется только после этих уровней.</p>\n<p>Такой порядок не превращает исследование в бюрократию. Он защищает от подмены. Фраза «люди не понимают поле, поэтому нужен tooltip» склеивает три разных шага. «Не понимают» требует источника. «Поэтому» выдаёт интерпретацию за доказанную причину. «Нужен tooltip» уже закрывает пространство альтернатив. Разделение возвращает вопрос: какое наблюдение подтвердит или опровергнет это объяснение?</p>\n<h2>Механизм: evidence не должен менять уровень сам</h2>\n<table><caption>Разбор типичного симптома</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>«Нужно сделать проще»</td><td>Решение записали вместо пользовательской трудности</td><td>Найти конкретный шаг, на котором возникает препятствие</td><td>Отложить макет и сформулировать вопрос</td></tr><tr><td>«Пользователь путается»</td><td>Наблюдение смешали с мотивом</td><td>Отделить буквальное действие от объяснений</td><td>Сохранить действие и добавить альтернативы</td></tr><tr><td>«Добавим подсказку»</td><td>Гипотезу приняли за готовый ответ</td><td>Назвать ожидаемое изменение поведения</td><td>Проверить прототип или другой обратимый вариант</td></tr><tr><td>«Так попросили»</td><td>Авторитет заменил источник</td><td>Уточнить контекст и доступность записи</td><td>Ограничить силу вывода</td></tr><tr><td>«Выпустим быстро»</td><td>Скорость подменяет критерий успеха</td><td>Проверить, что будет считаться улучшением</td><td>Выбрать малый шаг с понятным откатом</td></tr></tbody></table>\n<p>Источник не обязан быть числом. Им может быть запись согласованного наблюдения, обращение в поддержку, результат тестовой сессии или артефакт, доступный команде. Но слова «все знают» источником не являются. Без контекста нельзя понять, кто видел ситуацию, в каком сценарии и что именно произошло. Один случай может быть важным сигналом, но он не доказывает частотность и не описывает всех пользователей.</p>\n<p>Интерпретация должна сохранять неопределённость. «Поле оставили пустым, потому что подпись непонятна» — слишком сильная формулировка, если зафиксировано только пустое поле. Надёжнее написать: «Поле оставили пустым; возможная причина — непонятная подпись, но возможны и другие причины». После этого гипотеза становится проверяемой: «Если подпись мешает понять назначение поля, участники будут чаще правильно объяснять его назначение в варианте с новой подписью». Это ещё не результат и не обещание эффекта.</p>\n<h2>Конкретный пример: карточка evidence в коде</h2>\n<p>Ниже — учебный пример на JavaScript. Он не подключён к продукту, не читает аналитику и не описывает реальных участников. Модель полезна как минимальный контракт для записи: нельзя добавить наблюдение без источника, принять решение до гипотезы или стереть исходную запись при откате.</p>\n<pre><code>const 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 &amp;&amp;\n    record.source &amp;&amp;\n    record.interpretation &amp;&amp;\n    record.hypothesis &amp;&amp;\n    record.nextCheck\n  );\n}\n\nif (!canPlan(evidence)) {\n  throw new Error('Нужны observation, source, interpretation, hypothesis и nextCheck');\n}</code></pre>\n<p>Поле <code>decision</code> здесь намеренно равно <code>defer-solution</code>. Оно не означает, что работу отменили навсегда. Оно означает, что команда не выдаёт выбранный интерфейс за доказанный ответ. Следующий шаг должен узнавать больше, а не маскировать нехватку данных. Если проверка подтвердит гипотезу, команда сравнит варианты. Если опровергнет, она сохранит время на неправильный патч.</p>\n<h2>Что делать, если доказательство не складывается</h2>\n<p>Отрицательный путь важен не меньше положительного. Источник может оказаться недоступен. Наблюдение может не отличаться от общей оценки. Гипотеза может не содержать условия, при котором она окажется неверной. В каждом случае остановите переход к реализации. Сохраните исходное наблюдение, явно запишите неизвестное и назначьте способ получить недостающий контекст.</p>\n<p>Rollback означает отмену решения, а не удаление неудобного свидетельства. Если команда уже выбрала подсказку, но не может связать её с проверяемой проблемой, отложите подсказку и вернитесь к карточке evidence. Не переписывайте наблюдение так, чтобы оно оправдывало выбранный компонент. Иначе процесс создаёт красивую историю вместо знания.</p>\n<figure><img src=\"/assets/editorial/2022/user-research-2022-evidence-flow.svg\" alt=\"Схема перехода от наблюдения и источника к интерпретации, гипотезе и следующей проверке с возвратом к исходной записи\" loading=\"lazy\" /><figcaption>Учебная схема: решение появляется после проверки цепочки evidence; при разрыве связи команда возвращается к вопросу, а не маскирует неизвестное новым UI.</figcaption></figure>\n<h2>Порядок действий</h2>\n<ol><li>Выпишите из задачи все утверждения и разделите действия, причины, пожелания и решения.</li><li>Оставьте буквальное наблюдение: что произошло, на каком шаге и в каком контексте.</li><li>Добавьте источник, который другой член команды может открыть и проверить.</li><li>Запишите две или больше возможных интерпретации. Не выбирайте первую как факт.</li><li>Сформулируйте гипотезу с условием и ожидаемым наблюдением.</li><li>Выберите следующий опыт, который может подтвердить или опровергнуть гипотезу.</li><li>До результата оставьте решение обратимым или установите статус <code>defer-solution</code>.</li><li>После проверки обновите карточку: сохраните результат, границы вывода и решение, которое действительно следует из evidence.</li></ol>\n<h2>Ограничения метода</h2>\n<p>Эта схема не выбирает метод исследования автоматически. Вопрос о понимании текста может потребовать проверки удобства, вопрос о причине ухода — другого источника и другого контекста. Один артефакт не даёт репрезентативности, не оценивает размер выборки и не доказывает влияние на конверсию. Учебный объект в примере не заменяет согласие участников, правила хранения данных и требования к приватности.</p>\n<p>Не переносите единичное действие на всю аудиторию. Не называйте лог доказательством без владельца, определения события и контекста. Не добавляйте выдуманные цитаты, проценты и результаты, чтобы запись выглядела убедительнее. Если продукт обязан изменить экран по внешнему требованию, зафиксируйте это как ограничение. Обязательное решение всё равно не становится результатом исследования.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Карточка готова к обсуждению изменения, когда другой человек может открыть источник, отличить наблюдение от интерпретации, назвать условие, при котором гипотеза неверна, и повторить следующий опыт по записи. В тексте нет утверждения «пользователи хотят X», если источник показывает только действие Y. Есть явный отрицательный путь: что команда делает при недоступном источнике или опровергнутой гипотезе. До выполнения этих условий обсуждайте вопрос и следующий опыт, а не детали компонента.</p>\n<p>Практическая проверка занимает один проход по ближайшей задаче с готовым UI-ответом. Уберите решение из первой строки. Найдите наблюдение и источник. Если их нет, результат уже полезен: команда обнаружила, что проблема не подтверждена. Если они есть, добавьте альтернативу и обратимый следующий шаг. Готовность измеряется не уверенностью формулировки, а тем, можно ли проверить переход от наблюдения к действию.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.gov.uk/service-manual/user-research/plan-user-research-for-your-service\" target=\"_blank\" rel=\"noopener noreferrer\">GOV.UK Service Manual: Plan user research for your service</a> — официальное руководство предлагает начинать с исследовательских вопросов, превращать предположения в вопросы и выбирать метод по тому, что нужно узнать.</li><li><a href=\"https://www.gov.uk/service-manual/user-research/plan-round-of-user-research\" target=\"_blank\" rel=\"noopener noreferrer\">GOV.UK Service Manual: Plan a round of user research</a> — официальное руководство связывает цели раунда с проверяемыми предположениями, проблемами и решением о следующем шаге.</li></ul>"
}