Команда получает просьбу «починить форму заявки» и сразу собирает board из цитат. Наблюдаемый симптом — в карточке решения нет ни задачи, ни границы согласия, ни того, что именно видел коллега. Цена ошибки — новый интерфейс становится дорогим спором: никто не может показать, какая проблема была проверена, а следующая обратная связь снова сводится к вкусу.
Причина — материал исследования живёт в заметках, а изменение — в отдельной задаче. Проверка — вести короткий журнал, в котором consent card, scenario, observation, code, uncertainty, decision и follow-up соединены идентификаторами. Действие — выпускать только hypothesis for follow-up; если журнал не восстанавливает путь к заметке, интерфейс не меняют под видом evidence.
Минимальный журнал помещается в один review
Журнал не заменяет репозиторий записей и не собирает персональные данные. Ему достаточно семи полей: purpose, consent boundary, scenario, observation, code, uncertainty, decision. Для fixed примера purpose — найти следующий шаг в заявке; consent разрешает только de-identified note; scenario не называет будущий блок; decision предлагает проверить компактное пояснение status и owner. Каждая строка указывает, что она знает, а что оставляет неизвестным.
| Поле | Значение | Вопрос reviewer |
|---|---|---|
| Consent boundary | de-identified note only; no recording | какой материал вообще допустим? |
| Scenario | найти status и next owner | нет ли подсказки решения? |
| Observation ids | owner-v1, status-v1 | что именно было замечено? |
| Theme | next-step visibility | какие альтернативы ещё возможны? |
| Candidate change | блок owner + status explanation | что проверяем, а не обещаем? |
| Claim | not-established | какой эффект запрещено заявлять? |
| Follow-up | тот же fixed neutral scenario | с чем сравним следующий record? |
Поля журнала и их самостоятельный смысл
В полевом журнале consent boundary — не ссылка на шаблон, а ответ: можно ли использовать именно эту заметку. Scenario фиксирует работу без UI-подсказки. Observation сохраняет видимое действие, code даёт ей короткое имя, uncertainty ограничивает трактовку. Decision log связывает эти элементы и формулирует follow-up. Такое разнесение делает журнал полезным, когда автор сессии недоступен: reviewer восстанавливает цепочку без пересказа встречи.
Термин traceability означает прослеживаемость решения назад до наблюдения. Он не равен доказанной причинности. Если карточка советует добавить owner block, reviewer должен увидеть две заметки, из которых возникла тема next-step visibility, и то, что они не устанавливают частоту или эффект. Иначе один удачный рассказ незаметно становится нормативом для всего внутреннего инструмента.
Воспроизводимый тест полевого журнала
import { createFixedResearchInput, inspectToolUxResearch, prepareSyntheticFollowUp } from './upgrade-2025-08.mjs';
const report = inspectToolUxResearch(
createFixedResearchInput('fixed-withdrawn-consent-v1'),
);
console.log(prepareSyntheticFollowUp(report));
// Expected: stop-and-repair-boundary.
// This only validates fixed literals; it does not delete or retain real research material.Ветка показывает важный порядок: withdrawn consent проверяется раньше темы и UI-решения. В настоящей работе реакция на отзыв определяется policy организации и может включать удаление. Скрипт ничего не удаляет и не симулирует человека; его результат только запрещает synthetic hand-off. Поэтому он не выдаёт технический пример за инструкцию по обработке реальных материалов.
Порядок review для одной UX-задачи
- Открыть boundary. Убедиться, что purpose, evidence type, запись и отзыв сформулированы до чтения цитат.
- Прочитать scenario без макета. Проверить, что задача может привести и к неудобному для автора ответу.
- Проверить notes. В каждой остались действие или вопрос, а не оценка человека.
- Сверить codes. Метка существует в codebook и не обещает объяснить причину наблюдения.
- Прочитать uncertainty вслух. Она должна назвать то, чего evidence не установил.
- Разрешить следующий шаг, не результат. Decision получает follow-up на том же сценарии или STOP при сломанной ссылке.
Все карточки, labels и outcomes в этом журнале — fixed synthetic JavaScript literals. Нет реальных сотрудников, интервью, записей, денег, метрик, файлов, API или production-систем. Положительный результат модели означает только корректный synthetic hand-off; это не usability finding и не разрешение менять внешний или внутренний продукт.
Как провести review журнала
Сначала reviewer читает consent boundary, а не candidate change. Если цель и разрешённый evidence неясны, полезность заметки не оправдывает её использование. Затем он читает scenario вслух и вычёркивает слова, которые называют будущий control. После этого проверяет observation: есть ли действие или вопрос, code и uncertainty. Лишь в конце он смотрит на theme и решение. Такой порядок уменьшает confirmation bias — склонность видеть только то, что поддерживает первоначальную идею.
Следующий тест — traceability, прослеживаемость. Для каждого предложения в decision log reviewer открывает observation id и задаёт один вопрос: «что именно здесь наблюдали?» Если ответом служит память участника встречи, связь не восстановлена. В fixed инспекторе unlinked id даёт decision-not-traceable-to-evidence. Код не заменяет совместный разбор, но делает отсутствие ссылки явным до того, как задача попадёт в backlog.
Как не выдать follow-up за результат
Candidate change здесь предельно маленькое: добавить блок следующего шага. У него нет обещания «сократить время», «снизить обращения» или «повысить satisfaction». Следующий synthetic hand-off допускает только новую обезличенную observation record на той же задаче. Если changed scenario добавит обучение, другое исходное состояние или вопрос об оценке блока, журнал должен написать, что условия различаются. Смешивать два маршрута и называть разницу улучшением нельзя.
Это особенно важно для внутренних инструментов, где участники знают автора и могут помогать ему ответом. Нейтральная задача, пауза после вопроса и заметка о неизвестном не устраняют социальное давление полностью. Они дают команде место, где это давление можно заметить. Если человек соглашается с решением, но не может завершить сценарий, для интерфейса важнее наблюдаемый маршрут, а не вежливое одобрение.
Граница приватности и распространения
GOV.UK guidance подчёркивает, что notes и recordings могут содержать personal data и должны использоваться в пределах согласия. Отсюда не следует, что слово «анонимный» снимает все риски. В настоящей среде нужно заранее определить владельца данных, место хранения, доступ, срок и процесс отзыва. В этом пакете нет ни одного реального поля или записи; synthetic labels созданы именно чтобы пример нельзя было ошибочно принять за шаблон хранения данных коллег.
Ограничение и следующий шаг
Полевой журнал не обещает объективность и не превращает две заметки в представительную выборку. Он не измеряет деньги, производительность, качество сотрудника или эффект интерфейса. Его практическая ценность уже: плохое evidence останавливается раньше разработки, а хорошее оставляет путь для проверки. Следующий шаг: добавьте в ближайшую UX-задачу ссылки на scenario и observation, одну uncertainty и статус claim. Если хотя бы одна ссылка отсутствует, заведите follow-up research task вместо UI ticket.
Историческая граница августа 2025
Все использованные официальные руководства были опубликованы до 31 августа 2025; список источников показывает дату и ограничение каждого. Они поддерживают дисциплину согласия, работы с заметками и исследовательских вопросов. Наша модель decision log не является универсальным стандартом, не переносит consent между организациями и не доказывает корректность гипотезы о внутреннем интерфейсе.
Проверяемые источники
- 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 пример в подтверждение гипотезы.