8 lines
24 KiB
JSON
8 lines
24 KiB
JSON
{
|
||
"index": 87,
|
||
"slug": "editorial-2025-08-practice-tool-ux-research",
|
||
"title": "UX внутреннего инструмента: как найти проблему до правки интерфейса",
|
||
"excerpt": "Нейтральный сценарий и точная запись действия помогают отличить реальную трудность в рабочем процессе от просьбы добавить ещё одну кнопку. Разбираем consent boundary, воспроизводимый decision log и отрицательные пути.",
|
||
"contentHtml": "<p>Команда просит «сделать внутренний инструмент удобнее». На встрече сразу показывают макет большой кнопки связи с владельцем заявки. Участник кивает, и в задаче появляется вывод: «кнопка нужна». Но это не исследование проблемы. Ведущий проверил реакцию на уже выбранное решение, а не то, как человек выполняет рабочую задачу.</p>\n<p>Цена такой подмены обнаруживается после релиза. Инженер тратит время на локальную правку, а коллега по-прежнему не знает, где искать статус и кому передавать исключение. Новая кнопка увеличивает интерфейс, но не обязательно убирает неопределённость. Следующая встреча начинается с новой цитаты и ещё одного предложения по экрану.</p>\n<p>Надёжнее начать с маршрута задачи. Зафиксируйте, что человек должен получить на выходе, дайте ему нейтральный сценарий и запишите наблюдаемое действие. Затем отделите факт от интерпретации, сформулируйте гипотезу и назначьте следующий тест. Такой порядок не обещает улучшения UX сам по себе. Он делает решение проверяемым и позволяет остановиться, когда данных недостаточно.</p>\n<h2>Сначала вопрос, потом интерфейс</h2>\n<p>У исследования должен быть вопрос, на который команда сможет ответить действием. «Нужна ли большая кнопка?» — плохой вопрос: он заранее выбирает средство. «Что мешает исполнителю назвать следующий шаг по заявке?» — рабочий вопрос: ответом может оказаться термин, порядок полей, недостающий контекст, право доступа или вообще внешний регламент.</p>\n<p>Сценарий должен описывать исходное состояние и ожидаемый результат, но не подсказывать control (элемент управления). Например: «Откройте карточку заявки 1842, назовите её текущее состояние и человека, которому нужно задать следующий вопрос». Критерий успеха — участник называет оба значения или прямо говорит, чего найти не удалось. В сценарии нет слов «нажмите», «оцените макет» и «найдите кнопку связи».</p>\n<p>Внутренний пользователь остаётся участником исследования. Рабочее знакомство с ним не отменяет необходимости объяснить цель, собираемые данные, наблюдение, запись, доступ к результатам, срок хранения и возможность прекратить участие. Если разрешены только обезличенные заметки, запись экрана не добавляется позже «для удобства анализа».</p>\n<h2>Граница доказательства</h2>\n<p>Полезно разделять пять уровней, иначе одна фраза быстро превращается в уверенный диагноз.</p>\n<ul><li><strong>Сценарий</strong> задаёт вход и критерий успеха.</li><li><strong>Наблюдение</strong> описывает то, что можно увидеть или услышать: действие, остановку, вопрос, обход.</li><li><strong>Код</strong> даёт повторяемое имя детали, например <code>owner-not-found</code>. Он группирует записи, но не объясняет причину.</li><li><strong>Тема</strong> объединяет несколько наблюдений в вопрос, например «виден ли следующий ответственный».</li><li><strong>Решение</strong> выбирает следующий ограниченный тест и ссылается на исходные записи. Оно не объявляет интерфейс улучшенным заранее.</li></ul>\n<p>Различие между уровнями можно проверить простой заменой формулировки. «Коллега растерялся» — интерпретация. «Прочитал статус, остановил курсор у поля <code>owner</code> и спросил, кто отвечает после отправки» — наблюдаемая запись. Вторая формулировка не доказывает, что поле плохо названо или что проблема есть у всей команды. Рядом нужно оставить <code>uncertainty</code>: причину, частоту и переносимость на другие роли пока не установили.</p>\n<figure><img src='/assets/editorial/2025/tool-ux-research-2025-evidence-map.svg' alt='Схема UX-исследования внутреннего инструмента: согласие ограничивает заметки, нейтральная задача ведёт к наблюдению, затем к решению и повторному тесту' loading='lazy' /><figcaption>Граница доказательства отделяет разрешённые данные и факт наблюдения от гипотезы. Решение разрешает следующий тест, но не доказывает эффект изменения.</figcaption></figure>\n<p>Согласие — это не формальность рядом с заметкой. Официальное руководство GOV.UK прямо распространяет informed consent и на сотрудников организации, требует сообщать о наблюдении и записи, а при отзыве согласия — остановить участие и удалить собранные материалы по установленному процессу. В вашей компании могут действовать более строгие правила хранения и обработки данных; их нужно проверить до сессии.</p>\n<h2>Исполняемый decision log</h2>\n<p>Ниже учебный пример без реальных людей, заявок, персональных данных и production-результатов. Он проверяет только локальную связь между нейтральным сценарием, наблюдением и решением. Сохраните его как <code>ux-check.mjs</code>, затем выполните команды из следующего блока.</p>\n<pre><code>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}</code></pre>\n<pre><code>node --check ux-check.mjs\nnode ux-check.mjs\n# ожидаемый статус: \"follow-up-only\"</code></pre>\n<p>Код намеренно делает мало. Он не анализирует речь, не считает удобство и не выбирает кнопку. Он лишь проверяет, что решение ссылается на существующее наблюдение. Если заменить <code>observation-01</code> на <code>observation-missing</code>, скрипт напечатает <code>status: \"stop\"</code>. Это воспроизводимая отрицательная ветка: сломанную ссылку нельзя чинить догадкой.</p>\n<p>В рабочем хранилище добавьте к каждой записи идентификатор сессии и сценария, тип разрешённого материала, роль участника и способ обезличивания. Конкретные поля — проектный выбор. Важен инвариант: другой инженер должен восстановить, откуда взялась гипотеза и чего она пока не доказывает.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class='table-scroll'><table><caption>Диагностика слабого UX-доказательства</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>Убрать название кнопки и дать задачу</td><td>Повторить нейтральный сценарий</td></tr><tr><td>В записи есть только цитата</td><td>Не зафиксирован маршрут работы</td><td>Что было видно до и после фразы?</td><td>Добавить действие, состояние и вопрос</td></tr><tr><td>Появился один «инсайт»</td><td>Факт смешали с диагнозом</td><td>Отделить observation, code и uncertainty</td><td>Сформулировать тему как проверяемый вопрос</td></tr><tr><td>Decision не открывает исходную запись</td><td>Ссылка потеряна при пересказе</td><td>Проверить каждый observation id</td><td>Остановить передачу решения и восстановить evidence</td></tr><tr><td>После правки «стало лучше»</td><td>Изменились сценарий или критерий</td><td>Сравнить вход, задачу и outcome</td><td>Повторить сопоставимый тест или снять утверждение</td></tr><tr><td>Для анализа включили запись экрана</td><td>Тип данных расширили после consent</td><td>Разрешены ли запись и наблюдатели?</td><td>Не использовать материал до согласования границы</td></tr></tbody></table></div>\n<p>Таблица не заменяет исследователя. Она нужна как стоп-лист перед тем, как наблюдение попадёт в backlog. Особенно опасно исправлять отсутствие данных автоматически: если человек записал не то, что произошло, добавление кода только сделает ошибку аккуратнее.</p>\n<h2>Отрицательные пути</h2>\n<p>У каждого перехода должен быть отказ. Наведённый вопрос «вам ведь не хватает большой кнопки?» даёт социально ожидаемое согласие, но не подтверждает потребность. Если согласие на запись отсутствует, запись не должна появиться в наборе ради удобства. Если участник отзывает согласие, сессию прекращают, а материалы обрабатывают по согласованной процедуре удаления или ограничения доступа.</p>\n<p>Отсутствующий <code>observationId</code> — это не повод выбрать ближайшую заметку. Исследователь либо восстанавливает исходный материал, либо создаёт новый нейтральный проход. Несопоставимый follow-up тоже не доказывает эффект: другой сценарий, другая роль или изменившийся регламент меняют условия сравнения.</p>\n<p>Есть и менее очевидный отказ: человек завершил задачу, но потратил время на обход в соседней системе. В таком случае интерфейс карточки может быть не источником задержки. Фиксируйте границу наблюдаемого маршрута и не превращайте любой вопрос в задачу на редизайн.</p>\n<h2>Как провести один раунд</h2>\n<ol><li><strong>Назовите решение.</strong> Запишите, что команде нужно решить после раунда: менять интерфейс, уточнять регламент или собирать дополнительные данные.</li><li><strong>Сформулируйте неизвестное.</strong> Превратите просьбу о кнопке в вопрос о действии, состоянии или следующем шаге.</li><li><strong>Определите consent boundary.</strong> Зафиксируйте цель, тип заметки или записи, наблюдателей, доступ, хранение и отзыв. Получите согласие до сбора материала.</li><li><strong>Подготовьте нейтральный сценарий.</strong> Укажите исходное состояние и критерий успеха. Проверьте его на коллеге и удалите подсказки о предполагаемом решении.</li><li><strong>Наблюдайте, а не объясняйте.</strong> Запишите последовательность действий, паузу, вопрос и обход. Не заменяйте их оценкой «растерялся».</li><li><strong>Закодируйте осторожно.</strong> Дайте короткую метку и рядом запишите uncertainty. Один code не показывает частоту и причинность.</li><li><strong>Соберите decision log.</strong> Свяжите гипотезу с существующими идентификаторами наблюдений, укажите claim и следующий сопоставимый сценарий.</li><li><strong>Разберите отрицательные ветки.</strong> Проверьте отозванное consent, наведённый prompt, отсутствующую ссылку и изменившийся критерий. Для каждого случая назначьте STOP и владельца восстановления.</li><li><strong>Проведите follow-up.</strong> Меняйте один проверяемый элемент и сохраняйте исходные условия. Эффект называйте только после заранее определённого критерия.</li></ol>\n<h2>Как читать результат</h2>\n<p>Две одинаковые остановки у поля — повод проверить тему, но не доказательство проблемы всей команды. Участники отличаются ролью, опытом, правами и частотой работы. Для обычного usability-теста небольшая целевая выборка может помочь найти проблемы сценария, но она не даёт репрезентативной оценки всей организации. Если нужен процент пользователей или сравнение вариантов, заранее определите population, метрику и способ набора участников.</p>\n<p>Разделяйте силу утверждений. «Курсор остановился у <code>owner</code>» — факт наблюдения. «Следующий ответственный плохо виден» — гипотеза. «Новый блок сократил время выполнения» — измеряемое утверждение, для которого нужны одинаковый сценарий, единица времени, правило замера и сопоставимые условия. Не подменяйте третье первым.</p>\n<p>Согласие тоже имеет границы. Оно разрешает только те сбор и использование, о которых участника уведомили. Локальная политика может требовать отдельного согласования с владельцем данных, запрета на внешние сервисы расшифровки или меньшего срока хранения. Руководства ниже помогают спланировать исследование, но не заменяют юридическую и security-проверку.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>UX-разбор готов к следующему решению, если другой инженер без устного пересказа видит цель раунда, границу consent, исходное состояние, нейтральный сценарий, наблюдаемое действие, code, uncertainty и все ссылки из decision log. Для гипотезы указан следующий сопоставимый тест. Для отсутствующей записи, отозванного согласия и изменившихся условий существует явная остановка.</p>\n<p>Практический тест занимает несколько минут: передайте коллеге только карточку решения и попросите назвать, что было проверено, чего данные не доказывают и что будет сделано дальше. Если он может пересказать только макет, evidence недостаточно. Если он может повторить сценарий и получить тот же тип записи, решение готово к ограниченному follow-up, но ещё не к заявлению о результате.</p>\n<h2>Ограничения применимости</h2>\n<p>Этот метод не заменяет accessibility-аудит, исследование разных ролей, анализ событий, нагрузочное тестирование, проверку прав или юридическую оценку обработки данных. Он не устанавливает причинность и не сообщает размер эффекта. Внутренний сотрудник может соглашаться из-за служебных отношений; нейтральная формулировка снижает давление, но не устраняет его.</p>\n<p>Код в статье проверяет только целостность ссылок в маленьком объекте JavaScript. Он не является готовым хранилищем research data, системой управления доступом или политикой удаления. Пример синтетический: в нём нет действующего интерфейса и production-метрик. Переносите структуру полей, а не тестовые идентификаторы и не вывод «кнопка нужна».</p>\n<h2>Проверяемые источники</h2><ul><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> — официальное руководство перечисляет цель исследования, собираемые данные, наблюдение и запись, добровольность, срок хранения и отзыв согласия. В нём отдельно сказано, что consent нужен и сотрудникам организации. Это руководство не заменяет policy и legal review вашей компании.</li><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> — официальные рекомендации требуют получить informed consent до заметок или записи и советуют отделять наблюдения от личных интерпретаций. Они не подтверждают учебный пример и не доказывают эффект конкретного интерфейса.</li><li><a href='https://www.gov.uk/service-manual/user-research/plan-round-of-user-research' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: Plan a round of user research</a> — официальная инструкция предлагает заранее определить objectives, problems, assumptions и то, что нужно узнать для следующего решения, а также подготовить сценарий, пробный прогон и время на анализ. Число участников и расписание нужно подбирать под метод и контекст проекта.</li></ul>"
|
||
}
|