Задача на улучшение интерфейса часто приходит уже с макетом, названием компонента и оценкой. Проблема — никто не может показать, какая пользовательская трудность подтверждает это решение. Цена такой скорости — дорогая ложная определённость: разработка быстро закрывает тикет, но команда не узнаёт, исчезла ли исходная преграда, и получает ещё один слой UI, который придётся объяснять и поддерживать.
Полевой маршрут начинается не с поиска «самого частого» сигнала и не с имитации интервью. Он берёт только то, что можно показать reviewer: наблюдение и источник. Затем отдельно описывает возможные смыслы, гипотезу и следующий опыт. В примере ниже используются учебные записи. Мы не называем их отзывами, не рисуем воронку и не сообщаем эффект, потому что такого evidence в статье нет.
Диагностируйте утверждение в задаче
Откройте инициативу и подчеркните глаголы: «не понимают», «часто бросают», «нужно упростить», «лучше добавить». Первые два могут звучать как факты, последние два — как решения, но без источника все четыре остаются допущениями. Не спорьте с автором задачи о правоте. Спросите точнее: что было наблюдаемо, где это зафиксировано, какой контекст известен и что из этого ещё не ясно. Если ответа нет, это не провал автора; это корректно обнаруженная исследовательская дыра.
| Симптом в задаче | Что обычно смешано | Проверка | Безопасное действие |
|---|---|---|---|
| «сделать проще» | решение и критерий успеха | есть ли описанная трудность | отложить UI и записать вопрос |
| «пользователь путается» | наблюдение и мотив | есть ли источник и альтернативы | сохранить буквальный факт |
| «добавим подсказку» | гипотеза и реализация | что должно стать наблюдаемым | спланировать отдельный опыт |
| «так просили» | авторитет и evidence | можно ли сверить контекст | назвать ограничение источника |
| «быстро выпустим» | скорость и полезность | можно ли откатить решение | выбрать обратимый шаг |
Сохраните два независимых артефакта
Первый артефакт — карточка evidence. В ней нет выбранной фичи, пока не появился переход к решению. Второй — список инженерных вариантов: изменение текста, порядка, навигации, состояния или отказ от изменения. Их нельзя хранить одной строкой, потому что список вариантов неизбежно влияет на чтение evidence. На review сначала рассмотрите карточку, потом варианты. Это простое разделение защищает исследование от желания оправдать первый доступный патч.
Официальный материал GOV.UK, доступный в архивном снимке ноября 2022 года, предлагает фокусироваться на том, помогает ли сервис человеку достигнуть нужного исхода, а не на том, что популярно. Для текущей задачи это не готовый KPI и не разрешение игнорировать ограничения продукта. Это полезная проверка формулировки: «какой исход и какая преграда?» сильнее, чем «какой компонент нравится команде?».
Проверьте форму записи локально
CLI не читает трекер и не связывается с продуктом. Он лишь показывает порядок допустимых операций на искусственном объекте: observation без source отклонено; experiment до hypothesis отклонён; после гипотезы план содержит `defer-solution`; rollback удаляет синтетическую запись. Эти ограничения полезны, когда хочется написать «сделаем X, потому что Y» одним предложением. Модель заставляет сначала признать, где отсутствует связка.
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'После этого не надо переписывать все старые задачи. Начните с одной ставки, которая достаточно дорога, чтобы её стоило остановить на час. Добавьте source, перепишите интерпретацию в осторожной форме, укажите альтернативу и назначьте следующий способ узнать больше. Если команда всё равно обязана выпустить изменение по правовому, операционному или иному внешнему ограничению, назовите это отдельно. Вынужденное решение не надо выдавать за исследовательский вывод.
Маршрут: симптом → причина → проверка → действие
- Симптом. В тикете уже есть решение, но нет проверяемого описания проблемы и источника.
- Причина. Наблюдение, его толкование и предпочтение команды записаны одной фразой.
- Проверка. Для каждого утверждения найдите отдельные поля observation, source, interpretation и hypothesis.
- Действие. Сформулируйте следующий опыт, который может подтвердить или опровергнуть гипотезу, не обещая релиз.
- Решение. Только после evidence выберите маленькое изменение либо честно отложите его.
- Rollback. Если запись смешивает уровни, удалите решение и вернитесь к исходному наблюдению; не повышайте предположение до факта.
Проверка перед реализацией
До pull request проведите короткий gate. Может ли другой человек открыть источник? Понимает ли он, какое предложение является наблюдением, а какое — нашей трактовкой? Есть ли формулировка, при которой гипотеза окажется неверной? Описан ли следующий опыт так, чтобы его можно было отменить или изменить? Если на любой вопрос ответ «нет», преждевременно обсуждать компоненты и оценку. Запишите unknown как unknown — это рабочий результат, а не пустая форма.
Не создавайте имитацию точности. Не добавляйте выдуманные цитаты, количество людей, процент проблем или «типичного пользователя», чтобы повысить убедительность карточки. Не переносите единичное наблюдение в правило для всех. Не объявляйте любой существующий лог продуктовым доказательством без владельца и контекста. Когда evidence слаб, корректное действие — выбрать опыт с большей ясностью или снизить размер обратимого изменения, а не сделать текст увереннее.
Rollback и граница утверждений
Rollback — это удалить либо отложить решение, но сохранить вопрос, источник и причины неопределённости. Он нужен, когда между наблюдением и фичей нет проверяемой гипотезы, когда источник недоступен для review или когда предполагаемый опыт проверяет только предпочтение интерфейса. Не используйте rollback как способ стереть несогласные данные. Если evidence законно хранится, его разбор остаётся частью контекста; отменяется только необоснованный переход к реализации.
Статья не устанавливает обязательный процесс исследований, не определяет sample size и не утверждает эффективность конкретного метода. Локальный fixture не даёт права принимать продуктовые решения автоматически. Он лишь делает одну мыслительную ошибку труднее: нельзя назвать решение подтверждённым, если до него не существует отдельно описанного наблюдения, источника, интерпретации и гипотезы.
Следующий шаг и историческая граница
Возьмите ближайшую задачу с готовым UI-ответом и проведите разбор на одном листе. Завершите его либо одним проверяемым следующим опытом, либо статусом `defer-solution`. Источники этой статьи — официальные архивные страницы GOV.UK, доступные в ноябре и декабре 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 года — датированный архивный снимок официального руководства. Он отделяет потребности и исходы пользователя от того, что просто популярно, и описывает исследование как непрерывную работу.