{
  "index": 85,
  "slug": "editorial-2025-08-field-tool-ux-research",
  "title": "Как исследовать UX внутреннего инструмента и не принять мнение за факт",
  "excerpt": "Нейтральная задача, короткая заметка и прослеживаемое решение помогают понять, где внутренний инструмент мешает работе. Разбираем границы согласия, отрицательные ветки и критерий готовности до изменения интерфейса.",
  "contentHtml": "<p>Команда получает просьбу «сделать форму заявки удобнее» и сразу обсуждает новую кнопку. Симптом заметен: в карточке задачи есть цитаты коллег, но нет исходного сценария, точного наблюдения и границы согласия. Непонятно, что человек действительно сделал, а что автор уже объяснил за него.</p>\n<p>Цена ошибки — не только лишняя кнопка. Команда тратит разработку на решение, которое нельзя связать с проблемой. После релиза коллега снова спрашивает, кто отвечает за заявку и что означает её статус. В ответ появляются новые подсказки, ручные обходы и ещё один цикл обсуждений.</p>\n<p><strong>Тезис:</strong> UX-исследование внутреннего инструмента должно передавать в разработку не «инсайт», а короткую проверяемую цепочку: разрешённый материал → нейтральная задача → наблюдение → код → неопределённость → решение → следующий сценарий. Если звено нельзя открыть и проверить, изменение остаётся гипотезой.</p>\n<h2>Механизм: отделить наблюдение от решения</h2>\n<p>Начните с одной рабочей задачи. Например, участник должен найти состояние заявки на доступ и назвать владельца следующего вопроса. Не называйте будущий блок, цвет, кнопку или термин, который хотите проверить. Так человек может показать неожиданный маршрут: сразу найти владельца, задержаться на статусе или использовать внешний список.</p>\n<p>Заранее запишите исходное состояние и условие успеха. В примере карточка содержит номер заявки, статус и поле владельца. Успех означает, что участник назвал следующий вопрос и адресата. Успех не означает, что интерфейс ему понравился, что он работал быстро или что такой путь типичен для всех.</p>\n<p>Следующий слой — согласие. Зафиксируйте цель, допустимый тип evidence, запись, доступ и отзыв. Если разрешены только обезличенные заметки, запись экрана не становится допустимой из-за удобства анализа. Отзыв останавливает работу с материалом по правилам организации. В учебном примере ниже нет реальных людей и данных; он показывает только порядок проверки.</p>\n<p>Наблюдение описывает действие или вопрос. Фраза «курсор остановился у поля owner, затем прозвучал вопрос “кто отвечает после отправки?”» годится как observation. Фраза «человеку непонятен интерфейс» уже содержит интерпретацию. Её можно получить позже как тему, но нельзя выдавать за факт.</p>\n<p>Код даёт наблюдаемой детали короткое имя. <code>owner-unclear</code> означает, что в этом сценарии не найден следующий владелец. Он не объясняет причину, не измеряет частоту и не доказывает, что проблема относится к каждому пользователю. Поле <code>uncertainty</code> сохраняет это ограничение рядом с наблюдением.</p>\n<p>Decision log связывает решение с observation id. Запись может предложить проверить компактное пояснение статуса и владельца. Она не должна говорить «пояснение улучшит UX». Корректная формулировка — «проверить кандидатное изменение на том же сценарии». Это сохраняет отрицательный путь: при сломанной ссылке на наблюдение, withdrawn consent или изменённой задаче нужно остановиться.</p>\n<h2>Учебный пример: одна карточка и два наблюдения</h2>\n<p>Ниже — учебный пример. Все значения условны и служат только для иллюстрации связи между полями. Они не описывают production, не заменяют согласие и не дают результата о реальных пользователях.</p>\n<pre><code>const research = {\n  consent: {\n    evidence: 'de-identified-note',\n    recording: 'not-permitted',\n    withdrawal: 'stop-and-discard'\n  },\n  scenario: {\n    task: 'Найти статус заявки и владельца следующего вопроса',\n    success: 'Назвать следующий вопрос и owner',\n    prompt: 'Покажите, как вы разбираетесь со статусом заявки'\n  },\n  observations: [\n    {\n      id: 'obs-owner-1',\n      statement: 'Курсор остановился у owner; задан вопрос о следующем ответственном',\n      code: 'owner-unclear',\n      uncertainty: 'Одна заметка не показывает частоту и причину'\n    },\n    {\n      id: 'obs-status-1',\n      statement: 'Термин processing прочитан, но не связан со следующим действием',\n      code: 'status-hidden',\n      uncertainty: 'Нельзя заключить, что термин непонятен всем'\n    }\n  ],\n  decision: {\n    observationIds: ['obs-owner-1', 'obs-status-1'],\n    candidateChange: 'Проверить компактный блок status и owner',\n    claim: 'not-established',\n    followUp: 'Повторить тот же нейтральный сценарий'\n  }\n};</code></pre>\n<p>Смысл примера не в формате JavaScript. Важна последовательность. <code>candidateChange</code> не становится задачей на безусловную разработку. Сначала проверяющий открывает оба observation id, читает факты и ограничения, затем проверяет, что follow-up сохраняет цель и исходное состояние.</p>\n<p>Если решение ссылается на <code>obs-owner-2</code>, которого нет, нельзя восстановить происхождение идеи. Не следует угадывать ссылку по похожему тексту. Два безопасных действия — найти исходную заметку или остановить решение и завести новый нейтральный сценарий.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика исследовательского материала перед изменением интерфейса</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>В заметке есть только оценка экрана</td><td>Вопрос подсказал готовое решение</td><td>Прочитать prompt без макета и найти действие участника</td><td>Повторить сценарий нейтральной задачей</td></tr><tr><td>Цитата не связана с задачей</td><td>Запись собрали после обсуждения, без scenario id</td><td>Проверить исходное состояние и условие успеха</td><td>Пометить материал как контекст, не как evidence решения</td></tr><tr><td>Решение ссылается на неизвестный observation</td><td>Заметки и ticket живут раздельно</td><td>Открыть каждый observation id из decision log</td><td>Остановить hand-off и восстановить источник</td></tr><tr><td>Анализ требует запись экрана</td><td>Граница согласия была задана слишком поздно</td><td>Сверить permitted evidence и фактический материал</td><td>Не использовать запись; уточнить policy до нового раунда</td></tr><tr><td>После правки задан другой вопрос</td><td>Изменились цель или исходное состояние</td><td>Сравнить objective, starting state и prompt</td><td>Не объявлять эффект; спланировать сопоставимый follow-up</td></tr><tr><td>Две заметки превращены в «проблему всех»</td><td>Неопределённость потеряна при обобщении</td><td>Прочитать uncertainty рядом с каждой observation</td><td>Оставить claim ограниченным и собрать следующий материал</td></tr></tbody></table></div>\n<h2>Иллюстрация цепочки</h2>\n<figure><img src=\"/assets/editorial/2025/tool-ux-research-2025-research-feedback-loop.svg\" alt=\"Цикл исследования UX внутреннего инструмента: граница согласия ведёт к нейтральному сценарию, затем к наблюдению, коду, неопределённости и решению; решение разрешает следующий сценарий или останавливает процесс\" loading=\"lazy\" /><figcaption>Цепочка не выпускает изменение автоматически. Она показывает, какое звено нужно открыть, чтобы проверить решение, и где процесс должен остановиться.</figcaption></figure>\n<p>Такая схема полезна как контрольная точка проверки. Consent boundary отвечает на вопрос «какой материал можно использовать». Scenario отвечает на вопрос «какую работу наблюдаем». Observation отвечает на вопрос «что произошло». Code помогает сортировать детали. Uncertainty ограничивает вывод. Decision формулирует следующий шаг, а не скрытый результат.</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Назовите рабочую задачу.</strong> Запишите роль, исходное состояние и наблюдаемый критерий окончания. Не начинайте с названия компонента.</li><li><strong>Откройте границу согласия.</strong> Укажите purpose, допустимые заметки или записи, доступ и порядок отзыва. Если boundary неясна, не читайте материал для принятия решения.</li><li><strong>Сформулируйте нейтральный prompt.</strong> Просите показать, как человек выполняет задачу. Уберите подсказку о кнопке, цвете, термине и желаемом ответе.</li><li><strong>Запишите наблюдаемое.</strong> Отделите действие, паузу и вопрос от своей интерпретации. Одна заметка должна содержать одну проверяемую деталь.</li><li><strong>Добавьте code и uncertainty.</strong> Код называйте коротко. Рядом укажите, чего эта заметка не устанавливает: частоту, причину, универсальность или эффект.</li><li><strong>Соберите decision log.</strong> Перечислите observation ids, тему, маленькое кандидатное изменение и claim со скромной силой. Ссылка должна открывать конкретный материал.</li><li><strong>Проверьте отрицательные ветки.</strong> Withdrawn consent, evidence вне разрешённой границы, leading prompt и отсутствующий id дают STOP, а не догадку и не автоматическое исправление.</li><li><strong>Назначьте сопоставимый follow-up.</strong> Сохраните цель, исходное состояние и нейтральную задачу. Отдельно опишите, что можно будет наблюдать и чего результат всё ещё не докажет.</li></ol>\n<h2>Ограничения</h2>\n<p>Нейтральный сценарий не устраняет влияние ведущего. Интонация, порядок действий и знакомство с автором всё равно меняют поведение. Поэтому полезно приглашать отдельного наблюдателя и фиксировать условия, но не называть это устранением bias.</p>\n<p>Короткий журнал не делает выборку представительной. Две заметки могут дать хорошую гипотезу для следующего раунда и не дать оснований для вывода о всей организации. Внутренние пользователи тоже различаются по роли, доступам и опыту. Если эти условия важны для решения, их нужно проверять отдельно.</p>\n<p>Обезличивание не равно отсутствию риска. Имя, команда, заявка и редкое событие могут вместе указать на человека. Реальная организация отдельно определяет владельца данных, хранение, доступ, срок и порядок удаления. В этом материале учебные значения не содержат персональных данных.</p>\n<p>Локальный проверяющий скрипт или таблица может подтвердить структуру записи: наличие полей, допустимый тип evidence и целостность ссылок. Он не проверяет качество разговора, честность заметки, поведение браузера или эффект интерфейса. PASS такой модели означает только прохождение её собственных проверок.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Материал готов к обсуждению кандидатного изменения, если проверяющий за один проход может открыть consent boundary, нейтральный scenario и каждое observation из decision log. Каждое observation описывает действие или вопрос, имеет допустимый code и явную uncertainty. Claim не обещает улучшение. Follow-up сохраняет цель и исходное состояние. При withdrawn consent, недопустимой записи, leading prompt или сломанной ссылке система возвращает STOP.</p>\n<p>Если хотя бы одно условие не выполнено, готово не изменение интерфейса, а список недостающих доказательств. Это полезный результат: команда видит, что нужно проверить дальше, и не маскирует пробел в исследовании новой формулировкой кнопки.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.gov.uk/service-manual/user-research/taking-notes-and-recording-user-research-sessions\" target=\"_blank\" rel=\"noopener noreferrer\">GOV.UK Service Manual: Taking notes and recording user research sessions</a> — официальное руководство связывает заметки и записи с информированным согласием и советует отделять наблюдаемое действие от интерпретации.</li><li><a href=\"https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research\" target=\"_blank\" rel=\"noopener noreferrer\">GOV.UK Service Manual: Getting informed consent for user research</a> — официальное руководство описывает цель согласия, допустимые материалы и связь записи согласия с данными исследования.</li><li><a href=\"https://www.gov.uk/service-manual/user-research/plan-user-research-for-your-service\" target=\"_blank\" rel=\"noopener noreferrer\">GOV.UK Service Manual: Plan user research for your service</a> — руководство рекомендует начинать с приоритетных вопросов и не проводить исследование, на которое команда не сможет ответить действием. Это не универсальная юридическая политика и не доказательство production-эффекта.</li></ul>"
}