Самая опасная ошибка в обсуждении интерфейса — выдать интерпретацию за факт. Тогда инженер получает красивую задачу, но не получает проблему, которую должен решать. Цена видна поздно: решение уже собрано, а на вопрос «почему именно оно?» остаются ссылка на старый созвон и уверенная формулировка без источника. Такое изменение трудно отменить, потому что спор идёт о вкусах, а не о проверяемой цепочке.
Разберём evidence как контракт состояний. Наблюдение допускается только с источником. Интерпретация прикрепляется к конкретной записи и обязана говорить о неопределённости, а не объявлять мотив установленным. Гипотеза появляется после интерпретации. Только затем модель разрешает запланировать следующий эксперимент или явное `defer-solution`. Это учебный reducer; он не моделирует людей, сессии, consent, аналитику, browser или метрики.
Контракт должен запрещать короткий путь
Если в трекере можно сразу написать «сделать кнопку заметнее», процесс поощряет решение до вопроса. Контракт не запрещает инженерную инициативу; он заставляет пометить её как предположение. В модели `planExperiment` возвращает `decision-rejected`, пока у записи нет гипотезы. Это полезная граница: решение не становится доказательством самого себя, а следующий опыт остаётся отдельным объектом, который можно не проводить, изменить или откатить.
| Вход | Допустимое условие | Результат | Недопустимая подмена |
|---|---|---|---|
| observation | есть text и source | создана запись | наблюдение без происхождения |
| interpretation | существует id | добавлен осторожный смысл | объявить его фактом |
| hypothesis | есть interpretation | записано проверяемое допущение | сразу указать UI-решение |
| experiment | есть hypothesis и nextExperiment | решение отложено или опыт спланирован | назвать его проведённым |
| rollback | есть snapshot | синтетическая запись снята | стирать исходный источник |
Интерпретация должна переживать несогласие
Хорошая интерпретация не звучит как приговор. Вместо «человек не понимает термин» она говорит: «это наблюдение не объясняет, почему поле осталось пустым». Такая запись хуже продаёт инициативу, но лучше работает на следующем шаге: можно проверить язык, порядок полей, контекст задачи или недоступность действия. Несколько гипотез могут относиться к одному наблюдению. Если команда выбрала одну из них из-за ограничений времени, это решение надо назвать, а не маскировать под вывод исследования.
Архивный GOV.UK Service Manual отделяет вопросы команды от её непроверенных предположений и советует выбирать исследовательские активности по тому, что нужно узнать. Мы не превращаем это в универсальную норму и не заимствуем у руководства реальный кейс. Здесь это только подтверждение принципа: метод не должен быть выбран по привычке, а вопрос не должен быть подменён заранее выбранным компонентом.
Проверяемый код и то, чего он не проверяет
Выполнение fixture создаёт одну синтетическую запись. Первая попытка без source отвергается. Ранняя попытка планировать опыт отвергается. После интерпретации и гипотезы модель принимает `defer-solution` с текстом следующего опыта, а затем rollback очищает запись. Assertions намеренно не содержат «пользователь согласен», «conversion выросла» или «интервью завершено»: у модели нет таких входных данных.
import { runUserResearchFixture } from './upgrade-2022-12.mjs';
const report = runUserResearchFixture();
if (!Object.values(report.assertions).every(Boolean)) throw new Error('evidence contract failed');
console.log(report.evidence.planned.record.decision.decision); // 'defer-solution'
console.log(report.boundary.interview); // 'not-conducted'Этот код годится как проверяемый пример для соглашения в команде, но не как библиотека исследования. В production нельзя использовать его ids, строки и отсутствие политики хранения. Если нужен настоящий инструмент, отдельно спроектируйте роли, доступ, аудит изменений, удаление данных и связь с согласованными исследованиями. Не расширяйте значение двенадцати assertions до этих задач: они проверяют только порядок локальных переходов.
Маршрут: симптом → причина → проверка → действие
- Симптом. В тикете уже есть решение, но нет проверяемого описания проблемы и источника.
- Причина. Наблюдение, его толкование и предпочтение команды записаны одной фразой.
- Проверка. Для каждого утверждения найдите отдельные поля observation, source, interpretation и hypothesis.
- Действие. Сформулируйте следующий опыт, который может подтвердить или опровергнуть гипотезу, не обещая релиз.
- Решение. Только после evidence выберите маленькое изменение либо честно отложите его.
- Rollback. Если запись смешивает уровни, удалите решение и вернитесь к исходному наблюдению; не повышайте предположение до факта.
Как не превратить модель в театральный процесс
Пять заполненных полей не делают слабое наблюдение сильным. Запись может быть неполной, источник — узким, а гипотеза — неверной. Контракт нужен, чтобы это было видно до разработки. В поле source полезно указывать тип и границу: что именно доступно для сверки, чего оно не говорит и на какой вопрос не отвечает. Если таких данных нет, честный статус — «неизвестно», а не аккуратно оформленная история о пользователе.
Второй риск — спросить людей только о выбранном решении. Тогда запись формально содержит experiment, но фактически проверяет вкус. Сначала сформулируйте задачу и наблюдаемый критерий понимания или выполнения, затем выбирайте прототип, интервью, наблюдение или существующий артефакт. В этой статье не назначается метод и не задаётся размер выборки: это зависит от вопроса, рисков и контекста, которого учебная модель не содержит.
Граница и следующий шаг
Модель не является интервью-скриптом, исследовательским репозиторием или системой принятия решений. Она не оценивает качество источника, не гарантирует отсутствие bias и не знает юридические требования. Документы GOV.UK описывают подход для государственных сервисов; они не являются спецификацией вашего продукта. Их неизменяемые архивные URL нужны здесь только для честной исторической рамки декабря 2022 года.
Следующий шаг: выберите одну уже написанную фичу и проведите статический разбор. Отделите предложения, которые являются наблюдениями, от предложений, которые являются объяснениями. Для каждого объяснения добавьте альтернативу и вопрос. Если не удаётся сформулировать следующий опыт без слова «реализовать», остановите дизайн. Это нормальный результат: проблема пока не определена достаточно, чтобы кодировать решение.
Историческая граница декабря 2022
Ссылки ведут на архивные snapshots GOV.UK от 26 ноября и 5 декабря 2022 года. Они доступны до заданного месяца и использованы как официальные методические источники, а не как свидетельства о конкретных пользователях или системах.
Проверяемые источники
- GOV.UK Service Manual: Plan user research for your service, snapshot 5 декабря 2022 года — датированный архивный снимок официального руководства. Он предлагает превращать непроверенные предположения в исследовательские вопросы и связывать метод с тем, что нужно узнать.
- GOV.UK Service Manual: User research for government services, snapshot 26 ноября 2022 года — датированный архивный снимок официального руководства. Он отделяет потребности и исходы пользователя от того, что просто популярно, и описывает исследование как непрерывную работу.