Инженер видит неровный интерфейс и сразу берётся за улучшение: переставить блок, добавить подсказку, упростить форму. Проблема в том, что у этого изменения может не быть подтверждённой пользовательской задачи. Цена — не только потраченный спринт. Команда закрепляет удобный для себя ответ, а исходная трудность остаётся неописанной и потому не проверяется после релиза.
Нужна строгая, но небольшая единица evidence: наблюдение, источник, интерпретация, гипотеза, решение или следующий эксперимент. Это не бюрократическая анкета и не обещание статистической достоверности. Она нужна, чтобы reviewer увидел границу между тем, что было замечено, тем, как это поняли, и тем, что команда пока лишь предлагает проверить. Ниже все карточки учебные; никаких интервью, продуктовых событий и людей здесь нет.
Не принимайте решение за наблюдение
Фраза «пользователи не понимают поле, поэтому добавим tooltip» содержит минимум три разных утверждения. Первое могло быть наблюдением, если есть воспроизводимый источник. Второе — интерпретация: по одному действию нельзя узнать мотив. Третье — решение, которое уже зафиксировало форму ответа. Пока они склеены, нельзя проверить, не поменяли ли мы дизайн ради вкуса команды. Разделение делает неизвестное видимым и оставляет право не выпускать изменение.
| Уровень | Что допустимо записать | Чего он не доказывает | Следующий шаг |
|---|---|---|---|
| Наблюдение | буквально увиденное действие или высказывание | причину и частотность | указать источник |
| Источник | сессия, документ, согласованный сигнал или артефакт | репрезентативность сам по себе | проверить доступ и контекст |
| Интерпретация | осторожное объяснение наблюдения | факт о мотивации | сформулировать альтернативу |
| Гипотеза | проверяемое условие и ожидаемое наблюдение | готовое решение | выбрать опыт |
| Решение/эксперимент | обратимое изменение или способ узнать больше | эффект в продукте | сохранить outcome и границу |
Источник — не украшение записи
Источник отвечает на очень приземлённый вопрос: откуда взялось наблюдение и кто может сверить его контекст. Он не обязан быть числом. Это может быть заметка из согласованной сессии, артефакт поддержки или специально проведённый опыт — если его допустимо хранить и обсуждать. Но строка «все знают» источником не является. Без него фраза не выдерживает повторного чтения и незаметно превращается в авторитет самого громкого участника обсуждения.
Официальное руководство GOV.UK в архивном снимке декабря 2022 года предлагает начать с исследовательских вопросов и превращать непроверенные предположения в такие вопросы. Это важная дисциплина, а не готовая методика для любого продукта. Руководство не доказывает нашу учебную запись и не даёт ей статистический вес. Оно лишь поддерживает направление: сначала назвать то, чего команда не знает, затем подобрать способ узнать это.
Выполните маленькую модель перед обсуждением решения
Fixture ниже создаёт синтетическую карточку и запрещает планировать опыт, пока нет интерпретации и гипотезы. Она также отклоняет наблюдение без источника. После rollback запись исчезает: так пример демонстрирует, что в нём нет накопленного исследования и реального результата. PASS означает только то, что локальные правила объекта соблюдены; он не означает, что кто-то понял интерфейс или что будущий опыт уже проведён.
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'Полезная проверка на ревью проста: можно ли удалить последнее решение и всё ещё понять исходную проблему? Если нельзя, решение замаскировало evidence. Верните отдельную карточку с наблюдением, сохраните дословную формулировку, если она допустима, и назовите её источник. Затем перечислите минимум одну альтернативную интерпретацию. Это замедляет ранний дизайн на несколько минут, но уменьшает вероятность, что команда будет защищать уже нарисованный интерфейс вместо вопроса.
Маршрут: симптом → причина → проверка → действие
- Симптом. В тикете уже есть решение, но нет проверяемого описания проблемы и источника.
- Причина. Наблюдение, его толкование и предпочтение команды записаны одной фразой.
- Проверка. Для каждого утверждения найдите отдельные поля observation, source, interpretation и hypothesis.
- Действие. Сформулируйте следующий опыт, который может подтвердить или опровергнуть гипотезу, не обещая релиз.
- Решение. Только после evidence выберите маленькое изменение либо честно отложите его.
- Rollback. Если запись смешивает уровни, удалите решение и вернитесь к исходному наблюдению; не повышайте предположение до факта.
Граница и rollback
Учебная модель не проводит интервью, не собирает consent, не подключается к аналитике, не хранит персональные данные и не измеряет частоту. Её `synthetic-card-A` выдумана специально для детерминированного fixture. Поэтому нельзя переносить её поля в production как достаточный процесс исследования. Реальный план обязан отдельно решить, какие данные допустимы, кто их читает, как учесть исключённые группы и какой метод отвечает на конкретный вопрос.
Rollback здесь не означает «забыть неудобное evidence». Он означает отменить поспешное решение, если оно не связано с наблюдением или эксперимент пока не согласован. Оставьте проблему открытой и зафиксируйте, чего не хватает. Следующий шаг — взять одну настоящую инициативу и написать пять полей без названия фичи. Если поле решения заполняется раньше гипотезы, вернитесь на шаг назад.
Историческая граница декабря 2022
Использованы только архивные снимки официального GOV.UK Service Manual, доступные до конца декабря 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 года — датированный архивный снимок официального руководства. Он отделяет потребности и исходы пользователя от того, что просто популярно, и описывает исследование как непрерывную работу.