Команда просит «сделать внутренний инструмент удобнее». На встрече сразу показывают макет большой кнопки связи с владельцем заявки. Участник кивает, и в задаче появляется вывод: «кнопка нужна». Но это не исследование проблемы. Ведущий проверил реакцию на уже выбранное решение, а не то, как человек выполняет рабочую задачу.
\nЦена такой подмены обнаруживается после релиза. Инженер тратит время на локальную правку, а коллега по-прежнему не знает, где искать статус и кому передавать исключение. Новая кнопка увеличивает интерфейс, но не обязательно убирает неопределённость. Следующая встреча начинается с новой цитаты и ещё одного предложения по экрану.
\nНадёжнее начать с маршрута задачи. Зафиксируйте, что человек должен получить на выходе, дайте ему нейтральный сценарий и запишите наблюдаемое действие. Затем отделите факт от интерпретации, сформулируйте гипотезу и назначьте следующий тест. Такой порядок не обещает улучшения UX сам по себе. Он делает решение проверяемым и позволяет остановиться, когда данных недостаточно.
\nУ исследования должен быть вопрос, на который команда сможет ответить действием. «Нужна ли большая кнопка?» — плохой вопрос: он заранее выбирает средство. «Что мешает исполнителю назвать следующий шаг по заявке?» — рабочий вопрос: ответом может оказаться термин, порядок полей, недостающий контекст, право доступа или вообще внешний регламент.
\nСценарий должен описывать исходное состояние и ожидаемый результат, но не подсказывать control (элемент управления). Например: «Откройте карточку заявки 1842, назовите её текущее состояние и человека, которому нужно задать следующий вопрос». Критерий успеха — участник называет оба значения или прямо говорит, чего найти не удалось. В сценарии нет слов «нажмите», «оцените макет» и «найдите кнопку связи».
\nВнутренний пользователь остаётся участником исследования. Рабочее знакомство с ним не отменяет необходимости объяснить цель, собираемые данные, наблюдение, запись, доступ к результатам, срок хранения и возможность прекратить участие. Если разрешены только обезличенные заметки, запись экрана не добавляется позже «для удобства анализа».
\nПолезно разделять пять уровней, иначе одна фраза быстро превращается в уверенный диагноз.
\nowner-not-found. Он группирует записи, но не объясняет причину.Различие между уровнями можно проверить простой заменой формулировки. «Коллега растерялся» — интерпретация. «Прочитал статус, остановил курсор у поля owner и спросил, кто отвечает после отправки» — наблюдаемая запись. Вторая формулировка не доказывает, что поле плохо названо или что проблема есть у всей команды. Рядом нужно оставить uncertainty: причину, частоту и переносимость на другие роли пока не установили.
Согласие — это не формальность рядом с заметкой. Официальное руководство GOV.UK прямо распространяет informed consent и на сотрудников организации, требует сообщать о наблюдении и записи, а при отзыве согласия — остановить участие и удалить собранные материалы по установленному процессу. В вашей компании могут действовать более строгие правила хранения и обработки данных; их нужно проверить до сессии.
\nНиже учебный пример без реальных людей, заявок, персональных данных и production-результатов. Он проверяет только локальную связь между нейтральным сценарием, наблюдением и решением. Сохраните его как ux-check.mjs, затем выполните команды из следующего блока.
const scenario = {\n id: 'scenario-request-owner-v1',\n prompt: 'Найдите статус заявки и следующего ответственного',\n success: 'названы status и next owner',\n};\n\nconst observations = [\n {\n id: 'observation-01',\n scenarioId: scenario.id,\n action: 'прочитан status; курсор остановился у owner',\n question: 'Кто отвечает после отправки?',\n code: 'owner-not-found',\n uncertainty: 'неизвестны причина, частота и роль участника',\n },\n];\n\nconst decision = {\n observationIds: ['observation-01'],\n hypothesis: 'проверить видимость следующего ответственного',\n nextCheck: 'повторить тот же сценарий без подсказки',\n claim: 'эффект не установлен',\n};\n\nconst missing = decision.observationIds.filter(\n (id) => !observations.some((item) => item.id === id),\n);\n\nif (missing.length > 0 || !scenario.id || !decision.nextCheck) {\n console.log(JSON.stringify({ status: 'stop', missing }, null, 2));\n} else {\n console.log(JSON.stringify({ status: 'follow-up-only', decision }, null, 2));\n}node --check ux-check.mjs\nnode ux-check.mjs\n# ожидаемый статус: \"follow-up-only\"Код намеренно делает мало. Он не анализирует речь, не считает удобство и не выбирает кнопку. Он лишь проверяет, что решение ссылается на существующее наблюдение. Если заменить observation-01 на observation-missing, скрипт напечатает status: \"stop\". Это воспроизводимая отрицательная ветка: сломанную ссылку нельзя чинить догадкой.
В рабочем хранилище добавьте к каждой записи идентификатор сессии и сценария, тип разрешённого материала, роль участника и способ обезличивания. Конкретные поля — проектный выбор. Важен инвариант: другой инженер должен восстановить, откуда взялась гипотеза и чего она пока не доказывает.
\n| Симптом | Вероятная причина | Проверка | Действие |
|---|---|---|---|
| Все согласились с макетом | Вопрос подсказал решение | Убрать название кнопки и дать задачу | Повторить нейтральный сценарий |
| В записи есть только цитата | Не зафиксирован маршрут работы | Что было видно до и после фразы? | Добавить действие, состояние и вопрос |
| Появился один «инсайт» | Факт смешали с диагнозом | Отделить observation, code и uncertainty | Сформулировать тему как проверяемый вопрос |
| Decision не открывает исходную запись | Ссылка потеряна при пересказе | Проверить каждый observation id | Остановить передачу решения и восстановить evidence |
| После правки «стало лучше» | Изменились сценарий или критерий | Сравнить вход, задачу и outcome | Повторить сопоставимый тест или снять утверждение |
| Для анализа включили запись экрана | Тип данных расширили после consent | Разрешены ли запись и наблюдатели? | Не использовать материал до согласования границы |
Таблица не заменяет исследователя. Она нужна как стоп-лист перед тем, как наблюдение попадёт в backlog. Особенно опасно исправлять отсутствие данных автоматически: если человек записал не то, что произошло, добавление кода только сделает ошибку аккуратнее.
\nУ каждого перехода должен быть отказ. Наведённый вопрос «вам ведь не хватает большой кнопки?» даёт социально ожидаемое согласие, но не подтверждает потребность. Если согласие на запись отсутствует, запись не должна появиться в наборе ради удобства. Если участник отзывает согласие, сессию прекращают, а материалы обрабатывают по согласованной процедуре удаления или ограничения доступа.
\nОтсутствующий observationId — это не повод выбрать ближайшую заметку. Исследователь либо восстанавливает исходный материал, либо создаёт новый нейтральный проход. Несопоставимый follow-up тоже не доказывает эффект: другой сценарий, другая роль или изменившийся регламент меняют условия сравнения.
Есть и менее очевидный отказ: человек завершил задачу, но потратил время на обход в соседней системе. В таком случае интерфейс карточки может быть не источником задержки. Фиксируйте границу наблюдаемого маршрута и не превращайте любой вопрос в задачу на редизайн.
\nДве одинаковые остановки у поля — повод проверить тему, но не доказательство проблемы всей команды. Участники отличаются ролью, опытом, правами и частотой работы. Для обычного usability-теста небольшая целевая выборка может помочь найти проблемы сценария, но она не даёт репрезентативной оценки всей организации. Если нужен процент пользователей или сравнение вариантов, заранее определите population, метрику и способ набора участников.
\nРазделяйте силу утверждений. «Курсор остановился у owner» — факт наблюдения. «Следующий ответственный плохо виден» — гипотеза. «Новый блок сократил время выполнения» — измеряемое утверждение, для которого нужны одинаковый сценарий, единица времени, правило замера и сопоставимые условия. Не подменяйте третье первым.
Согласие тоже имеет границы. Оно разрешает только те сбор и использование, о которых участника уведомили. Локальная политика может требовать отдельного согласования с владельцем данных, запрета на внешние сервисы расшифровки или меньшего срока хранения. Руководства ниже помогают спланировать исследование, но не заменяют юридическую и security-проверку.
\nUX-разбор готов к следующему решению, если другой инженер без устного пересказа видит цель раунда, границу consent, исходное состояние, нейтральный сценарий, наблюдаемое действие, code, uncertainty и все ссылки из decision log. Для гипотезы указан следующий сопоставимый тест. Для отсутствующей записи, отозванного согласия и изменившихся условий существует явная остановка.
\nПрактический тест занимает несколько минут: передайте коллеге только карточку решения и попросите назвать, что было проверено, чего данные не доказывают и что будет сделано дальше. Если он может пересказать только макет, evidence недостаточно. Если он может повторить сценарий и получить тот же тип записи, решение готово к ограниченному follow-up, но ещё не к заявлению о результате.
\nЭтот метод не заменяет accessibility-аудит, исследование разных ролей, анализ событий, нагрузочное тестирование, проверку прав или юридическую оценку обработки данных. Он не устанавливает причинность и не сообщает размер эффекта. Внутренний сотрудник может соглашаться из-за служебных отношений; нейтральная формулировка снижает давление, но не устраняет его.
\nКод в статье проверяет только целостность ссылок в маленьком объекте JavaScript. Он не является готовым хранилищем research data, системой управления доступом или политикой удаления. Пример синтетический: в нём нет действующего интерфейса и production-метрик. Переносите структуру полей, а не тестовые идентификаторы и не вывод «кнопка нужна».
\n