8 lines
19 KiB
JSON
8 lines
19 KiB
JSON
{
|
||
"index": 182,
|
||
"slug": "editorial-2022-12-mechanism-user-research",
|
||
"title": "Как проверить пользовательскую проблему до изменения интерфейса",
|
||
"excerpt": "Разбираем цепочку от наблюдения до решения: как отделить факт от объяснения, выбрать проверку под вопрос и не принять готовый UI за доказательство проблемы.",
|
||
"contentHtml": "<p>Типичная задача звучит так: «сделать кнопку заметнее, потому что пользователи её не видят». Макет уже приложен, оценка разработки готова, а исходное утверждение никто не может открыть. После релиза кнопку меняют, но команда не знает, исчезла ли трудность: люди могли не понимать термин, не иметь права на действие, потерять данные в форме или вообще не доходить до экрана. Цена ошибки — не только один спринт. В продукте закрепляется решение без критерия, а следующий спор снова начинается с мнений.</p>\n<p>Начните не с компонента, а с проверяемого вопроса. Разделите наблюдение, источник, интерпретацию, гипотезу и решение. Такой порядок не доказывает, что интерфейс станет лучше, но не даёт выдать догадку за пользовательский факт. Следующий шаг должен уменьшать конкретную неизвестность и оставаться обратимым, пока доказательств мало.</p>\n<h2>Механизм: пять уровней одной записи</h2>\n<p><strong>Наблюдение</strong> описывает действие в контексте: человек оставил обязательное поле пустым, прервал действие после сообщения об ошибке или спросил о назначении элемента. Наблюдение не содержит мотива. Фраза «человек не понял поле» уже объясняет поведение и потому не является чистым наблюдением.</p>\n<p><strong>Источник</strong> позволяет другому члену команды сверить запись: это может быть заметка исследовательской сессии, обращение в поддержку, согласованный лог или другой доступный артефакт. Наличие источника не доказывает частотность, репрезентативность или причину. Оно отвечает только на вопросы «откуда взялась запись?» и «в каком контексте её можно читать?».</p>\n<p><strong>Интерпретация</strong> связывает наблюдение с возможным объяснением. Она должна сохранять неопределённость: «пустое поле может быть связано с термином, порядком полей или отсутствием нужных данных». Альтернативы важны: если сразу назвать мотив установленным, команда потеряет часть проверки.</p>\n<p><strong>Гипотеза</strong> превращает интерпретацию в условие с ожидаемым сигналом. Например: «если подпись поля мешает понять его назначение, то в варианте с новой подписью участники чаще правильно объяснят, что произойдёт после отправки». Это ещё не результат. Гипотеза не равна задаче «добавить подсказку».</p>\n<p><strong>Решение</strong> выбирает следующий опыт или изменение только после первых четырёх уровней. Оно должно содержать критерий отката: какой сигнал подтвердит гипотезу, какой её ослабит и что команда сделает в обоих случаях. Метод исследования выбирают под вопрос, а не под уже выбранный макет. Именно такой порядок рекомендует Service Manual GOV.UK: сначала согласовать вопросы и предположения, затем определить подход и исследовательские активности.</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>Готовый UI и эффект выпуска</td><td>Выбрать опыт</td></tr><tr><td>Решение</td><td>Обратимый следующий шаг</td><td>Подтверждённую пользу</td><td>Проверить исход</td></tr></tbody></table>\n<h2>Пример: контракт не пропускает раннее решение</h2>\n<p>Ниже — учебная модель записи на JavaScript. Она не проводит интервью, не подключается к аналитике и не создаёт данные о реальных людях. Её задача — сделать порядок переходов видимым: без наблюдения и источника запись отклоняется, без интерпретации и гипотезы план не появляется.</p>\n<pre><code>function planNextStep(record) {\n if (!record.observation || !record.source) {\n return { kind: 'rejected', reason: 'observation-needs-source' };\n }\n\n if (!record.interpretation || !record.hypothesis || !record.nextCheck) {\n return { kind: 'rejected', reason: 'hypothesis-is-incomplete' };\n }\n\n return {\n kind: 'planned',\n decision: 'defer-solution',\n nextCheck: record.nextCheck,\n };\n}\n\nconst card = {\n observation: 'Обязательное поле осталось пустым',\n source: 'session-note-17',\n interpretation: 'Причина пока не установлена',\n hypothesis: 'Новая подпись изменит понимание назначения поля',\n nextCheck: 'Сравнить объяснение поля в двух вариантах прототипа',\n};\n\nconsole.log(planNextStep(card).decision); // defer-solution\nconsole.log(planNextStep({ ...card, source: '' }).reason); // observation-needs-source\nconsole.log(planNextStep({ ...card, hypothesis: '' }).reason); // hypothesis-is-incomplete</code></pre>\n<p>Фикстура возвращает <code>defer-solution</code>, потому что команда пока планирует проверку, а не объявляет подсказку правильным ответом. Последние две строки показывают отрицательные пути. Пустой <code>source</code> не превращается в карточку с неизвестным происхождением. Пустая <code>hypothesis</code> не позволяет перепрыгнуть от наблюдения к UI.</p>\n<p>Для рабочей системы понадобятся схема хранения, права доступа, журнал изменений и правила удаления данных. В примере их нет намеренно: локальный контракт проверяет только порядок полей и не оценивает качество рекрутинга, формулировок или результатов исследования.</p>\n<figure><img src='/assets/editorial/2022/user-research-2022-evidence-contract.svg' alt='Учебная схема: observation требует source, interpretation уточняет возможные причины, hypothesis задаёт ожидаемый сигнал, experiment следует после hypothesis, rollback возвращает решение к исходному вопросу' loading='lazy' /><figcaption>Схема показывает порядок учебной записи. Она не изображает реальных участников, исследовательскую сессию или данные продукта.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</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>Отложить UI и написать гипотезу</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<ol><li>Возьмите утверждение из задачи и уберите готовое решение. Оставьте проблему, которую нужно подтвердить.</li><li>Запишите наблюдаемое действие без объяснения мотива: что произошло, на каком экране, в каком сценарии и в какой момент.</li><li>Прикрепите источник, который другой член команды может открыть и проверить. Укажите, чего источник не показывает.</li><li>Запишите минимум две возможные интерпретации. Не выбирайте первую только потому, что она ведёт к удобному компоненту.</li><li>Сформулируйте гипотезу как условие с ожидаемым наблюдением и способом её ослабить.</li><li>Выберите небольшой опыт под вопрос. В GOV.UK Service Manual отдельная исследовательская итерация должна иметь ясные цели, проблематику, предположения и решение, которое нужно принять после результата.</li><li>Проверьте отрицательный путь: нет источника, источник недоступен, нет гипотезы, выбранный метод проверяет только вкус или решение необратимо.</li><li>До результата оставьте изменение обратимым. После проверки сохраните наблюдение, сигнал, границы вывода и решение, которое действительно следует из записи.</li></ol>\n<h2>Откат и границы метода</h2>\n<p>Откат отменяет решение, а не удаляет неудобное доказательство. Если команда уже выбрала подсказку, но не может связать её с проверяемой проблемой, снимите UI-вариант и вернитесь к карточке. Не переписывайте наблюдение так, чтобы оно оправдывало компонент: иначе процесс создаёт красивую историю вместо знания.</p>\n<p>Контракт не спасает от слабого источника. Одно наблюдение может оказаться случайным. Гипотеза может проверять не ту группу людей. Локальная проверка не оценивает доступность интерфейса, размер выборки, смещение исследователя, согласие участников или правила хранения персональных данных. Эти вопросы требуют отдельного метода, владельца и проверки.</p>\n<p>Не превращайте поля записи в бюрократию для каждого текстового изменения. Небольшой обратимый патч и перестройка сервиса имеют разную цену ошибки. Но чем дороже откат, тем опаснее фраза без источника. Если выпуск обязателен по операционной или правовой причине, назовите это ограничением. Вынужденное изменение не становится результатом исследования.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Запись готова к обсуждению изменения, если проверяющий без автора может ответить: что наблюдали; где это зафиксировано; какие объяснения рассматриваются; какой сигнал ослабит гипотезу; какой следующий опыт даст этот сигнал; что команда сделает при каждом исходе. Должно быть понятно и то, какой результат ещё не получен.</p>\n<p>Сделайте контрольный проход по ближайшей задаче с готовым UI-ответом. Уберите решение из первой строки. Найдите наблюдение и источник. Если их нет, зафиксируйте, что проблема пока не подтверждена. Если они есть, добавьте альтернативу и обратимый следующий шаг. Готовность измеряется не уверенностью формулировки, а тем, можно ли повторить переход от наблюдения к действию.</p>\n<h2>Проверяемые источники</h2>\n<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><li><a href='https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: Learning about users and their needs</a> — отделяет пользовательскую потребность и проблему от возможного решения и требует проверять предположения исследованием.</li></ul>"
|
||
}
|