{
  "index": 86,
  "slug": "editorial-2025-08-mechanism-tool-ux-research",
  "title": "UX внутреннего инструмента: от наблюдения к проверяемому решению",
  "excerpt": "Внутренний интерфейс ломается не только из-за плохой кнопки. Разбираем цепочку consent → observation → code → theme → decision, отрицательные ветки и критерий готовности.",
  "contentHtml": "<p>После короткого интервью в задаче часто остаётся фраза «коллеге неудобно», а рядом уже стоит готовый редизайн. Симптом виден: решение не содержит исходного действия, условий сценария и того, чего наблюдение не установило. Через неделю никто не может восстановить связь между заметкой и изменением. Цена ошибки — лишнее время и новый обход того же участка.</p>\n<p>Внутренний инструмент нужно исследовать через границу доказательства. Сначала фиксируют, что разрешено наблюдать и хранить. Затем записывают видимое действие. Потом группируют записи, формулируют вопрос и только после этого выбирают следующий эксперимент. Цепочка выглядит так: <code>consent → observation → code → theme → decision</code>. Каждый следующий уровень допускает более сильное решение, но не стирает ограничения предыдущего.</p>\n<h2>Почему одна цитата не объясняет проблему</h2>\n<p>Фраза «не нашёл владельца» — это не причина и не предложение для интерфейса. Это наблюдение, если оно привязано к задаче: человек прочитал статус, дошёл до поля <code>owner</code> и задал вопрос о следующем ответственном. Запись не доказывает, что термин плох, что все пользователи теряются или что нужна кнопка «Написать владельцу».</p>\n<p>У наблюдения должны быть идентификатор сценария, видимое действие, короткий code и uncertainty. Code собирает похожие факты. Он не ставит диагноз. Например, <code>owner-unclear</code> означает только, что в данном маршруте не удалось найти владельца следующего шага. Uncertainty говорит, чего запись не установила: частоту, причину и переносимость на другие роли.</p>\n<h2>Механизм и граница силы вывода</h2>\n<p><strong>Consent boundary.</strong> До разговора определяют цель, тип evidence, наблюдение, запись и путь отзыва. Для внутреннего сотрудника действует та же необходимость добровольного согласия, что и для внешнего участника. Если разрешены обезличенные заметки, запись экрана не появляется «для удобства анализа». Отозванное согласие останавливает hand-off и требует следовать правилам хранения организации.</p>\n<p><strong>Observation.</strong> Запись описывает видимое действие или вопрос в заданном сценарии. «Курсор остановился у owner» сильнее, чем «человек растерялся»: первое можно проверить по маршруту, второе уже содержит интерпретацию.</p>\n<p><strong>Code и theme.</strong> Code даёт стабильное имя детали. Theme объединяет несколько codes в проверяемый вопрос. Два наблюдения про owner и статус могут образовать theme <code>next-step-visibility</code>: видит ли исполнитель, что делать после текущего состояния. Theme не отвечает, какая кнопка нужна.</p>\n<p><strong>Decision.</strong> Решение выбирает candidate change и следующий follow-up. Оно ссылается на observation ids, содержит claim и отмечает статус <code>not-established</code>, если эффект ещё не проверен. Decision без ссылок — список предпочтений. Decision с отсутствующей ссылкой получает STOP.</p>\n<figure><img src='/assets/editorial/2025/tool-ux-research-2025-observation-decision-matrix.svg' alt='Матрица связи observation, code, theme и decision: неполная граница consent или отсутствующая ссылка останавливает переход к candidate change' loading='lazy' /><figcaption>Матрица показывает переход от двух synthetic observations к теме и следующему эксперименту. Она не показывает процент удобства и не доказывает эффект изменения.</figcaption></figure>\n<h2>Учебный пример с отрицательной веткой</h2>\n<p>Ниже — только фиксированный synthetic пример. В нём нет реальных людей, заявок, записей, API, telemetry и production-данных. Есть карточка access request, статус <code>processing</code> и поле <code>owner</code>. Нейтральная задача просит показать, как найти состояние заявки и назвать следующий вопрос. Ведущий не подсказывает будущую кнопку.</p>\n<pre><code>const observation = { id: 'synthetic-observation-owner-v1', scenarioId: 'synthetic-scenario-access-request-v1', evidenceKind: 'de-identified-note', statement: 'Статус прочитан; курсор остановился у owner; следующий вопрос: кто отвечает после отправки?', codeIds: ['code-owner-unclear-v1'], uncertainty: 'Не установлены частота и причина остановки.' }; const decision = { observationIds: ['synthetic-observation-owner-v1', 'synthetic-observation-status-v1'], theme: 'next-step-visibility', candidateChange: 'Добавить компактный блок следующего шага.', claim: 'not-established', followUp: 'Повторить тот же neutral scenario.', status: 'synthetic-follow-up-only' };</code></pre>\n<p>В нормальной ветке инспектор проверяет, что оба observation id существуют, code есть в codebook, scenario нейтрален, а consent разрешает именно этот тип заметки. Результат — не «интерфейс улучшен», а разрешение на изолированный follow-up. В учебном примере нужно повторить ту же задачу с заранее описанным изменением и заново записать наблюдаемое действие.</p>\n<p>В отрицательной ветке decision ссылается на <code>missing-observation-v1</code>. Инспектор возвращает <code>decision-not-traceable-to-evidence</code> и не чинит ссылку автоматически. Владелец восстанавливает исходную запись или создаёт новый сценарий. Если consent имеет статус withdrawn, проверка останавливается раньше темы. Если prompt звучит как «вам ведь не хватает большой кнопки?», результат — <code>neutral-task-scenario-required</code>. Удачный ответ на наведённый вопрос не становится evidence.</p>\n<h2>Симптом → причина → проверка → действие</h2>\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>Theme подменили candidate change</td><td>Есть ли два observation с видимым действием?</td><td>Вернуться к нейтральному сценарию и записать uncertainty</td></tr><tr><td>В заметке написано «пользователь запутался»</td><td>Интерпретация смешалась с фактом</td><td>Можно ли описать действие без оценки?</td><td>Переписать statement и сохранить контекст</td></tr><tr><td>Решение выглядит убедительно, но ссылок нет</td><td>Decision вырос из памяти встречи</td><td>Каждый cited id находится в том же наборе?</td><td>Остановить hand-off до восстановления evidence</td></tr><tr><td>Для анализа включили запись экрана</td><td>Тип evidence расширили после согласия</td><td>Разрешены ли запись и наблюдатели в boundary?</td><td>Не использовать запись; сверить policy и consent</td></tr><tr><td>После изменения объявили «UX улучшился»</td><td>Follow-up выдали за результат</td><td>Есть ли сравнимый сценарий и измеримый критерий?</td><td>Поставить claim <code>not-established</code> и назначить отдельную проверку</td></tr></tbody></table></div>\n<h2>Порядок работы для одной UX-задачи</h2>\n<ol><li><strong>Открыть boundary.</strong> Записать цель, допустимый тип evidence, хранение, наблюдателей и порядок отзыва.</li><li><strong>Описать neutral scenario.</strong> Назвать исходное состояние, действие и условие успеха. Убрать из prompt будущую кнопку и оценку участника.</li><li><strong>Сделать observation.</strong> Записать действие или вопрос, scenario id и uncertainty. Не называть причину, которую человек не показал.</li><li><strong>Применить code.</strong> Выбрать существующую метку из codebook. Если метки нет, не расширять вывод одной записью.</li><li><strong>Сформулировать theme.</strong> Объединить несколько наблюдений в вопрос и назвать альтернативу. Theme должна допускать отрицательный ответ.</li><li><strong>Собрать decision log.</strong> Добавить candidate change, observation ids, claim и follow-up. Проверить каждую ссылку, consent и статус.</li><li><strong>Запустить следующий тест.</strong> Повторить сопоставимый сценарий. Не объявлять эффект до заранее заданного критерия.</li></ol>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Две заметки не дают частоту, репрезентативность или объяснение задержки. Codebook не заменяет исследователя. Neutral prompt не устраняет социальное давление во внутренней команде. Обезличивание не отменяет требований к доступу, сроку хранения и отзыву. Для чувствительных данных нужны policy организации, владелец данных и юридическая проверка.</p>\n<p>Механизм не выбирает лучший интерфейс. Он не даёт слабому evidence незаметно превратиться в backlog ticket. Candidate change может оказаться неверным. При сломанной ссылке, неподтверждённом consent, наведённом prompt или несопоставимом follow-up результатом должен быть STOP, а не новая гипотеза.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>UX-разбор готов, если независимый reviewer может пройти от decision до каждой observation и обратно к одному neutral scenario. У каждой observation есть видимое действие, scenario id, code и uncertainty. У decision существуют все cited ids, есть claim <code>not-established</code> до проверки эффекта и указан следующий сопоставимый сценарий. Boundary разрешает использованный evidence. Для withdrawn consent или любой сломанной ссылки проверка возвращает STOP. Это проверяемый контракт, а не обещание, что интерфейс уже стал удобнее.</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> — официальное руководство описывает цель, собираемые данные, наблюдение, запись, добровольность и отзыв согласия. Оно задаёт границу для consent, но не является универсальной юридической политикой другой организации.</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> — официальное руководство требует согласия до заметок и записи и рекомендует отделять наблюдения от интерпретаций. Оно не подтверждает synthetic-пример и не доказывает production-эффект.</li><li><a href='https://www.w3.org/TR/WCAG22/' target='_blank' rel='noopener noreferrer'>W3C: Web Content Accessibility Guidelines (WCAG) 2.2</a> — актуальный официальный стандарт доступности веб-контента. Он помогает проверять интерфейс после формулировки проблемы, но не заменяет user research и не выводит UX-решение из одной заметки.</li></ul>"
}