8 lines
22 KiB
JSON
8 lines
22 KiB
JSON
{
|
||
"index": 183,
|
||
"slug": "editorial-2022-12-practice-user-research",
|
||
"title": "Как проверить пользовательскую проблему до изменения интерфейса",
|
||
"excerpt": "Команда часто начинает с готового UI-решения, хотя проблема ещё не описана. Разбираем цепочку от наблюдения до проверяемого следующего шага и показываем, когда изменение нужно отложить.",
|
||
"contentHtml": "<p>Команда получает просьбу «сделать форму понятнее» и сразу выбирает средство: добавить подсказку, поменять подпись или переставить поля. Через спринт появляется новый экран, но никто не может точно сказать, какую трудность он устраняет. Пользователь останавливается на том же шаге, а разработчики поддерживают решение, принятое до проверки проблемы.</p>\n<p>Симптом здесь конкретный: задача содержит ответ, но не содержит наблюдаемого вопроса. Цена ошибки — не только лишняя разработка. Предположение закрепляется как факт, исходный контекст теряется, а результат нельзя сравнить с состоянием до изменения. Поэтому сначала нужно разделить наблюдение, возможную причину, способ проверки и решение.</p>\n<h2>Тезис: UI не является доказательством проблемы</h2>\n<p>Пользовательское исследование начинается не с выбора компонента, а с вопроса, на который команда должна получить ответ. Практическая формулировка выглядит так: «На каком шаге человек не может выполнить задачу, что он делает вместо ожидаемого действия и какое наблюдение отличит одну причину от другой?» Пока этих частей нет, обсуждение tooltip, маски или нового текста преждевременно.</p>\n<p>Это не формальность. Фраза «люди не понимают поле, поэтому нужен tooltip» склеивает действие, причину и решение. Из пропущенного поля ещё не следует, что виновата подпись: человек мог не иметь значения, не заметить обязательность, не доверять форме или столкнуться с ошибкой сохранения. Проблема должна оставаться открытой ровно настолько, чтобы проверка могла опровергнуть первую догадку.</p>\n<h2>Сначала зафиксируйте наблюдение</h2>\n<p>Наблюдение описывает то, что можно увидеть или открыть в исходной записи: шаг сценария, действие, текст сообщения, состояние интерфейса и контекст. Оно не должно содержать объяснение. «Поле “Номер договора” осталось пустым после отправки формы на мобильном экране» — наблюдение. «Пользователь не понял подпись» — уже интерпретация.</p>\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<h2>Отделите причину от гипотезы</h2>\n<p>После наблюдения запишите как минимум две возможные интерпретации. Для пустого поля это могут быть непонятное назначение, отсутствие нужного значения или проблема с фокусом и валидацией. Такой список не обязан быть полным. Его задача — не дать первой правдоподобной причине превратиться в установленный факт.</p>\n<p>Затем выберите гипотезу, которую можно опровергнуть. «Если подпись не объясняет назначение поля, то после нейтрального вопроса о задаче участники чаще назовут неверный смысл именно в текущем варианте» — проверяемое утверждение. «Новая подпись сделает форму удобнее» — обещание без условия и измеримого наблюдения. До проверки это не результат, а план узнать больше.</p>\n<h2>Учебный пример: карточка исследования</h2>\n<p>Ниже — самостоятельный пример на JavaScript. В нём нет данных реального продукта и нет выдуманных участников. Объект задаёт минимальный контракт: вопрос, наблюдение, источник, альтернативы, гипотезу, метод и критерий решения должны быть заполнены до обсуждения конкретного компонента.</p>\n<pre><code>const 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}</code></pre>\n<p>Функция проверяет готовность плана, а не истинность гипотезы. Она не читает аналитику и не сообщает, что подпись действительно виновата. После сессии нужно добавить результат: что сделал участник, какую формулировку использовал, где остановился и какая альтернативная причина осталась возможной. Иначе валидный объект будет только хорошо заполненным планом.</p>\n<h2>Выберите метод под вопрос</h2>\n<p>Один и тот же симптом требует разных проверок. Если нужно понять, где человек останавливается, наблюдайте выполнение задачи. Если нужно узнать, как он описывает свою практику, задавайте вопросы о реальном опыте. Если нужно оценить распространённость уже понятной проблемы, пригодится количественный источник. Интервью не заменяет проверку действия, а число отправок формы не объясняет мотив.</p>\n<p>В официальном Service Manual GOV.UK советуют сначала договориться о целях и исследовательских вопросах, превратить необоснованные предположения в вопросы и выбирать методы по тому, что команда хочет узнать. Для отдельного раунда там же предлагают заранее зафиксировать проблемы, проверяемые предположения и информацию, необходимую для следующего решения. Это совпадает с рабочим контрактом выше, но сама карточка — прикладной формат этой статьи, а не нормативный стандарт.</p>\n<figure><img src='/assets/editorial/2022/user-research-2022-evidence-flow.svg' alt='Схема перехода от наблюдения и источника к альтернативным причинам, гипотезе и следующей проверке с возвратом к исходной записи' loading='lazy' /><figcaption>Учебная схема: решение появляется после проверки цепочки; если источник или гипотеза не выдержали проверки, команда возвращается к вопросу, а не маскирует неизвестное новым UI.</figcaption></figure>\n<h2>Сделайте проверку воспроизводимой</h2>\n<p>Перед сессией зафиксируйте задачу участника, стартовое состояние, нейтральную инструкцию, критерий наблюдаемого результата и способ записи. Не подсказывайте ответ формулировкой вроде «найдите поле с непонятной подписью»: такая инструкция уже сообщает гипотезу. Наблюдатель записывает действие и цитату отдельно, чтобы позже не принять своё объяснение за слова участника.</p>\n<p>Если проверяется прототип, убедитесь, что сценарий проходит от начала до конца, а нужные состояния доступны участнику. Запишите версию прототипа и условия запуска. Для работы с людьми нужны согласие и правила хранения заметок; в примере эти процессы не реализованы. Официальное руководство GOV.UK отдельно указывает на доступность прототипа, проверку сценариев заранее, учёт потребностей участников и согласие.</p>\n<p>Критерий успеха задаётся до просмотра результата. Например, команда может решить: «открываем обсуждение подписи, только если участники не могут объяснить назначение поля в текущем варианте и новая формулировка устраняет именно это затруднение». Порог, состав участников и решение о выпуске зависят от проекта. Не выдавайте учебное правило за универсальную статистическую границу.</p>\n<h2>Отрицательный путь: когда изменение нужно отложить</h2>\n<p>Источник может оказаться недоступен, запись — неполной, а гипотеза — неотличимой от альтернатив. В этом случае результатом является не «ничего не узнали», а точная граница: проблема наблюдалась, причина не подтверждена, следующий источник или опыт назначен. Остановите переход к реализации, сохраните исходную запись и не переписывайте её под уже выбранный компонент.</p>\n<p>Если новая подпись улучшила объяснение поля в прототипе, это ещё не доказывает, что она снизит число незавершённых отправок в реальном потоке. Понадобится отдельная проверка поведения и заранее определённый способ сравнения. Если тест не подтвердил гипотезу, не называйте его неудачным: он сэкономил работу на изменении, для которого не было достаточной причины.</p>\n<h2>Порядок действий</h2>\n<ol><li>Выпишите из задачи все утверждения и отделите действие, причину, пожелание и готовое решение.</li><li>Запишите наблюдаемый симптом: кто, на каком шаге и в каком контексте сделал не то, что ожидалось.</li><li>Приложите открываемый источник и укажите, что именно в нём проверяется.</li><li>Сформулируйте вопрос исследования без названия будущего компонента.</li><li>Запишите минимум две возможные причины, затем выберите гипотезу с условием и ожидаемым наблюдением.</li><li>Выберите метод под вопрос: действие проверяйте действием, распространённость — количественным источником.</li><li>До проверки зафиксируйте сценарий, стартовое состояние, версию прототипа, критерий и правила записи.</li><li>Проведите нейтральную проверку и разделите в заметках действие, цитату и интерпретацию.</li><li>Сохраните результат, неопределённость и оставшиеся альтернативы; не добавляйте вымышленные проценты.</li><li>Примите решение: изменить интерфейс, собрать ещё один источник или отложить UI до появления доказательства.</li></ol>\n<h2>Ограничения метода</h2>\n<p>Карточка исследования не делает выборку репрезентативной и не заменяет продуктовую аналитику, проверку доступности или согласие участников. Единичное действие показывает сигнал, но не масштаб проблемы. Результат интервью описывает рассказ человека, но не автоматически подтверждает его поведение. У каждого вывода должны быть источник, контекст и граница применимости.</p>\n<p>Метод также не обязан привести к изменению интерфейса. Иногда выясняется, что проблема находится в данных, правах, тексте ошибки или бизнес-правиле. Если внешний срок требует выпустить изменение, это ограничение проекта, а не доказательство пользовательской причины. Зафиксируйте его отдельно и не переписывайте наблюдение под обязательный релиз.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Карточка готова к обсуждению изменения, если другой инженер может открыть источник, пересказать наблюдение без добавленной причины, назвать минимум одну альтернативу, повторить следующий опыт и объяснить, какое наблюдение изменит решение. В тексте нет утверждения «пользователи хотят X», когда источник показывает только действие Y. Есть явный stop: что делать при недоступном источнике, отрицательном результате или несовпадении версии прототипа.</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>"
|
||
}
|