Команда получает просьбу «сделать внутренний инструмент удобнее». На встрече сразу показывают макет большой кнопки связи с владельцем заявки. Участник кивает, а в заметке появляется фраза «кнопка нужна». Это наблюдаемый симптом: исследователь проверяет уже выбранное решение, а не работу по задаче.
\nЦена ошибки видна после релиза. Инженер тратит время на локальную правку. Коллега по-прежнему не знает, где искать статус или кому передать исключение. Новая кнопка добавляет поверхность, но не убирает неопределённость. Следующая встреча снова начинается с цитаты и нового предложения по интерфейсу.
\nТезис простой: UX внутреннего инструмента нужно проверять через маршрут задачи. Сначала зафиксируйте, что человек пытается сделать. Затем дайте нейтральный сценарий и запишите видимое действие, вопрос и неизвестное. Только после этого формулируйте изменение как гипотезу. Такое исследование не обещает эффект. Оно делает решение проверяемым и останавливает правку, если evidence не хватает.
\nУ рабочего разбора есть четыре разных объекта. Сценарий задаёт исходное состояние и понятный результат. Наблюдение описывает действие или вопрос в этом сценарии. Тема объединяет несколько наблюдений, но не объясняет их автоматически. Решение предлагает следующий тест, а не объявляет интерфейс улучшенным.
\nНапример, сценарий звучит так: «Найдите текущее состояние одной заявки и назовите владельца следующего вопроса». Исходное состояние известно: карточка содержит номер, статус и поле владельца. Успех тоже известен: человек называет следующий вопрос и ответственного. В сценарии нет слов «нажмите кнопку связи» и «оцените новый блок». Он допускает ответ, неудобный автору макета.
\nСогласие задаёт границу материала. Перед сессией участник должен понимать цель, собираемые данные, наблюдение или запись, использование результата и возможность остановиться. Для внутреннего инструмента это важно не меньше, чем для внешнего сервиса: знакомство с коллегой не отменяет добровольность. Если разрешены только обезличенные заметки, не добавляйте запись экрана «для удобства анализа».
\nНаблюдение должно быть скучным и точным: «прочитал статус, остановил курсор у поля owner, спросил, кто отвечает после отправки». Запись «растерялся» уже содержит трактовку. Код owner-unclear может помочь найти похожие записи, но не объясняет причину и не показывает частоту. Рядом укажите uncertainty: «неизвестно, не виден ли владелец, непонятен ли термин или не хватает контекста заявки».
Короткая структура защищает от пересказа встречи. Её можно хранить в задаче исследования или в согласованном хранилище заметок. Учебный пример ниже не содержит реальных людей, заявок и production-данных.
\nconst observation = {\n scenario: 'find-status-and-next-owner',\n action: 'прочитан status; курсор остановился у owner',\n question: 'кто отвечает после отправки?',\n code: 'owner-unclear',\n uncertainty: 'неизвестна причина и частота вопроса',\n};\n\nconst decision = {\n evidence: ['observation-01'],\n hypothesis: 'проверить пояснение status и next owner',\n nextCheck: 'повторить тот же сценарий без подсказки',\n claim: 'эффект не установлен',\n};В этом примере hypothesis не превращается в задачу «срочно добавить блок». Сначала нужно решить, что именно проверять: видимость владельца, язык статуса, порядок полей или отсутствие перехода к следующему действию. Если одна заметка не различает варианты, следующий шаг — ещё один нейтральный сценарий, а не выбор идеи по громкости голоса.
| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| Все соглашаются с макетом | Вопрос подсказывает решение | Убрать название кнопки и дать задачу | Переписать сценарий без UI-ответа |
| В заметке есть только цитата | Не записан маршрут работы | Спросить, что было видно до и после фразы | Добавить действие, вопрос и исходное состояние |
| Появился один «инсайт» | Факт смешали с объяснением | Отделить observation, code и uncertainty | Назвать тему как гипотезу |
| Решение нельзя перепроверить | Нет ссылки на исходную заметку | Открыть каждый evidence id | Остановить hand-off и восстановить связь |
| После правки «стало лучше» | Изменились сценарий и вопрос | Сравнить исходное состояние и критерий успеха | Повторить тот же маршрут или признать сравнение несостоятельным |
Представим, что ведущий начинает так: «Вам ведь не хватает большой кнопки “Написать владельцу”?» Участник может согласиться из вежливости. Даже несогласие будет слабым: вопрос уже сузил пространство ответов. Такой материал нельзя использовать как подтверждение кнопки.
\nПравильный отрицательный путь должен останавливать решение. Если сценарий ведущий, согласие не подтверждено, заметка выходит за разрешённую границу или decision ссылается на несуществующее наблюдение, исследование не переходит к изменению интерфейса. Не надо лечить пробел догадкой. Верните материал владельцу и запросите новый нейтральный проход.
\nТо же правило действует для отзыва согласия. Если участник остановился, прекратите сессию и примените согласованный процесс удаления или ограничения материалов. Код в задаче может обозначить статус «stop», но он не заменяет политику хранения и юридическую проверку. Учебная схема показывает порядок принятия решения, а не готовую процедуру для организации.
\nДве заметки с одинаковым вопросом — повод исследовать тему, но не доказательство проблемы всей команды. Даже несколько повторов не устанавливают причинность сами по себе. Участники могут отличаться ролью, опытом, правами доступа и частотой работы. Внутренний инструмент также связан с регламентом, данными и соседними системами. Интерфейс не всегда является источником задержки.
\nРазделяйте три утверждения. «Человек остановился у owner» — наблюдение. «Следующий ответственный плохо виден» — рабочая гипотеза. «Новый блок сократил время» — измеряемое утверждение, для которого нужны заранее определённая метрика, условия сравнения и достаточный объём данных. Не подменяйте третье первым.
\nЕсть и социальное ограничение. Коллега может помогать автору, потому что знает его по работе. Нейтральная формулировка, пауза и отсутствие макета уменьшают давление, но не устраняют его. Поэтому молчаливое действие, обход и вопрос часто полезнее оценки «нравится». Если человек хвалит новый блок, но не завершает задачу, фиксируйте маршрут.
\nМатериал готов к следующему шагу, когда другой инженер без устного пересказа может восстановить цепочку: цель и consent boundary, исходное состояние, нейтральный сценарий, наблюдаемое действие, code, uncertainty, ссылка на decision и критерий следующей проверки. В decision явно написано, чего данные не доказывают. Отрицательные ветки имеют остановку и владельца восстановления.
\nМатериал не готов, если в нём осталась только удачная цитата, название любимой кнопки, диагноз пользователя или обещание production-эффекта. В этом случае задача должна вернуться к исследовательскому вопросу. Практический тест занимает несколько минут: удалите автора записи и попросите коллегу объяснить, что было проверено и что будет проверено дальше. Если он может назвать только макет, evidence не выдерживает hand-off.
\nМетод не заменяет доступность, исследование с разными ролями, анализ событий, нагрузочное тестирование и проверку прав доступа. Он не даёт репрезентативную выборку и не устанавливает юридические требования к данным. Руководства ниже описывают общие принципы user research; правила вашей организации могут быть строже. Примеры в статье учебные. Они не сообщают production-результаты и не доказывают, что конкретная кнопка улучшит внутренний инструмент.
\n