![\"Схема](\"/assets/editorial/2025/tool-ux-research-2025-research-feedback-loop.svg\")
Запрос «сделайте форму заявки удобнее» ещё не описывает проблему. Внутри команды его легко превратить в решение: добавить кнопку, перенести поле или переименовать статус. Но пока никто не видел, как сотрудник выполняет задачу, неизвестно, мешает ли форма, правила доступа, неполный контекст или внешний список, которым пользуются вместо неё.
\nЦена поспешной правки измеряется не только часами разработки. Команда может улучшить экран и оставить прежний обход: сотрудник по-прежнему спрашивает в чате, кто владеет заявкой, или открывает несколько систем, чтобы понять статус. Поэтому результат исследования должен быть меньше и строже, чем «инсайт»: задача с исходным состоянием, наблюдаемое действие, ограниченный вывод и следующий проверяемый шаг.
\nГлавный принцип: отделяйте то, что человек сделал или сказал, от объяснения, которое предложил исследователь. Тогда другая команда сможет открыть исходную заметку, проверить связь с решением и понять, что пока не доказано.
\nНачинайте не с макета и не с названия компонента, а с операции, которую человек должен выполнить. Для внутреннего инструмента «Заявки на доступ» рабочий вопрос может звучать так: может ли сотрудник по карточке заявки понять текущий статус и назвать владельца следующего вопроса? Такой вопрос задаёт объект наблюдения, но не подсказывает ответ.
\nДо сессии запишите три вещи. Исходное состояние — открыта карточка с номером заявки, статусом processing и полем owner. Задача — «Покажите, как вы разберётесь с этой заявкой и кому зададите следующий вопрос». Условие успеха — участник называет статус своими словами и адресата следующего вопроса. Скорость, симпатия к интерфейсу и универсальность решения в это условие не входят.
Ведущий не должен произносить название предполагаемой проблемы: «Найдите кнопку владельца» уже подталкивает к нужному элементу. Нейтральная формулировка оставляет место для реального маршрута: человек может открыть историю, прочитать справку, воспользоваться поиском или сразу обратиться в чат.
\nЗаметка о наблюдении отвечает на вопрос «что произошло». Вывод отвечает на вопрос «какую тему стоит проверить дальше». Решение отвечает на вопрос «какое небольшое изменение мы готовы испытать». Если соединить эти уровни в одной фразе, гипотеза начинает выглядеть установленным фактом.
\nЗапись «участник 20 секунд смотрел на поле owner и спросил: “Кто отвечает после отправки?”» содержит наблюдаемые детали. Запись «владелец непонятен» — уже краткий вывод. Он может быть полезен, но его нужно пометить как интерпретацию и связать с конкретным наблюдением. По одному случаю нельзя заключить, что поле непонятно всем сотрудникам или что причина — именно в дизайне.
В официальном руководстве GOV.UK заметки рекомендуют строить вокруг наблюдений, а каждую запись — вокруг одной детали, которую можно анализировать отдельно. Это не делает исследование объективным автоматически: ведущий, порядок вопросов, роль участника и знакомство с процессом всё равно влияют на результат. Задача формата — сделать влияние и неопределённость видимыми.
\nРассмотрим учебную сессию без реальных людей и данных. Участник знает, что ему нужно получить доступ к отчёту, но не знает внутреннюю маршрутизацию. Карточка содержит статус processing, дату отправки и имя команды-владельца. Мы просим его показать следующий шаг, не объясняя термины заранее.
Первое наблюдение: участник открывает историю изменений, видит, что заявка передана в другую команду, и завершает задачу. Здесь интерфейс мог быть непривычным, но условие успеха выполнено. Второе наблюдение: участник читает processing, затем спрашивает, нужно ли ждать или написать владельцу. Здесь виден вопрос о следующем действии, но его причина пока не установлена. Это может быть термин, отсутствие срока, организационное правило или отсутствие ссылки на владельца.
Разница влияет на решение. Для первого случая не следует автоматически менять форму: успешное действие само по себе не доказывает удобство и не требует исправления. Для второго можно проверить кандидатный блок «текущий статус, ожидаемое действие, владелец», сохранив исходный сценарий. После проверки мы сравним не впечатление, а достижение того же условия успеха и характер оставшихся вопросов.
\nДля каждой записи достаточно небольшого контракта. sessionId и participantId связывают заметку с сессией, но не должны содержать имя или редкий идентификатор в открытом виде. statement хранит действие или дословный короткий вопрос. code помогает группировать записи, но не объявляет причину. uncertainty фиксирует, чего наблюдение не доказывает.
Согласие — часть контракта, а не формальность перед выгрузкой. До заметок или записи участник должен знать цель, собираемые данные, формат сессии, наблюдателей, использование и срок хранения. Сотрудник организации не исключение: руководство GOV.UK прямо требует информированного согласия от всех участников, включая работников своей организации. Для конкретной компании дополнительно действуют её политика данных и применимое право.
\n{\n \"consent\": {\n \"informed\": true,\n \"evidence\": \"consent-2025-08-014\",\n \"allowed\": [\"de-identified-notes\"],\n \"recording\": false,\n \"withdrawal\": \"stop-and-delete\"\n },\n \"scenario\": {\n \"id\": \"access-request-status-v1\",\n \"startingState\": \"Карточка заявки: status=processing, owner=Platform\",\n \"task\": \"Показать следующий шаг и назвать владельца вопроса\",\n \"success\": \"Участник назвал действие и адресата без подсказки\"\n },\n \"observations\": [\n {\n \"id\": \"obs-014-01\",\n \"statement\": \"Участник открыл историю заявки и нашёл команду-владельца\",\n \"code\": \"owner-found\",\n \"uncertainty\": \"Одна сессия не показывает частоту и влияние маршрута\"\n },\n {\n \"id\": \"obs-014-02\",\n \"statement\": \"После чтения processing участник спросил, ждать ли или писать владельцу\",\n \"code\": \"next-action-unclear\",\n \"uncertainty\": \"Причина может быть в термине, сроке или процессе\"\n }\n ],\n \"decision\": {\n \"observationIds\": [\"obs-014-02\"],\n \"candidateChange\": \"Проверить блок status, next action и owner\",\n \"claim\": \"hypothesis-only\",\n \"followUpScenario\": \"access-request-status-v2\"\n }\n}Значения в примере проектные. В вашей системе другими будут формат идентификаторов, срок хранения, перечень наблюдателей и правила удаления. Существенна не форма JSON, а трассировка: каждое решение ссылается на существующую заметку, заметка — на конкретный сценарий, а согласие ограничивает, какой материал можно использовать.
\nСтруктурный чекер не оценивает правдивость разговора. Он ловит более простые ошибки hand-off: ссылку на отсутствующее наблюдение или решение после отозванного согласия. Сохраните JSON выше в файл research-log.json, затем выполните команду из той же папки:
node -e \"const fs=require('node:fs'); const r=JSON.parse(fs.readFileSync('research-log.json','utf8')); const ids=new Set(r.observations.map(o=>o.id)); const ok=r.consent.informed && r.consent.recording===false && r.decision.observationIds.every(id=>ids.has(id)); if(!ok) { console.error('STOP: проверьте согласие и observationIds'); process.exit(1); } console.log('PASS: структурные ссылки и граница записи проверены');\"Ожидаемый результат — строка PASS. Если заменить obs-014-02 на несуществующий идентификатор, команда завершится с кодом 1. Это полезная автоматическая защита, но не доказательство качества исследования: команда не видит, действительно ли участник произнёс вопрос, не проверяет анонимность и не устанавливает причинность.
Перед передачей задачи разработчику проверьте контракт вручную: откройте каждый observationId, сравните startingState и task, а затем сформулируйте ожидаемое наблюдение для следующего раунда. Если ссылка потеряна, не угадывайте её по похожему тексту. Восстановите источник или вернитесь к нейтральной задаче.
| Симптом | Возможная причина | Проверка | Действие |
|---|---|---|---|
| В заметке есть только «неудобно» | Оценку записали вместо действия | Найти шаг, паузу, вопрос и исходное состояние | Пометить как гипотезу; повторить нейтральный сценарий |
| Участник нашёл нужный путь, но команда хочет менять экран | Предположение о проблеме приняли за наблюдение | Сверить условие успеха и фактический маршрут | Не менять интерфейс без отдельного основания |
| Два человека задали один вопрос | Возможен повторяющийся барьер, но выборка мала | Сравнить роли, условия, формулировки и контекст | Проверить гипотезу на сопоставимой группе |
| Решение ссылается на неизвестный observationId | Источник потерян при передаче | Запустить структурный чекер и открыть журнал | STOP: восстановить источник или завести новую заметку |
| После сессии отозвано согласие | Материал больше нельзя использовать в прежнем объёме | Найти все связанные заметки, записи и копии | Остановить анализ и удалить данные по установленной процедуре |
| Изменился текст, но не задача | Сравнение стало несопоставимым | Сверить task, startingState и критерий успеха | Не приписывать эффект; назначить повторную проверку |
Следующий раунд не обязан копировать старый экран. Он обязан сохранить вопрос, исходное состояние и критерий успеха. В нашем кейсе можно заменить только представление статуса на короткий блок: «Обрабатывается → дождитесь ответа Platform до указанного срока → вопрос задайте владельцу Platform». Сценарий остаётся тем же, а в журнале появляется версия access-request-status-v2.
Сравнивайте наблюдаемые результаты по заранее выбранным полям: назван ли следующий шаг, найден ли владелец, какая подсказка потребовалась, возник ли новый ошибочный маршрут. Не объявляйте успехом одну эмоциональную реплику и не сравнивайте сессию в новом состоянии с воспоминанием о старом.
\nДля веб-инструмента исследование дополняет, а не заменяет проверку доступности. WCAG 2.2 содержит тестируемые критерии и рекомендует сочетать автоматизированную проверку с оценкой человеком, но сам стандарт не покрывает все потребности людей с инвалидностью. Поэтому после гипотезы проверьте клавиатурный маршрут, видимый фокус, названия полей и сообщения об ошибках по применимым критериям, а затем включите подходящих пользователей в исследование.
\nДве или три сессии могут выявить непредвиденный маршрут и дать хорошую гипотезу. Они не дают статистической оценки частоты и не доказывают, что изменение ускорит работу всей организации. Если решение дорогое или рискованное, добавьте исследование других ролей, количественную метрику и проверку в реальном процессе.
\nНейтральный вопрос снижает подсказку, но не устраняет bias. Участник может стараться угодить ведущему, а наблюдатель — замечать только ожидаемый барьер. Помогают второй наблюдатель, единый сценарий, запись условий и отдельная маркировка факта и вывода. Это способы снизить риск, а не обещание полной объективности.
\nОбезличенная заметка всё равно может раскрыть человека, если в ней соединены редкая роль, дата, заявка и необычное событие. Не собирайте лишние атрибуты, ограничивайте доступ и удаляйте копии по правилам организации. Если согласие отозвано, нельзя продолжать анализ «только потому, что запись уже сделана»: GOV.UK рекомендует остановиться и удалить собранные исследовательские данные, а конкретный порядок должен соответствовать вашей политике и закону.
\nГайд GOV.UK полезен как практическая методика, но не является юридической политикой для другой страны или компании. Требования к согласию, хранению, удалению и передаче данных нужно согласовать с ответственным за защиту данных и применимыми нормативными требованиями.
\nПеред hand-off задайте пять вопросов. Есть ли у решения одна рабочая задача и измеримый критерий успеха? Можно ли открыть каждую ссылку из решения на конкретное наблюдение? Отделены ли действие, интерпретация и гипотеза? Разрешён ли фактически используемый тип данных? Сохранит ли следующий раунд исходное состояние и цель?
\nЕсли на любой вопрос ответ «нет», готово не изменение интерфейса, а следующий исследовательский шаг. Это не задержка ради процесса: команда перестаёт тратить разработку на неизвестную причину и получает короткий список того, что нужно проверить.
\n