En
Написать
‹ Назад

У дизайнеров появился новый пользователь. И это не человек

AXagentsdesign systems

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

19 октября 20265 мин
Дизайнер, пользователь и AI-агент, соединённые общей схемой данных, правил и инструментов

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

Теперь в продукте появляется ещё один участник: AI‑агент. Он может работать с данными, вызывать инструменты, обращаться к API и выполнять цепочки действий между системами. Интерфейс никуда не исчезает, просто теперь пользоваться продуктом может не только человек.

Когда сценарий перестаёт быть цепочкой экранов

Возьмём обычный внутренний процесс. Сотрудник получает письмо, идёт в CRM, сверяет данные, открывает ещё одну систему, проверяет лимиты и принимает решение. Раньше дизайнер пытался сделать этот путь короче и понятнее: свести информацию на один экран, убрать лишние поля, подсветить статус, сократить количество переходов.

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

И вопросы на проектировании становятся другими:

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

AX: новый термин или новый слой работы

Для этого всё чаще используют термин AX — Agent Experience. Salesforce ещё в 2025 году описала AI‑агентов как новый тип пользователей, для которых тоже нужно проектировать среду и правила взаимодействия. У них есть хороший текст про это: Welcome to a New Era of Agent Experience Design.

Но я бы пока не спешил писать AX Designer в профиле на LinkedIn или hh. Скорее это новый слой работы поверх product design, service design и engineering, чем сформировавшаяся отдельная профессия — пока точно нет (но кто знает: тренды быстро залетают, и чего только люди уже себе не пишут в профилях).

Похожая история уже была с Design Systems и DesignOps: сначала это казалось просто дополнительной аккуратностью внутри обычной продуктовой работы, а потом стало понятно, что без явных правил, токенов и контрактов большие продукты начинают расползаться. С агентами происходит то же самое, только цена неясности стала выше: человек перед странным экраном хотя бы остановится и переспросит, а агент уверенно продолжит выполнять цепочку.

То, что понятно на глаз, недоступно машине

Особенно это заметно в дизайн‑системах и внутренних инструментах. Человек считывает огромное количество смысла из визуального контекста: видит, что красная кнопка рядом с названием проекта, скорее всего, удаляет данные; понимает по отступам, какие поля относятся к одной группе; догадывается, что серый текст — это подсказка, а не значение.

Если правило существует только в голове дизайнера или его можно понять, лишь посмотрев на макет в Figma, машине оно недоступно. Агенту нужны явные описания состояний, ограничений, доступных действий и инструментов — всё то, что можно вытащить в структурированном виде через правила, схемы, плагины и MCP.

На практике это быстро меняет требования к тому, как мы описываем систему:

  • Не просто картинка компонента, а контракт: для чего он нужен, когда его нельзя использовать, какие состояния обязательны и какие свойства меняют смысл действия.
  • Не сырые значения, а семантика: токены и роли элементов, по которым и разработчик, и coding‑агент собирают предсказуемый интерфейс без угадывания HEX и отступов на глаз.
  • Не «нажми сюда», а чёткие границы действия: что именно делает инструмент, какие параметры принимает, какие побочные эффекты создаёт и что возвращает при ошибке.

Agent‑Computer Interface

Anthropic называет это Agent‑Computer Interface (ACI) и отдельно пишет, что качество tool descriptions, параметров и границ инструментов напрямую влияет на то, насколько надёжно работает агент: Building Effective AI Agents.

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

Плохой ACI устроен так же, как перегруженный экран: слишком много похожих действий, неочевидные параметры, отсутствие понятных ошибок и размытые границы ответственности. Хороший ACI, наоборот, сужает пространство для галлюцинаций и делает правильное действие самым простым.

Два контура одного продукта

Поэтому UX никуда не уходит, и новая профессия завтра не отменит старую. Человеку по‑прежнему нужны ясные экраны, понятная иерархия, предсказуемые состояния и удобный контроль над тем, что происходит. Более того, когда часть работы уходит агенту, требования к человеческому интерфейсу в точках проверки и передачи управления становятся только выше.

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

Раньше мы объясняли человеку, как пользоваться системой. Теперь приходится ещё и объяснять системе, что она вообще может делать.

Есть задача?

Напишите мне. Вместе разберёмся, с чего начать.