{
  "index": 182,
  "slug": "editorial-2022-12-mechanism-user-research",
  "title": "Как не принять догадку о пользователе за основание для интерфейса",
  "excerpt": "Практический контракт для user research: отделяем наблюдение от его смысла, проверяем гипотезу и откладываем UI-решение, пока цепочка evidence не выдержит проверку.",
  "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> превращает интерпретацию в условие, которое можно подтвердить или опровергнуть. Например: «если люди не понимают назначение поля, то на прототипе без подсказки они будут задавать вопрос или выбирать неверный вариант». Гипотеза не равна задаче «добавить tooltip». Она задаёт, что нужно узнать и какое наблюдение изменит решение.</p>\n<table><caption>Границы между evidence и решением</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 и production-эффект</td><td>Выбрать опыт</td></tr><tr><td>Решение</td><td>Обратимое изменение</td><td>Подтверждённую пользу</td><td>Проверить outcome</td></tr></tbody></table>\n<h2>Пример: решение не перепрыгивает через гипотезу</h2>\n<p>Ниже — учебная модель переходов. Она не проводит интервью, не подключается к аналитике и не создаёт данные о реальных людях. Её задача — не дать функции записать план эксперимента до появления интерпретации и гипотезы. В production этот код нельзя считать системой хранения исследований.</p>\n<pre><code>function planExperiment(record, nextExperiment) { if (!record.interpretation || !record.hypothesis) return { kind: 'decision-rejected' }; return { kind: 'experiment-planned', decision: 'defer-solution', nextExperiment }; }</code></pre>\n<p>Если <code>source</code> пуст, запись наблюдения должна завершиться отказом, а не созданием карточки с неизвестным происхождением. Если вызвать <code>planExperiment</code> раньше гипотезы, результатом должен быть <code>decision-rejected</code>. После добавления интерпретации и гипотезы модель может вернуть <code>defer-solution</code> с описанием следующего опыта. Это всё ещё план. Он не означает, что опыт проведён.</p>\n<p>В записи должны различаться статусы «хотим узнать», «проверили», «получили сигнал» и «приняли решение». Смешивание статусов создаёт ложную уверенность. Локальная проверка контракта полезна только для порядка переходов. Она не оценивает качество исследования.</p>\n<figure><img src='/assets/editorial/2022/user-research-2022-evidence-contract.svg' alt='Контракт учебной evidence-модели: observation требует source, interpretation требует записи, hypothesis требует interpretation, experiment требует hypothesis, rollback возвращает предыдущее состояние' loading='lazy' /><figcaption>Схема показывает учебные переходы записи. Она не изображает реальных участников, исследовательскую сессию или product analytics.</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>Мнение приняли за evidence</td><td>Уточнить контекст высказывания</td><td>Назвать источник и ограничение</td></tr><tr><td>«Проверим макет»</td><td>Метод выбран раньше цели</td><td>Сформулировать вопрос</td><td>Выбрать метод под вопрос</td></tr><tr><td>«Тест прошёл»</td><td>План приняли за результат</td><td>Проверить участников и сигнал</td><td>Разделить план и outcome</td></tr><tr><td>«Данных мало»</td><td>Неопределённость скрыли</td><td>Проверить обратимость и цену ошибки</td><td>Уменьшить изменение или сделать rollback</td></tr></tbody></table>\n<h2>Порядок работы</h2>\n<ol><li>Возьмите утверждение из задачи и уберите готовое решение. Оставьте проблему, которую нужно подтвердить.</li><li>Запишите наблюдаемое действие без объяснения мотива. Укажите экран, сценарий, данные и момент сбоя.</li><li>Прикрепите источник, который другой человек может открыть или проверить. Запишите, чего источник не показывает.</li><li>Добавьте альтернативную интерпретацию. Не выбирайте одну только потому, что она ведёт к удобному компоненту.</li><li>Сформулируйте гипотезу как условие с ожидаемым наблюдением. Не используйте «точно» и «всегда» без подтверждения.</li><li>Выберите небольшой опыт, который отвечает на вопрос, а не просит оценить выбранный макет. Запишите, какой результат изменит решение.</li><li>Проверьте отрицательный путь: нет source, нет interpretation, нет гипотезы, источник недоступен или опыт проверяет только вкус.</li><li>Если связка не выдерживает проверку, верните статус <code>defer-solution</code>. Сохраните вопрос и источник, отмените необоснованный переход к интерфейсу.</li></ol>\n<h2>Rollback и границы</h2>\n<p>Rollback не стирает неудобное evidence. Он отменяет решение, которое не связано с наблюдением проверяемой гипотезы. Снимок состояния возвращает запись к моменту до синтетического изменения: можно снять ошибочный план или убрать UI-вариант. Исходный источник остаётся доступным, если правила хранения позволяют его сохранять.</p>\n<p>Контракт не спасает от слабого источника. Одно наблюдение может оказаться случайным. Гипотеза может проверять не ту группу людей. Локальный тест не оценивает recruitment, доступность интерфейса, размер выборки, смещение исследователя или юридические требования. Эти вопросы требуют отдельного процесса и владельца.</p>\n<p>Не превращайте поля записи в бюрократию для каждого изменения. Низкорисковый текстовый патч и дорогая перестройка сервиса имеют разную цену ошибки. Но чем дороже откат, тем опаснее фраза без источника. Если выпуск обязателен по операционной или правовой причине, назовите это ограничением. Не выдавайте вынужденный выпуск за подтверждённую пользовательскую пользу.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Переход к решению готов, если проверяющий без автора может ответить: что наблюдали; где это зафиксировано; какие объяснения рассматриваются; какая гипотеза будет опровергнута конкретным сигналом; что команда сделает при каждом исходе. Должно быть понятно и то, какой результат ещё не получен. Если в карточке есть только макет и слово «понятнее», готовности нет.</p>\n<p>Удалите из записи решение и проверьте, остаётся ли понятна исходная проблема. Затем уберите гипотезу и спросите, может ли команда назвать следующий опыт без выбора компонента. Если смысл исчезает после удаления одного поля, уровни склеены. Вернитесь к наблюдению, зафиксируйте неизвестное и не увеличивайте точность искусственно.</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/how-user-research-improves-service-design' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: User research for government services</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>"
}