{
  "index": 86,
  "slug": "editorial-2025-08-mechanism-tool-ux-research",
  "title": "UX внутреннего инструмента: как превратить наблюдение в проверяемое решение",
  "excerpt": "Разбираем, как отделить действие коллеги от интерпретации, связать наблюдение с решением и остановить работу, если согласие, сценарий или ссылка на evidence не выдерживают проверки.",
  "contentHtml": "<p>Команда получает просьбу «сделать внутреннюю форму удобнее» и сразу обсуждает новую кнопку. Симптом кажется ясным, но в задаче нет исходного действия: неизвестно, где человек остановился, что уже видел и какой следующий шаг пытался выполнить. Через неделю решение нельзя связать с исходным материалом, а коллега снова обходит тот же экран.</p>\n<p>У внутреннего инструмента те же инженерные свойства, что у внешнего сервиса: роли, сценарии, состояния, ошибки и стоимость задержки. Поэтому UX-разбор должен передавать в разработку не удачную цитату, а цепочку, которую другой человек сможет открыть и перепроверить: граница данных → нейтральная задача → observation → code → theme → decision → следующий сценарий. Сильнее всего здесь не формулировка решения, а возможность остановиться до него.</p>\n<h2>Сначала вопрос, потом интерфейсный ответ</h2>\n<p>Рабочий вопрос описывает неизвестное, а не желаемый компонент. «Почему исполнитель не называет следующий шаг после чтения статуса?» можно проверить. «Нужна кнопка “Связаться с владельцем”» уже сужает исследование и подталкивает участника подтвердить идею. Если причина в термине, правах доступа или регламенте, такая кнопка только замаскирует сбой.</p>\n<p>Начните с одного маршрута. Например, исполнитель открывает карточку заявки на доступ, проверяет статус <code>processing</code> и должен понять, кому задать следующий вопрос. Исходное состояние и критерий окончания фиксируются заранее. Успехом может быть названный следующий шаг, но это ещё не означает, что интерфейс понятен всем, работает быстро или нравится участнику.</p>\n<p>Цель раунда должна отвечать на три вопроса: какое поведение нужно понять, какую гипотезу проверить и какое решение потребуется принять после наблюдения. Такой порядок согласуется с официальным руководством GOV.UK: сначала определяются проблемы, предположения и информация, необходимая для следующего решения, а уже потом выбирается метод исследования.</p>\n<h2>Четыре слоя доказательства</h2>\n<p><strong>Observation</strong> — наблюдаемое действие, пауза или вопрос в конкретном сценарии. «Статус прочитан, курсор остановился у поля owner, затем задан вопрос о следующем ответственном» можно проверить по записи или заметке. «Человеку непонятен интерфейс» уже является интерпретацией.</p>\n<p><strong>Code</strong> — короткая метка для повторяющейся детали. <code>owner-unclear</code> говорит, что в данном маршруте не найден следующий владелец. Она не показывает частоту, не устанавливает причину и не переносит результат на другие роли. Рядом хранится <code>uncertainty</code>: что именно наблюдение не установило.</p>\n<p><strong>Theme</strong> — вопрос, объединяющий несколько кодов. Наблюдения про поле owner и термин processing могут образовать тему <code>next-step-visibility</code>: видит ли исполнитель действие после текущего состояния. Тема помогает выбрать следующий эксперимент, но не выбирает кнопку за команду.</p>\n<p><strong>Decision</strong> — запись о следующем решении. В ней есть ссылки на observation id, кандидатное изменение, текущий статус утверждения и сопоставимый follow-up. Пока эффект не измерен, корректный claim — «гипотеза» или <code>not-established</code>. Если ссылка ведёт на несуществующую заметку, decision нельзя считать прослеживаемым.</p>\n<figure><img src='/assets/editorial/2025/tool-ux-research-2025-observation-decision-matrix.svg' alt='Матрица показывает, как два наблюдения переходят в коды и тему видимости следующего шага; при нарушенной границе согласия, ведущем сценарии или отсутствующей ссылке решение останавливается' loading='lazy' /><figcaption>Схема связывает наблюдение, код, тему и ворота решения. Она объясняет структуру доказательства, но не показывает частоту проблемы и не доказывает эффект изменения.</figcaption></figure>\n<h2>Граница данных начинается до первой заметки</h2>\n<p>Информированное согласие — не формальность, которую можно добавить после встречи. В нём участнику объясняют цель исследования, собираемые данные, наблюдателей, способ записи, использование результатов, срок хранения и возможность остановиться. GOV.UK отдельно указывает, что согласие нужно получать и у людей, которые работают в той же организации.</p>\n<p>Выберите допустимый тип материала до сессии. Если согласованы только обезличенные заметки, запись экрана не становится разрешённой «для удобства анализа». Имя, команда, номер заявки и содержимое экрана могут раскрывать человека даже без явного поля с ФИО. Обезличивание снижает риск, но не отменяет правила доступа, хранения и удаления.</p>\n<p>При отзыве согласия нужно остановить сессию и действовать по утверждённой политике хранения. Руководство GOV.UK описывает удаление собранных исследовательских материалов в таком случае, однако конкретные сроки, владельца данных и юридические основания определяет организация. Поэтому в decision log достаточно зафиксировать STOP и владельца процесса; нельзя придумывать локальную процедуру по статье из другой юрисдикции.</p>\n<h2>Воспроизводимый пример записи и проверки</h2>\n<p>Ниже учебный пример без реальных людей, заявок и результатов исследования. Сохраните его как <code>decision-check.mjs</code> и выполните командой <code>node decision-check.mjs</code>. Проверка не анализирует качество интерфейса: она только ловит сломанные ссылки и запрещает переход к decision без подтверждённого согласия.</p>\n<pre><code>const record = {\n  consent: {\n    status: 'confirmed',\n    allowedEvidence: ['de-identified-note']\n  },\n  scenario: {\n    id: 'access-request-v1',\n    task: 'Найти статус заявки и следующий вопрос',\n    success: 'Назвать следующий шаг и адресата'\n  },\n  observations: [\n    {\n      id: 'observation-owner-v1',\n      action: 'Прочитан status; курсор остановился у owner',\n      question: 'Кто отвечает после отправки?',\n      code: 'owner-unclear',\n      uncertainty: 'Не установлены причина и частота'\n    },\n    {\n      id: 'observation-status-v1',\n      action: 'Термин processing прочитан без перехода к действию',\n      code: 'status-hidden',\n      uncertainty: 'Не установлено, знаком ли термин другим ролям'\n    }\n  ],\n  decision: {\n    observationIds: ['observation-owner-v1', 'observation-status-v1'],\n    theme: 'next-step-visibility',\n    candidateChange: 'Проверить блок со статусом и следующим шагом',\n    claim: 'not-established',\n    nextScenario: 'Повторить ту же задачу без подсказки'\n  }\n};\n\nfunction validateDecision(input) {\n  const ids = new Set(input.observations.map(({ id }) =&gt; id));\n  const missing = input.decision.observationIds.filter((id) =&gt; !ids.has(id));\n  const stop = [];\n  if (input.consent.status !== 'confirmed') stop.push('consent-not-confirmed');\n  if (missing.length) stop.push('decision-not-traceable-to-evidence');\n  return { ok: stop.length === 0, missing, stop };\n}\n\nconsole.log(validateDecision(record));\nconsole.log(validateDecision({\n  ...record,\n  decision: { ...record.decision, observationIds: ['missing-observation-v1'] }\n}));\n// { ok: true, missing: [], stop: [] }\n// { ok: false, missing: ['missing-observation-v1'],\n//   stop: ['decision-not-traceable-to-evidence'] }</code></pre>\n<p>Код проверяет контракт, а не правдивость самой заметки. Проверяющий всё равно открывает исходный материал, сверяет роль и состояние экрана, проверяет разрешённый тип evidence и читает uncertainty. Вторая строка вывода — обязательная отрицательная ветка: неизвестный id не исправляется угадыванием по похожему тексту.</p>\n<h2>Как не перепутать код с диагнозом</h2>\n<p>Одна остановка у поля owner допускает несколько объяснений. Владелец может быть скрыт, термин может быть новым, у роли может не быть права на просмотр или следующий шаг может находиться в другом регламенте. Codebook делает записи сопоставимыми, но не выбирает между этими гипотезами.</p>\n<p>Полезно хранить рядом четыре значения: <code>action</code> — что произошло, <code>context</code> — в каком состоянии, <code>code</code> — какую деталь отмечаем, <code>uncertainty</code> — чего пока не знаем. Если в поле action появляется «растерялся», замените его на наблюдаемую паузу, повторное чтение, вопрос или обходной путь. Интерпретацию перенесите в theme и пометьте как гипотезу.</p>\n<div class='table-scroll'><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>Есть ли исходный вопрос и нейтральный prompt?</td><td>Вернуться к задаче без названия будущего control</td></tr><tr><td>В заметке написано «пользователь запутался»</td><td>Факт смешан с интерпретацией</td><td>Можно ли описать действие без оценки?</td><td>Переписать action и добавить uncertainty</td></tr><tr><td>Decision ссылается на неизвестный id</td><td>Источник потерялся при пересказе встречи</td><td>Открывается ли каждая ссылка из decision log?</td><td>Остановить hand-off и восстановить evidence</td></tr><tr><td>Для анализа нужна запись экрана</td><td>Тип evidence расширили после согласия</td><td>Разрешены ли запись, наблюдатели и хранение?</td><td>Не использовать запись до новой проверки границы</td></tr><tr><td>После правки сказали «стало лучше»</td><td>Follow-up не сопоставим с исходным</td><td>Совпадают ли задача, состояние и критерий успеха?</td><td>Повторить маршрут или оставить claim not-established</td></tr><tr><td>Две заметки стали «проблемой всех»</td><td>Потеряна роль и граница выборки</td><td>Какие роли и условия реально наблюдались?</td><td>Сузить вывод и собрать следующий материал</td></tr></tbody></table></div>\n<h2>Отрицательная ветка должна приводить к STOP</h2>\n<p>Предположим, ведущий начинает с вопроса: «Вам ведь не хватает большой кнопки “Написать владельцу”?» Согласие участника не подтверждает исходную гипотезу: на ответ повлияли формулировка и желание помочь коллеге. Такой эпизод можно сохранить как сигнал для дизайна следующего исследования, но нельзя использовать как evidence именно этой кнопки.</p>\n<p>То же правило действует для сломанного сценария. Если тестовая заявка уже содержит подсказку, критерий успеха меняется по ходу встречи или участник не понимает, что записывается, результат нельзя сравнивать с планом. Не надо чинить пробел предположением. Создайте новый нейтральный проход после проверки границы данных.</p>\n<p>STOP нужен и при расхождении ролей. Если наблюдали оператора, а решение предназначено администратору, запись остаётся фактом про оператора. Она может стать гипотезой для другой роли, но не доказывает тот же барьер. Так ограничение не исчезает во время передачи задачи от исследователя к дизайнеру и инженеру.</p>\n<h2>Порядок разбора одной задачи</h2>\n<ol><li><strong>Назовите неизвестное.</strong> Запишите вопрос о поведении или следующем шаге, не называя будущую кнопку.</li><li><strong>Опишите границу данных.</strong> Зафиксируйте цель, допустимые заметки или записи, наблюдателей, доступ, хранение и способ отзыва. Сверьте это с локальной policy и владельцем данных.</li><li><strong>Соберите нейтральный сценарий.</strong> Укажите роль, исходное состояние, задачу и критерий окончания. Уберите из prompt желаемый ответ.</li><li><strong>Проведите пробный проход.</strong> Проверьте, что прототип или сервис открывается, тестовые данные безопасны, а наблюдатель знает свою роль.</li><li><strong>Запишите action.</strong> Сохраняйте одно наблюдаемое действие или вопрос на одну запись. Не подменяйте маршрут диагнозом.</li><li><strong>Добавьте code и uncertainty.</strong> Используйте существующую метку, а при новой детали явно укажите, чего она не доказывает.</li><li><strong>Сформулируйте theme.</strong> Объединяйте несколько наблюдений в проверяемый вопрос и перечислите альтернативные объяснения.</li><li><strong>Соберите decision log.</strong> Перечислите observation id, candidate change, claim и следующий сценарий. При любой сломанной ссылке верните STOP.</li><li><strong>Повторите сопоставимый маршрут.</strong> Меняйте один элемент, сохраняйте исходное состояние и заранее задайте критерий, по которому можно будет говорить об эффекте.</li></ol>\n<h2>Что можно и нельзя заключить по результату</h2>\n<p>Две заметки показывают два эпизода, а не распространённость проблемы. Несколько одинаковых вопросов усиливают гипотезу, но сами по себе не устанавливают причину и не доказывают причинный эффект новой кнопки. Роли, опыт, права, частота работы и контекст заявки влияют на маршрут.</p>\n<p>Разделяйте три уровня утверждений. «Курсор остановился у owner» — факт наблюдения. «Следующий шаг недостаточно заметен» — гипотеза. «Новый блок сократил время выполнения» — измеряемое утверждение, для которого нужны метрика, условия сравнения и достаточный объём наблюдений. Если этих условий нет, оставьте <code>claim: not-established</code>.</p>\n<p>Проверка доступности идёт рядом с UX-исследованием, а не заменяется им. WCAG 2.2 даёт тестируемые критерии и уровни соответствия для веб-контента, но сам по себе не отвечает, понимает ли конкретная роль бизнес-сценарий. После выбора кандидатного изменения проверьте клавиатурный маршрут, порядок фокуса, подписи, сообщения об ошибках и работу вспомогательных технологий; затем повторите задачу с подходящими участниками.</p>\n<h2>Критерий готовности</h2>\n<p>Материал готов к следующему инженерному шагу, когда независимый коллега без устного пересказа может восстановить цель, границу данных, роль, исходное состояние, нейтральную задачу, каждое observation, code, uncertainty и все ссылки из decision log. Он понимает, что именно предлагается проверить и чего текущие данные не доказывают.</p>\n<p>Материал не готов, если осталась только цитата, макет, диагноз «неудобно» или обещание улучшения. В таком случае решение возвращается к вопросу, а не превращается в безусловную разработку. Это и есть практический смысл цепочки: она экономит не клики в интерфейсе, а повторный спор о происхождении задачи.</p>\n<h2>Ограничения применимости</h2>\n<p>Метод не заменяет юридическую проверку, локальную политику обработки данных, исследование разных ролей, анализ событий, проверку прав доступа и тестирование производительности. GOV.UK — официальный практический ориентир, но его рекомендации не являются универсальной политикой вашей организации. Учебный код проверяет только целостность ссылок и статус согласия; он не подтверждает качество заметки и не создаёт согласие задним числом.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: Getting informed consent for user research</a> — официальное руководство о цели, собираемых данных, наблюдателях, добровольности, отзыве и хранении evidence согласия. Оно прямо включает сотрудников организации, но не заменяет локальную юридическую policy.</li><li><a href='https://www.gov.uk/service-manual/user-research/taking-notes-and-recording-user-research-sessions' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: Taking notes and recording user research sessions</a> — официальные рекомендации получать informed consent до заметок или записи, отделять наблюдения от интерпретаций и защищать обезличенные материалы. Формат полей в примере — проектное решение статьи.</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> — официальное руководство предлагает заранее определить objectives, проблемы, assumptions и информацию для следующего решения. Оно не устанавливает статистическую репрезентативность малой выборки.</li><li><a href='https://www.w3.org/TR/WCAG22/' target='_blank' rel='noopener noreferrer'>W3C: Web Content Accessibility Guidelines (WCAG) 2.2</a> — официальный тестируемый стандарт доступности веб-контента с уровнями A, AA и AAA. Он помогает оценивать реализацию интерфейса, но не превращает одну UX-заметку в доказательство удобства.</li></ul>"
}