AI UX - интерфейс управления неопределённой системой

Обычная форма либо проходит validation, либо нет. Генеративная функция способна вернуть грамматически идеальный, но неверный результат. Пользователю нужны средства сформировать запрос, оценить ответ, исправить его и восстановиться после ошибки.

Цель дизайна - калиброванное доверие: человек опирается на AI там, где система доказала полезность, и проверяет или отклоняет там, где риск выше.

1
явный outcome вместо «спросите что угодно»
3
этапа: ожидание, взаимодействие, recovery
0
необратимых действий без preview

Начните с user outcome и цены ошибки

Одинаковый ответ требует разного UX: идея заголовка допускает быстрый regenerate, перевод лекарства - экспертную проверку, отправка платежа - строгий approval. Опишите решение человека, обратимость и вред ошибки.

Пользователь и контекст: [кто/где]
Job to be done: [результат]
Роль AI: create | recommend | summarize | decide | act
Цена false positive / false negative: [последствия]
Обратимость: [да/нет/окно]
Источники истины: [системы]
Что проверяет человек: [конкретно]
Допустимый отказ: [поведение]
Success metrics: [задача, качество, время]
Harmful acceptance metric: [как измерять]

Четыре роли AI требуют разного контроля

РольИнтерфейсКонтроль
CreateEditable draft и variantsРедактирование до публикации
RecommendOptions, evidence, trade-offsПользователь выбирает
DecideКритерии и review queueAppeal и audit
ActPlan, preview, scopeApproval, receipt, undo

Не маскируйте действие под генерацию текста. Кнопка «Исправить всё» должна ясно показывать, какие файлы или записи изменятся.

Onboarding: покажите возможности и границы до первой ошибки

Microsoft HAX рекомендует заранее объяснять, что система может делать и насколько хорошо. Вместо общего «AI-помощника» покажите 3 - 5 конкретных задач, нужные входы и примеры результата.

AI onboarding
  1. Одна фраза о полезном результате.
  2. Список поддерживаемых задач.
  3. Качественный example input/output.
  4. Явные ограничения и критичные проверки.
  5. Какие данные будут отправлены и куда.
  6. Безопасный sample без личных данных.
  7. Время, стоимость или лимит, если значимы.
  8. Как отменить, исправить и сообщить об ошибке.

Empty state: не заставляйте пользователя изобретать prompt

Пустое поле «Введите запрос» перекладывает дизайн продукта на пользователя. Дайте task templates, структурированные поля и контекстные suggestions. Prompt можно оставить advanced-режимом.

Template

Готовая структура частой задачи.

Fields

Цель, аудитория, ограничения.

Preview

Какие данные войдут в запрос.

Progress: streaming не заменяет статус

Появляющиеся токены создают ощущение скорости, но не объясняют, ищет ли система документы, вызывает ли tools или застряла. Для многошагового процесса показывайте понятные этапы и возможность отмены.

  • «Проверяю доступ к 12 документам» лучше абстрактного spinner.
  • Не показывайте внутреннюю цепочку рассуждений.
  • Отделяйте проверяемые действия от декоративных этапов.
  • Указывайте, можно ли закрыть страницу.
  • Cancel должен останавливать дальнейшие tools и расходы.
  • При долгой задаче предложите notification или background mode.

Editable draft - безопасное состояние по умолчанию

Сгенерированный текст не должен выглядеть опубликованным. Пометьте его как черновик, дайте обычное редактирование, compare с исходником и понятную кнопку применения.

Плохой паттернЛучший паттернПочему
AI сразу заменил текстDiff и ApplyВидны изменения
Только RegenerateРедактирование фрагментаСохраняется полезная часть
Одна версия исчезаетVersion historyМожно сравнить и вернуть
Скрытая публикацияDraft → review → publishЯсный статус

Sources: provenance на уровне утверждения

Список ссылок в конце не показывает, какая поддерживает конкретную фразу. Связывайте citation с утверждением и открывайте точный фрагмент, дату и источник. Показывайте, где evidence отсутствует.

Citation UX
  1. Marker рядом с утверждением.
  2. Название, автор/владелец и дата.
  3. Точный supporting snippet.
  4. Ссылка на исходный документ.
  5. Версия или дата доступа.
  6. Предупреждение об устаревшем источнике.
  7. Различие source evidence и AI inference.
  8. Проверка прав доступа перед открытием.

Uncertainty: не рисуйте процент без калибровки

«Уверенность 92%» выглядит научно, но может быть просто самооценкой модели. Показывайте только сигналы, которые связаны с измеренным качеством: найден ли authoritative source, прошла ли schema, согласны ли независимые проверки, входит ли input в знакомый cohort.

Supported: обязательные утверждения имеют актуальные источники.
Needs review: часть утверждений без достаточного evidence.
Insufficient data: источник не найден или конфликтует.
Out of scope: система не предназначена для этой задачи.
Blocked: действие запрещено policy.
Каждое состояние содержит следующее действие пользователя, а не только цвет.

Показывайте ограничения в момент решения

Предупреждение в onboarding забывается. Контекстное ограничение появляется там, где оно влияет: при загрузке чувствительного файла, перед публикацией, рядом с непроверенной цифрой.

  • Не прячьте критичную оговорку в tooltip.
  • Не используйте один banner для всех рисков.
  • Объясняйте последствие и способ исправления.
  • Не повторяйте warning так часто, чтобы его перестали читать.
  • Используйте текст и структуру, не только цвет.
  • Проверяйте понимание в usability test.

Preview перед side effect

AI-агент должен показывать план в терминах продукта: получатель, сумма, файлы, записи, разрешения. Пользователь подтверждает конкретный scope, а не абстрактное «разрешить агенту действовать».

Перед действиемПоказатьРазрешить изменить
EmailПолучатели, тема, attachmentsТекст и адресаты
CRM updateЗаписи и field diffВыбор изменений
File editPaths и diffИсключить файл
PurchaseТовар, цена, доставкаКоличество/адрес
DeleteТочный список и последствияОтмена до выполнения

Approval: подтверждение должно быть осмысленным

Если диалог показывает десятки одинаковых approval, человек кликает автоматически. Группируйте безопасно связанные действия, повышайте friction пропорционально риску и не смешивайте разные разрешения.

Approval contract
  1. Кто выполняет действие.
  2. Что именно изменится.
  3. В каком tenant/account.
  4. Какие данные уйдут внешней стороне.
  5. Стоимость и необратимость.
  6. Срок действия согласия.
  7. Разовый или повторяемый scope.
  8. Способ отмены и receipt.

Undo, receipt и audit после действия

После выполнения покажите не «Готово», а результат: что изменено, что не удалось, идентификаторы операций и доступные способы восстановления. Undo проектируется вместе с action API.

Undo

Компенсирующая операция или version restore.

Receipt

IDs, scope, time и итог.

Audit

Model, policy, approval и actor.

Errors: сохраняйте работу и предлагайте recovery

Сообщение «Что-то пошло не так» заставляет повторить запрос и может дублировать действие. Классифицируйте ошибку и покажите безопасное следующее действие.

ОшибкаИнтерфейсRecovery
Input invalidКонкретное полеИсправить без потери текста
Rate limitСтатус и времяQueue/повтор позже
Tool partial failureЧто выполненоПовтор только failed steps
Insufficient evidenceЧего не хватаетДобавить source
Policy blockРазрешённое объяснениеБезопасная альтернатива

Feedback: thumbs up недостаточно

Feedback должен связываться с output version и позволять выбрать причину: неверный факт, плохой источник, тон, пропуск, формат, опасное действие. При возможности предложите исправить конкретный фрагмент.

trace_id / output_version
task outcome: accepted | edited | rejected | abandoned
reason codes: fact | source | omission | format | style | safety | latency
edited spans or corrected fields
severity and user-reported impact
consent for using content in improvement workflow
privacy classification
Не отправлять feedback автоматически в training/eval dataset без review.

Personalization и memory: пользователь контролирует сохранённое

Если система помнит предпочтение, покажите, что именно сохранено, откуда и где действует. Дайте временно игнорировать, изменить и удалить. Не превращайте inferred preference в скрытый профиль.

  • Явное подтверждение чувствительных или неоднозначных сведений.
  • Scope: этот документ, проект или аккаунт.
  • TTL и дата последнего использования.
  • Просмотр и редактирование memory.
  • Режим «не использовать память».
  • Удаление производных по policy.
  • Запрет memory расширять permissions.

Accessibility: AI-состояния должны быть доступны без цвета и анимации

Accessibility review
  1. Progress и результат объявляются screen reader без спама.
  2. Streaming content не крадёт фокус.
  3. Все actions доступны с клавиатуры.
  4. Diff понятен без красного/зелёного.
  5. Sources имеют осмысленные link labels.
  6. Uncertainty выражена текстом, не только цветом.
  7. Animation respects reduced motion.
  8. Timeout и approval дают достаточно времени.
  9. Plain-language summary доступен для сложных результатов.

Automation bias и обратная ошибка недоверия

Уверенный тон и polished layout усиливают склонность принять ответ. Но чрезмерные warnings заставляют игнорировать полезную систему. Проверяйте калибровку поведения: принимает ли пользователь корректные рекомендации и отклоняет ли ошибочные.

Correct acceptance

Полезный ответ принят.

Harmful acceptance

Ошибка принята без проверки.

Appropriate override

Человек исправил неверный output.

Метрики AI UX: adoption без результата ничего не доказывает

МетрикаЧто показываетРиск интерпретации
Task successПолучен принятый outcomeНужен quality contract
Correction burdenОбъём/время исправленийРедактирование не всегда плохо
Verification rateПроверены значимые sourcesКлик не равен пониманию
Harmful acceptanceПриняты неверные ответыНужна ground truth
Recovery successЗадача завершена после ошибкиНе считать только retry
Retained useПовторная ценностьРазбивать по cohorts

Usability-тест: проверяйте ошибки, а не только happy path

Дайте участнику корректный ответ, правдоподобную ошибку, отсутствие источника, partial failure и потенциально опасное действие. Наблюдайте, замечает ли он проблему и понимает ли recovery.

AI UX test
  1. Сформулировать ожидание до первого запуска.
  2. Выбрать подходящий template/input.
  3. Понять progress и отменить.
  4. Найти утверждение без evidence.
  5. Сравнить source snippet.
  6. Исправить часть draft без regenerate.
  7. Отклонить опасный action preview.
  8. Восстановиться после partial failure.
  9. Найти receipt и выполнить undo.
  10. Исправить или удалить memory.

Итоговый чек-лист AI UX

AI UX gate
  1. Роль AI и цена ошибки определены.
  2. Возможности и ограничения объяснены заранее.
  3. Empty state предлагает реальные задачи.
  4. Данные и получатели видимы пользователю.
  5. Progress отражает проверяемые этапы и cancel.
  6. Output начинается как editable draft.
  7. Sources связаны с утверждениями.
  8. Uncertainty основана на проверяемых сигналах.
  9. Side effects имеют preview и scoped approval.
  10. После действия есть receipt и undo.
  11. Errors сохраняют ввод и предлагают recovery.
  12. Feedback содержит причину и version.
  13. Memory просматривается и удаляется.
  14. Состояния доступны без цвета и анимации.
  15. Измеряются harmful acceptance и task success.

Хороший AI UX не скрывает несовершенство модели. Он превращает неопределённый output в управляемое сотрудничество человека и системы.

Что такое AI UX?
Это проектирование взаимодействия с вероятностной AI-системой: ожидания, ввод, progress, проверка результата, sources, uncertainty, редактирование, approvals, recovery, feedback и пользовательский контроль.
Как показать, что нейросеть может ошибаться?
Объясните конкретные ограничения до использования и показывайте контекстные сигналы: отсутствие источника, конфликт данных, unfamiliar input или провал validator. Добавляйте понятное следующее действие, а не общий дисклеймер.
Нужно ли показывать процент уверенности AI?
Только если показатель калиброван и связан с измеренной вероятностью ошибки для данного cohort. Самооценку модели нельзя выдавать за надёжную вероятность; лучше показывать evidence и проверяемые статусы.
Почему AI-ответ лучше показывать как черновик?
Draft снижает риск случайной публикации, позволяет исправить фрагмент, сравнить версии и отделяет генерацию от подтверждения человеком. Для важных решений нужен отдельный review/apply шаг.
Как проектировать действия AI-агента?
Покажите plan и точный preview изменения, запросите approval на ограниченный scope, используйте idempotency, верните receipt и обеспечьте undo или компенсирующее действие, если возможно.
Какие источники показывать в AI-ответе?
Связывайте каждое значимое утверждение с точным supporting fragment, владельцем, датой и исходным документом. Различайте evidence и AI inference и соблюдайте права доступа.
Как собирать feedback на AI-функцию?
Связывайте feedback с trace/output version, outcome и reason codes; позволяйте отметить или исправить конкретный фрагмент. Не переносите feedback автоматически в dataset без privacy review и разметки.
Какие метрики использовать для AI UX?
Task success, correction burden, verification, harmful acceptance, appropriate override, recovery success, time saved и retained use по cohorts. Click rate и число генераций сами по себе не доказывают ценность.
← Все статьи блога