Agentic UX: как проектировать интерфейсы когда AI действует за пользователя

Пользователь нажимает «Забронируй мне перелёт в Лиссабон на следующие выходные подешевле» — и уходит наливать кофе. Возвращается через минуту, а агент уже сравнил три агрегатора, выбрал рейс с пересадкой в Мадриде, потому что разница 80 евро, и ждёт подтверждения оплаты. Дизайнер этого экрана не рисовал ни форму поиска, ни фильтры, ни карточку результата в привычном виде. Он проектировал доверие, контроль и точки выхода.

Agentic UX — это не «чат с ИИ сбоку от продукта». Это сдвиг роли пользователя с исполнителя на заказчика. Раньше мы оптимизировали путь «клик — клик — результат». Теперь нужно проектировать делегирование: как пользователь ставит задачу, как наблюдает за её выполнением, как вмешивается, когда агент собирается сделать глупость, и как понимает, что именно произошло, когда всё закончилось.

Проблема в том, что 90% паттернов классического UX перестают работать. Прогресс-бар не отражает работу, в которой агент может пересмотреть свой план посередине. Кнопка «Отмена» в мире, где агент уже отправил три API-запроса и начал четвёртый, означает совсем не то, что раньше. А привычное «покажем результат — пользователь решит» превращается в стену текста, через которую никто не продерётся.

## Что меняется в самой модели взаимодействия

Классический интерфейс — это набор инструментов. Пользователь сам собирает результат, нажимая на кнопки. Agentic-интерфейс — это разговор о намерении и постоянная сверка: правильно ли я тебя понял, можно ли я сделаю вот это, вот что получилось.

### Три новые сущности на экране

В привычном UI были экраны, состояния и действия. В agentic-продукте появляются ещё три вещи, которые нужно явно показывать:

• Намерение — как агент понял задачу. Не сырой prompt, а его интерпретация: «Ищу перелёт туда-обратно, 2 пассажира, эконом, гибкость по датам ±1 день».
• План — последовательность шагов, которую агент собирается выполнить. Хотя бы крупными мазками.
• Граница автономии — что агент сделает сам, а где остановится и спросит.

Если этих трёх вещей нет на экране в явном виде — пользователь не доверяет агенту. И правильно делает.

### Анти-паттерн: «чёрный ящик с спиннером»

Самая частая ошибка ранних agentic-фич — показать одну строку «Думаю...» и крутящийся индикатор на 40 секунд. Пользователь не знает: агент работает или завис, его задачу поняли правильно или нет, можно ли что-то поправить или поздно.

Решение не в том, чтобы заменить спиннер на «красивую анимацию». А в том, чтобы стримить шаги: «Проверяю Aviasales → нашёл 12 вариантов → отбрасываю с пересадками больше 4 часов → сравниваю с Skyscanner». Каждый шаг — точка, где можно вмешаться.

## Проектируем намерение: как агент показывает, что он понял

Это первый и самый недооценённый экран в agentic-флоу. Пользователь написал расплывчатую фразу — агент должен её переформулировать в структуру и показать обратно. До того как начнёт действовать.

### Чеклист хорошего экрана подтверждения намерения

• Видны ключевые параметры задачи в структурированном виде, а не пересказом
• Каждое поле редактируется в один клик — без возврата в чат
• Явно показано, что агент додумал сам (например, «эконом» по умолчанию)
• Видно, какие данные агент возьмёт из контекста (профиль, история, календарь)
• Есть «Поехали» и «Стоп, не так» — две равноценные кнопки, а не одна основная

### Сценарий: бронирование встречи

Пользователь: «Договорись с Аней о созвоне на следующей неделе». Плохой агент сразу шлёт письмо с тремя слотами. Хороший — показывает карточку: «Аня Иванова (из последней переписки 12 ноября), 30 минут, Google Meet, твои свободные окна вт/ср/чт после 14:00, письмо на русском в твоём обычном тоне». И только потом — кнопка «Отправить».

Разница — в цене ошибки. Письмо не той Ане, отправленное от твоего имени, дороже, чем лишний экран подтверждения.

## Уровни автономии: не всё стоит делать самому

Главная проектная развилка — где агент действует молча, где спрашивает, а где вообще не имеет права решать. Это не настройка в недрах профиля, а часть основного интерфейса.

Удобно держать в голове три уровня:

• Авто — обратимые и дешёвые действия: поискать, отфильтровать, составить черновик, переформатировать таблицу.
• С подтверждением — действия с внешним эффектом: отправить письмо, забронировать, списать деньги, изменить чужой календарь.
• Только вручную — необратимое и чувствительное: удаление данных, публикация, юридически значимые операции, всё с деньгами выше порога.

Граница между уровнями должна быть видна пользователю и настраиваема. Иначе он либо отключит агента полностью после первого инцидента, либо начнёт перепроверять каждый шаг — и тогда смысл агента теряется.

### Вопросы для ревью agentic-флоу

• Что произойдёт, если агент ошибётся на этом шаге? Это обратимо?
• Поймёт ли пользователь через минуту, что именно агент уже сделал?
• Есть ли способ остановить агента в середине, не теряя контекста?
• Видно ли, какие внешние системы агент трогает прямо сейчас?

Короткий итог сегмента: agentic-интерфейс — это не «чат поверх продукта», а пересборка ролей. Пользователь становится заказчиком, агент — исполнителем, а дизайнер проектирует прозрачность намерения, видимый план и границы автономии. Дальше разберём, как показывать процесс работы, как делать осмысленные точки вмешательства и что делать с ошибками агента.

## Как показывать процесс: стрим вместо спиннера

Когда агент начал действовать, главный вопрос пользователя — «он вообще ещё жив?». Не «расскажи мне про архитектуру LLM», а буквально: идёт работа или повисло. Поэтому процесс надо стримить — выдавать шаги по мере того, как они происходят, а не копить и показывать готовый результат.

Стрим — это не лог разработчика. Это нарратив для заказчика, у которого мало времени.

### Что стримить, а что нет

• Стримить: какой инструмент агент сейчас вызывает, какой источник проверяет, какое промежуточное решение принял.
• Не стримить: сырые токены модели, внутренние reasoning-цепочки, JSON-ответы API, отладочные ошибки ретраев.

Полезное правило: если шаг нельзя описать одной короткой фразой на языке задачи пользователя — он не идёт в основной поток. Его можно спрятать в раскрывающийся «технический лог» для тех, кому надо.

### Анти-паттерн: бесконечный поток мыслей

Обратная крайность — вывалить весь chain-of-thought на экран. Пользователь видит десять экранов рассуждений, теряет нить, не понимает где он в этом потоке, и закрывает вкладку. Стрим должен быть плотным: пять-семь осмысленных шагов лучше, чем пятьдесят строк размышлений.

Хорошая эвристика — каждый шаг это глагол действия и объект: «Сравниваю цены у трёх поставщиков», «Формирую черновик письма», «Проверяю свободные слоты в календаре». Никаких «Думаю над тем, как лучше подойти к задаче».

## Точки вмешательства: где пользователь может вклиниться

Агент, которого нельзя остановить, — это не агент, а автозапуск. Минимум, который должен быть всегда:

• Кнопка «Стоп» в любой момент работы, не утопленная в меню.
• Возможность поправить промежуточный результат и продолжить с него, а не начинать с нуля.
• Откат последнего действия, если оно уже произведено во внешней системе.

### Сценарий: правка на лету

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

Это требует от дизайнера думать о состояниях артефакта, а не только о шагах диалога. Артефакт — письмо, документ, бронь — живёт отдельно от чата и редактируется напрямую.

### Чеклист точек вмешательства

• «Стоп» доступен в один клик на любом шаге
• Промежуточные артефакты редактируются in-place, без возврата в чат
• После правки агент продолжает, а не перезапускается
• Видна история шагов — к любому можно откатиться
• Действия с внешним эффектом имеют явный undo, пока это технически возможно

## Ошибки агента: три типа и что с ними делать

Агент ошибается иначе, чем обычный софт. Это не «500 Internal Server Error», это «уверенно сделал не то». Полезно разделять три типа.

Ошибка понимания. Агент неправильно интерпретировал задачу. Лечится на этапе подтверждения намерения — если этот экран сделан хорошо, такие ошибки ловятся до действия.

Ошибка исполнения. Понял правильно, но инструмент вернул ерунду или агент выбрал не тот источник. Здесь важно показать, что именно пошло не так и на каком шаге, а не общее «Не удалось выполнить задачу».

Ошибка суждения. Сделал всё технически правильно, но результат плохой по смыслу — выбрал странный рейс, написал письмо не в том тоне. Самый коварный тип, потому что система не знает, что ошиблась. Ловится только глазами пользователя — а значит, артефакт должен быть удобно ревьюабелен.

### Анти-паттерн: «успех» без проверки

Агент завершает работу зелёной галочкой «Готово» — а внутри письмо ушло не туда, бронь сделана на не тот день. Пользователь увидит это через сутки, и доверие к агенту обнулится.

Правильнее заканчивать сессию не статусом «успех», а сводкой: что сделано, куда, с какими параметрами, и явная просьба подтвердить, что всё ок. Особенно для действий с внешним эффектом.

## Как применить это в макете уже завтра

Если вы проектируете agentic-фичу, и хочется не утонуть — три практических шага.

1. Нарисуйте флоу как историю артефакта, а не как ветку чата. Где артефакт появляется, как меняется, кто его трогает, когда уходит во внешний мир.
2. Разметьте каждое действие по уровню автономии — авто, с подтверждением, вручную. Это покажет, где нужны экраны подтверждения, а где они избыточны.
3. Для каждого шага ответьте: что увидит пользователь, если зайдёт сюда через минуту молчания. Если ответ «спиннер» — переделывайте.

### Вопросы для ревью макета

• Видно ли намерение агента до того, как он начал действовать?
• Можно ли остановить процесс и не потерять контекст?
• Что показывается в момент работы — нарратив или пустота?
• Как выглядит ошибка суждения, а не только техническая?
• Где заканчивается «агент сам» и начинается «нужен человек» — видит ли это пользователь?

Короткий итог: процесс работы агента — это отдельный объект проектирования, не побочный эффект. Стрим вместо спиннера, артефакт отдельно от чата, явные точки вмешательства и честные ошибки — четыре опоры, на которых держится доверие к agentic-интерфейсу. Дальше посмотрим, как всё это влияет на метрики продукта и что меняется в работе самой дизайн-команды.

## Метрики agentic-продукта: что реально мерить

Обычные продуктовые метрики на агентских флоу врут. DAU растёт, потому что агент дёргает сервис сам. Time on task падает — но не потому что стало удобнее, а потому что человек кликнул «запусти» и ушёл пить кофе. Conversion может идеально расти на бумаге, пока выясняется, что половина задач завершилась «технически успешно», но юзер потом всё переделывал руками.

Чтобы не врать себе, на agentic-фиче стоит смотреть на три отдельных среза.

### Срез 1: качество автономии

Это про то, насколько агент справляется без человека — но честно.

• Доля сессий, завершённых без вмешательства — и отдельно: доля, где вмешательство было, но юзер не отменил весь флоу
• Intervention rate по шагам — на каком именно этапе люди чаще всего жмут «стоп» или правят артефакт
• Rollback rate — как часто после «Готово» пользователь откатывает или переделывает результат вручную
• Время до первой правки — если юзеры массово правят через 3 секунды после показа артефакта, агент промахивается с намерением

Rollback rate — самая честная метрика из всех. Зелёная галочка ничего не значит, если через час юзер всё переделал.

### Срез 2: доверие

Доверие плохо измеряется одной цифрой, но косвенные сигналы есть.

• Доля задач, запущенных в режиме «авто» vs «с подтверждением» — если юзеры массово сидят на ручном подтверждении даже после месяца использования, доверия нет
• Повторное использование на чувствительных сценариях — отправил письмо клиенту один раз, вернулся ли за вторым
• Глубина задач — растёт ли средняя сложность того, что люди делегируют, со временем

### Срез 3: стоимость ошибки

Не все ошибки равны. Стоит вести отдельный счётчик «дорогих» промахов — те, что ушли во внешний мир: отправленные не туда письма, лишние бронирования, ошибочные платежи. Эта метрика должна быть на дашборде команды красным цветом и обсуждаться на каждом ревью, даже если значение 0.

## Как ревьюить agentic-флоу в команде

Обычное дизайн-ревью устроено вокруг экранов. Agentic-флоу плохо ложится на этот формат — большинство интересного происходит между экранами и в состояниях, которые ты не покажешь одним фреймом.

### Формат ревью: проигрывание сценария

Вместо обхода макетов по порядку — проигрывайте сценарий вживую. Один человек читает реплику пользователя, второй — действия агента, третий следит за артефактом. Звучит театрально, но именно так вылезают дыры: «а что юзер видит, пока ты это говоришь?», «а если он сейчас закроет вкладку?».

### Три обязательных вопроса на ревью

• Что показывает экран на 15-й секунде молчания агента? Если в макете этого состояния нет — макет не готов.
• Где в этом флоу точка невозврата? До неё всё должно быть отменяемо дёшево, после — должно быть явное подтверждение.
• Как этот же флоу выглядит, если агент ошибся на шаге 3 из 5? Не «как обработана ошибка», а как выглядит весь экран целиком.

### Анти-паттерн ревью: «покажи happy path»

Соблазн показывать только идеальный сценарий — потому что он красивый и его проще нарисовать. На agentic-фиче happy path не показывает почти ничего полезного. Реальная сложность живёт в развилках: юзер вмешался, агент засомневался, инструмент вернул пустоту, контекст устарел. Ревью без этих веток — это ревью обёртки.

## Как объяснять решения команде разработки

Agentic-флоу — это место, где дизайнер вынужден говорить про вещи, которые раньше были не его территорией: какие инструменты доступны агенту, в каком порядке он их вызывает, что считается «уверенным» ответом. Без этого нельзя спроектировать честный UI.

Чтобы не утонуть в спорах с инженерами, помогает простой документ на каждую фичу — одна страница, три блока.

Блок	Что там
Намерения	Какие задачи агент берёт на себя, какие нет, какие требуют подтверждения
Контракт UI	Какие состояния агент обязан стримить наружу, в каком формате, с какой частотой
Обработка сбоев	Что считается ошибкой понимания, исполнения, суждения — и как каждая выглядит в интерфейсе

Этот документ — не ТЗ и не спека. Это общая опора, чтобы дизайн и бэкенд агента договаривались терминами одного уровня. Без него дизайнер рисует «красивый процесс», а инженер строит систему, которая физически не может выдать то, что нарисовано.

### Чеклист готовности фичи к разработке

• Определены уровни автономии для каждого действия
• Описан формат стрима: что приходит из агента и как часто
• Зафиксированы точки вмешательства и поведение после правки
• Прописана сводка по завершению — поля, источники, формулировки
• Договорено, какие действия имеют undo и сколько он живёт
• Есть сценарий ошибки суждения, не только технической

Короткий итог: agentic-фича требует от дизайнера выйти за рамки экранов — в метрики, которые ловят настоящую полезность, в ревью, которые проигрывают сценарии, и в документы, которые синхронизируют UI с поведением самого агента. Дальше — про то, как всё это меняет состав и ритм работы дизайн-команды.

## Сводный чеклист: agentic-фича перед запуском

Это не чеклист «всё ли красиво». Это чеклист, после которого не стыдно отдавать фичу живым людям, у которых агент будет тратить их время, деньги и репутацию.

### Намерения и границы

• Явно перечислено, какие задачи агент берёт, а какие отказывается выполнять
• Для каждого действия зафиксирован уровень автономии: спросить, предложить, сделать
• Видно, где проходит граница «дешёвое действие» и «дорогое действие»
• Есть формулировка отказа — что агент скажет, если задача вне его компетенции

### Видимость процесса

• У каждой длительной операции есть промежуточное состояние, а не только спиннер
• Показано, какие источники агент использует прямо сейчас
• Видно, чем агент занят на 15-й и 60-й секунде молчания
• Любое действие во внешний мир оставляет след, который пользователь может перечитать позже

### Управление и откат

• Каждое обратимое действие имеет undo с понятным окном
• Перед необратимым действием — отдельный экран подтверждения, не тост
• Пользователь может вмешаться в работу агента, не закрывая контекст
• После вмешательства агент не теряет уже сделанную часть работы

### Сбои и неопределённость

• Различаются три типа ошибок: понимания, исполнения, суждения
• Для каждого типа описан экран, а не только текст
• Агент умеет сказать «не уверен» и не выдаёт догадку за факт
• При частичном успехе видно, что сделано, что нет, и что делать дальше

## Анти-паттерны, которые встречаются чаще всего

### «Чат как универсальный интерфейс»

Когда любая фича сводится к окну переписки. Чат хорош для уточнений и нелинейных задач, но проваливается, когда нужно показать структуру, сравнить варианты или вернуться к шагу 3 из 8. Если интерфейс целиком — это история сообщений, пользователь теряет ориентацию через десять реплик.

### «Иллюзия согласия»

Агент пишет «готово», но не показывает, что именно сделал. Пользователь нажимает «ок», и только через день обнаруживает, что письмо ушло не туда. Лекарство — обязательная сводка по фактическим действиям, с источниками и обратимыми ссылками, а не финальной точкой в диалоге.

### «Уверенность по умолчанию»

Тон агента одинаково твёрдый и когда он знает ответ, и когда угадывает. Это самая дорогая ошибка: пользователь перестаёт перепроверять. UI должен иметь визуальный сигнал неуверенности — отдельный, не текстовый, чтобы его нельзя было пропустить.

### «Тихий контекст»

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

### «Прогресс-бар вместо смысла»

Полоска, которая едет от 0 до 100, ничего не говорит о том, что происходит и можно ли вмешаться. На agentic-флоу прогресс лучше показывать шагами с названиями: «читаю переписку», «составляю черновик», «проверяю адреса». Шаги дают точку входа для правки.

### «Один большой undo на всё»

Кнопка «отменить всё» создаёт ложное чувство безопасности и не работает там, где часть действий уже ушла наружу. Лучше — отдельный undo на каждое действие с разным сроком жизни, и явное «это уже нельзя отменить» там, где это правда.

## Вопросы для финального ревью

Перед тем как ставить фичу в релиз, пройдитесь по списку. Если на любой вопрос ответ «не знаю» — это работа, а не релиз.

• На каком экране пользователь поймёт, что агент его не понял?
• Как выглядит интерфейс, если агент уверен на 60%, а не на 95%?
• Что увидит пользователь, если откроет фичу через неделю и не вспомнит, о чём договаривался?
• Сколько кликов между «агент собирается сделать» и «я это остановил»?
• Где в флоу самый дорогой промах, и почему именно там стоит подтверждение?
• Какой одной метрикой команда поймёт, что пользователи начали доверять агенту больше?

## Короткий практический итог

Agentic UX не отменяет старые навыки — он добавляет несколько новых обязанностей. Дизайнер теперь отвечает не только за экраны, но и за то, как агент показывает свою работу, как признаётся в неуверенности и как возвращает управление человеку. Это требует другой плотности коммуникации с инженерами, других ревью и других метрик.

Практически это сводится к трём вещам. Первое — не прятать процесс: всё, что агент делает за пользователя, должно оставлять видимый и обратимый след. Второе — разнести уровни автономии по стоимости действия, а не по удобству разработки. Третье — проектировать ошибку и неуверенность как отдельные состояния интерфейса, не как баг.

Если фича проходит ваш собственный чеклист, переживает проигрывание сценария на ревью и не попадает в анти-паттерны из списка выше — её уже можно показывать пользователям. Дальше работают метрики, наблюдение и итерации, как и в любом другом продукте.