Внутренний инструмент получает просьбу «сделать удобнее», и интервью быстро подтверждает готовую кнопку автора. Наблюдаемый симптом — вопрос звучит как подсказка решения, а заметка хранит удачную цитату вместо пути по задаче. Цена ошибки — команда тратит разработку на локальную правку, но коллега по-прежнему не понимает следующий шаг и возвращается с тем же вопросом.
Причина в том, что интервью используют как голосование за макет. Проверка проще: убрать название контроля, дать человеку нейтральную задачу и записать только наблюдаемое действие, вопрос и границу неизвестного. Действие — связать заметку с code и decision log, где изменение остаётся гипотезой до следующего сценария.
Начинаем не с вопроса «нравится ли»
Для внутреннего инструмента полезно выбрать одну работу, а не абстрактное мнение. В fixed сценарии инженер должен понять состояние одной заявки и найти владельца следующего вопроса. Он не просит оценить экран и не говорит «кнопка связи». Поэтому ответ может опровергнуть автора: человек может сразу найти owner, но не понять status; может наоборот знать статус, но не знать, куда адресовать исключение. Оба пути ценнее согласия с заранее нарисованным решением.
| Поле | Fixed пример | Зачем | Чего не доказывает |
|---|---|---|---|
| Purpose | понять следующий шаг по заявке | не подменять цель оценкой личности | что интерфейс плох для всех |
| Evidence | de-identified note | не вынести лишний материал за consent boundary | что заметка безопасна при любом контексте |
| Scenario | проверить статус и owner | дать наблюдаемый маршрут | частоту проблемы |
| Uncertainty | неясна причина невидимости owner | не склеить факт и объяснение | причинность |
| Follow-up | тот же fixed scenario | проверить candidate change | рост удобства в production |
Минимальные определения для практического прохода
Нейтральный task scenario — это задача с исходным состоянием и критерием окончания, но без названия будущей кнопки. Informed consent, информированное согласие, задаёт цель, допустимый материал и возможность остановиться. Consent boundary — его техническая граница: в этом примере разрешена только de-identified note, то есть обезличенная заметка без записи экрана, имени, тикета или production-данных.
Evidence coding здесь означает короткую метку к конкретной заметке. Она не объясняет поведение человека. Code owner-unclear говорит только, что в одном маршруте следующий owner не найден. Рядом обязательна uncertainty: неизвестна частота этого вопроса и причина невидимости поля. Такая пара не позволяет превратить единичную фразу в утверждение о всех коллегах.
Воспроизводимый маршрут практики
import { createFixedResearchInput, inspectToolUxResearch } from './upgrade-2025-08.mjs';
const report = inspectToolUxResearch(
createFixedResearchInput('fixed-leading-prompt-v1'),
);
console.log(report.reasons);
// Expected: ['neutral-task-scenario-required'].
// The input is fixed in-memory synthetic data; no session or UI is started.
Этот negative path намеренно подменяет task prompt ведущим вопросом о большой кнопке. Инспектор останавливает hand-off до coding и до candidate change. Он не определяет качество реальной беседы по одному шаблону текста: это ограниченный executable пример того, что сценарий задачи и просьба подтвердить решение автора — разные входы.
Шесть действий ведущего сессии
- Записать неизвестное решение. Не «добавить кнопку», а «понять, что мешает назвать следующий шаг».
- Показать consent card до сценария. Уточнить цель, notes-only boundary, отсутствие записи и путь отзыва.
- Дать задачу без интерфейсной подсказки. Попросить разобраться со status и owner, а не оценить нарисованный блок.
- Записать маршрут буквально. Порядок прочтения, остановка, вопрос; без ярлыка «запутался».
- Добавить code и uncertainty. Метка связывает заметку с дальнейшим разбором, а неизвестное не даёт раздуть её силу.
- Передать только candidate follow-up. Новая проверка повторяет ту же задачу; выпуск UI не следует из одной заметки.
Все consent cards, роли, сценарии, наблюдения, коды, темы, решения и follow-up ниже — fixed synthetic JavaScript literals только в памяти. Модуль не читает и не пишет files, не использует сеть, clock, telemetry, production, PII, записи, real API, Git или CI и не выполняет side effect.
Consent card — это техническая граница материала
В руководстве GOV.UK informed consent включает цель, собираемые данные, способ использования, наблюдение или запись, добровольность и возможность отзыва. Для инженера это не формальность в конце календарного приглашения. Карточка определяет, какие поля имеет право получить протокол. Если согласованы только обезличенные notes, исследователь не добавляет запись «на всякий случай», не пересылает экран и не оставляет имя в decision log.
В модели consent status withdrawn приводит к stop. Второй negative path разрешает screen recording при notes-only boundary и тоже останавливает работу. Такой код не исполняет удаление реальных материалов; у него нет файлов и реальных записей. Он делает видимым правило, которое легко потерять в ручной таблице: evidence вне согласованного набора не превращается в «полезный дополнительный контекст».
Заметка сначала, тема потом
Хорошая observation record скучна: «прочитан status; курсор остановился у owner; сформулирован вопрос о следующем ответственном». В ней нет фразы «пользователь растерялся» и нет диагноза команды. Code owner-unclear связывает запись с темой, но его значение ограничено: он указывает, что owner не найден в этом маршруте, а не почему это случилось и не сколько людей столкнутся с тем же.
Неопределённость записывают рядом с кодом. Это экономит спор: дизайнер не обязан доказывать, что текст плох, а инженер не обязан угадывать, что имелось в виду. Следующий вопрос становится конкретным: показать ли owner до отправки, пояснить ли status, изменить ли порядок полей или сначала собрать ещё один observation. Когда evidence не различает варианты, решение — не «самый убедительный спикер», а новый сценарий.
Ограничение и следующий шаг
Один сценарий не является исследованием всей организации. Он не даёт метрик, денег, реальных сотрудников, записей, репрезентативности или причины задержки. GOV.UK guidance поддерживает идею явного согласия и планирования вопросов, но не переносит свои policy на другой контекст. Следующий шаг: возьмите одну внутреннюю задачу, вычеркните из prompt название будущей кнопки и добавьте к каждой заметке одну строку uncertainty. Ожидаемый результат — decision log содержит гипотезу, которую можно опровергнуть на следующем проходе.
Историческая граница августа 2025
Использованы три первичных руководства GOV.UK, опубликованные до 31 августа 2025; для каждого в источниках видна датированная версия страницы. Они применены только к consent, заметкам и постановке исследовательского вопроса. Fixed data model, codebook, stop reasons и candidate change — инженерская конструкция автора. Она не доказывает, что гипотеза верна, и не подменяет policy, legal review или живое исследование.
Проверяемые источники
- 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 пример в подтверждение гипотезы.