После внутреннего интервью в заметках остаётся фраза «коллеге неудобно», а в задаче уже появляется выбранный редизайн. Наблюдаемый симптом — решение не содержит исходного действия, consent boundary или неизвестного; его нельзя перепроверить. Цена ошибки — невидимая подмена: команда называет правку UX-исследованием и теряет время, когда следующий сценарий снова не проходит.
Причина — четыре разных объекта сливаются в одну цитату. Наблюдение говорит, что произошло; code группирует похожие записи; theme формулирует проверяемую область; decision выбирает следующий шаг. Проверка — требовать ссылки decision на конкретные observation ids и явный статус not-established. Действие — остановить карточку, если связь, consent или neutral scenario отсутствуют.
Четыре уровня evidence
Observation — это самый узкий уровень. В fixed модели он сообщает последовательность на карточке заявки и вопрос об owner. Codebook даёт этому фрагменту метку owner-unclear. Theme next-step-visibility объединяет owner и status только как рабочий вопрос: видит ли исполнитель, что делать после текущего состояния. Candidate change добавляет компактный блок следующего шага, но не заявляет, что он «улучшит UX». Так каждая ступень сохраняет собственную силу утверждения.
| Уровень | Содержит | Проверка | Запрещённый вывод |
|---|---|---|---|
| Observation | видимое действие или вопрос | есть scenario id и uncertainty | «все не понимают» |
| Code | короткая метка записи | code существует в codebook | «код объяснил причину» |
| Theme | объединённый вопрос | можно назвать альтернативы | «нужна именно эта кнопка» |
| Decision | candidate change и follow-up | есть ссылки на observations | «изменение уже помогло» |
Словарь механизма: что разрешает каждая запись
Consent boundary отвечает на вопрос «какой evidence разрешён». Observation отвечает «что произошло в заданном сценарии». Code — стабильное имя наблюдаемой детали; theme — вопрос, который объединяет несколько coded observations. Decision log — карточка следующего действия с ссылками на evidence. Эти уровни нельзя переставлять: theme без observations становится мнением, а decision без theme — списком любимых UI-идей.
В fixed наборе разрешены de-identified notes, а screen recording запрещён. Это не готовая политика хранения. Настоящая команда отдельно определяет владельца, срок, доступ и процесс отзыва. Модель проверяет только собственный контракт: один тип evidence, confirmed consent, существующие codes и ссылочная целостность decision. Если хоть одна граница нарушена, итог — stop-before-change.
Воспроизводимый разбор связи evidence и решения
import { createFixedResearchInput, inspectToolUxResearch, prepareSyntheticFollowUp } from './upgrade-2025-08.mjs';
const input = createFixedResearchInput('fixed-unlinked-decision-v1');
const report = inspectToolUxResearch(input);
console.log(prepareSyntheticFollowUp(report));
// Expected: stop-and-repair-boundary with an untraceable decision.
// No files, recordings, APIs or production data participate.В этой ветке candidate change выглядит правдоподобно, но ссылается на отсутствующий observation id. Поэтому нельзя проверить, что решение выросло из работы по задаче, а не из памяти workshop. Инспектор не предлагает другую кнопку и не ремонтирует ссылку сам. Он возвращает причину, после которой владелец должен либо восстановить evidence, либо сформулировать новый сценарий.
Проверка механики по порядку
- Проверить consent status. Withdrawn означает stop, даже если заметка кажется полезной.
- Проверить тип evidence. Notes-only boundary не расширяется записью ради более удобного анализа.
- Проверить prompt. Scenario описывает действие и успех, а не ответ, который хочет услышать автор.
- Проверить coding. У каждой observation есть допустимый code и uncertainty, иначе theme не имеет опоры.
- Проверить ссылки decision. Каждый cited id должен существовать в том же наборе наблюдений.
- Ограничить hand-off. Положительный результат разрешает лишь isolated follow-up на той же задаче.
Пакет хранит только fixed synthetic JavaScript literals в памяти. Он не читает, не пишет и не отправляет данные; `effect` всегда `no-system-change`. Поэтому пример воспроизводит проверку контракта, но не проверяет людей, реальный интерфейс или effect candidate change.
Почему neutral scenario важнее красивого interview guide
Ведущий вопрос сокращает дорогу к согласию, но убирает информацию. Формулировка «вам ведь не хватает большой кнопки?» уже содержит объект, размер и оценку. Нейтральный сценарий говорит только о задаче: найти состояние заявки и назвать следующий owner. Он позволяет наблюдать обход, термин, отсутствие статуса или другой путь. Если исследователь хочет проверить конкретную кнопку, это отдельный usability test после того, как проблема описана без решения.
Fixture показывает этот разрыв буквально. Когда neutralPrompt заменён на forbidden prompt, инспектор возвращает neutral-task-scenario-required. В реальной работе нельзя свести качество вопроса к регулярному выражению. Но эта fixed проверка полезна как отрицательный пример: модель обязана различать сценарий задачи и аргумент автора, иначе удачный ответ будет встроен в входные данные.
Decision log должен говорить, чего он не знает
Полезный decision log не прячет неуверенность за словами «инсайт» и «паттерн». Он перечисляет observation ids, тему, candidate change, владельца следующего шага и границу претензии. В данном пакете claim начинается с not-established: ни удобство, ни скорость, ни снижение нагрузки не были измерены. Это не ослабляет документ. Наоборот, reviewer видит, что обсуждать: достаточно ли evidence для следующего сценария, а не для массового запуска.
Вторая защита — одинаковый сценарий follow-up. Если baseline просит проверить статус, а после правки просит «оценить новый блок», сравниваются разные действия и контекст. Fixed record требует тот же objective, starting state и neutral prompt. Это не экспериментальный дизайн и не случайное распределение. Это минимальная защита от очень частой ошибки: принять новую формулировку вопроса за эффект новой поверхности.
Отрицательные ветки — часть исследования
Consent withdrawn останавливает работу до coding. Recording outside notes-only boundary останавливает её даже при полезной заметке. Unlinked decision останавливает candidate change, потому что reviewer не может восстановить его происхождение. Эти стопы не означают, что реальный человек или организация нарушили правило: все values synthetic. Они показывают, что безопасная система не должна лечить пробел в evidence догадкой или удачной цитатой.
Ограничение и следующий шаг
Codebook не является нейтральной машиной истины: выбор меток влияет на то, что команда замечает. Руководства GOV.UK помогают описать consent и план, но не дают универсальный список кодов и не переносят согласие одной организации на другую. Следующий шаг: возьмите один старый research note, отдельно выпишите факт, code, theme и decision. Если decision нельзя связать с конкретной заметкой, не спорьте о формулировке кнопки — сначала заведите новый нейтральный сценарий.
Историческая граница августа 2025
Источники относятся к доступным до 31 августа 2025 руководствам GOV.UK; их даты и границы приведены в списке источников. Из них взяты только требования к осмысленному согласию, работе с заметками и планированию вопросов. Разделение evidence levels, exact JS literals и stop rules не являются предписанием GOV.UK и не доказывают реальный outcome.
Проверяемые источники
- GOV.UK Service Manual: Getting informed consent for user research — версия: immutable archive capture 2025-07-02T00:40:27Z of official GOV.UK guidance; published 24 May 2016, last updated 5 November 2018. Информированное согласие описывает цель, собираемые данные, наблюдение или запись, использование результатов, добровольность и возможность отзыва. Граница: Это руководство для государственных сервисов Великобритании, а не универсальная юридическая политика или готовая форма для другой организации.
- GOV.UK Service Manual: Taking notes and recording user research sessions — версия: immutable archive capture 2025-07-02T00:37:09Z of official GOV.UK guidance; published 25 June 2017. Заметки и записи требуют согласия; при чувствительной теме руководство предлагает избегать идентифицирующих деталей и проверять материалы перед распространением. Граница: Источник не устанавливает качество конкретного интервью, не задаёт коды наблюдений и не доказывает, что обезличивание устраняет весь риск.
- GOV.UK Service Manual: Plan a round of user research — версия: immutable archive capture 2025-07-02T00:37:43Z of official GOV.UK guidance; published 24 May 2016. План предлагает начать с проблем, предположений и того, что нужно узнать для следующего решения, а не с заранее выбранного решения интерфейса. Граница: Это планировочная рекомендация. Она не превращает один сценарий, одну цитату или один synthetic пример в подтверждение гипотезы.