Як дизайнеру проєктувати AI-агентів

Коли я розповідаю студентам про евристики Нільсена, частина аудиторії реагує так, ніби чує очевидні речі. Система має показувати свій статус. Людина повинна мати можливість скасувати дію. Повідомлення про помилку має пояснювати, що сталося. Усе це здається природним, якщо з дитинства користуєшся продуктами, у яких такі принципи вже стали нормою.

Для мене свого часу вони були відкриттям. І я не думаю, що евристики застаріли. Радше вони настільки вплинули на цифрові продукти, що ми перестали їх помічати. Але останнім часом я все частіше ставлю інше питання: чи достатньо цих правил для інтерфейсу, який не просто реагує на дії людини, а може сам планувати та діяти від її імені?

Уявімо агента, якому ви доручили організувати робочу поїздку. Він знайшов рейси, перевірив календар, запропонував готель і почав заповнювати бронювання. Поки все відбувається за планом, взаємодія здається майже магічною. Але що робити, якщо агент вирішив змінити дати? Якщо бронювання не можна безкоштовно скасувати? Якщо він відправив повідомлення колезі без вашого дозволу? І в який момент ви маєте дізнатися, що щось пішло не так?

Це вже не питання про розташування кнопки. Це питання про межі автономії, відповідальність, передбачуваність і контроль. І саме ці рішення, на мою думку, мають стати частиною роботи продуктового дизайнера. Ми більше не проєктуємо лише те, як людина керує інтерфейсом. Ми проєктуємо також те, як система діє без неї і коли має повернути їй керування.

Сім рішень, які дизайнер ухвалює про агента

Я б починала проєктування не з чатового інтерфейсу, аватара чи бібліотеки готових AI-патернів, а з семи рішень. Вони визначають поведінку системи задовго до того, як ми почнемо вибирати компоненти.

Ці сім пунктів не претендують на статус нового універсального стандарту. Це мій практичний синтез із досліджень Microsoft, Google PAIR, Apple й Anthropic. Його цінність у тому, що він перетворює абстрактне «зробити agentic UX» на конкретні продуктові рішення, які можна обговорити з інженерами, менеджерами та майбутніми користувачами.

Спочатку визначити, чи потрібна автономія

Не кожна функція, яка використовує LLM, має ставати агентом. Якщо щодня о 8:30 потрібно зібрати короткий звіт із трьох відомих джерел, часто достатньо workflow з передбаченими кроками. Якщо користувач просить «розберися, чому ми не отримали оплату, і запропонуй наступні дії», системі, можливо, доведеться самостійно визначати послідовність пошуку, інструментів та уточнень. Anthropic у матеріалі Building effective agents розрізняє саме ці підходи: workflows мають визначені наперед траєкторії, а agents динамічно керують власним процесом.

Мені подобається підхід model-first, коли команда спочатку досліджує можливості й обмеження моделі, а вже потім формує продуктову концепцію. Це дозволяє не копіювати звичні екрани конкурентів лише тому, що вони існують. Але model-first не замінює user-centered design. Можливість моделі самостійно надіслати повідомлення не є достатньою причиною дозволити їй це робити.

Автономія має залежати від дії, а не від назви агента

Найкорисніша модель для початку розмови з командою, на мою думку, це ризик × зворотність. Прочитати доступність у календарі, створити чорновик листа, надіслати лист і здійснити платіж означає зовсім різні рівні відповідальності. Вони не повинні отримувати однакове правило підтвердження лише тому, що їх виконує один агент.

Важливе уточнення: навіть «легко відкотити» не завжди означає «безпечно». Надісланий лист можна видалити зі своєї пошти, але не можна гарантовано забрати його з чужої памʼяті чи чужої скриньки. Дизайнер має враховувати реальні наслідки, а не лише наявність кнопки Undo.

Дозвіл, пояснення і відновлення потрібно проєктувати разом

Можна змусити агента питати підтвердження перед кожною дією, але тоді навіщо взагалі делегувати йому роботу? І навпаки, можна дозволити все автоматично, проте користувач втратить можливість своєчасно помітити помилку. Баланс залежить від контексту. Я б розрізняла згоду на план, згоду на конкретну ризикову дію та можливість втрутитися під час виконання. Це три різні механізми, а не один екран із кнопкою «Підтвердити».

Те саме стосується пояснень. Людині зазвичай не потрібен журнал усіх кліків і технічних викликів. Значно корисніше знати, що агент змінив домовлений план, знайшов суперечливі дані або не зміг виконати важливу частину завдання. Тому основний екран має показувати прогрес і наслідки, а докладний журнал залишатися доступним на запит. Якщо агент помилився, продукт має пропонувати не просто повідомлення «Щось пішло не так», а наступний безпечний крок.

Що показують дослідження, а не лише наші припущення

У 2019 році Microsoft Research запропонувала 18 Guidelines for Human-AI Interaction, перевірених, зокрема, за участю 49 дизайн-практиків на 20 AI-продуктах. Ці рекомендації охоплюють чотири фази взаємодії: перше знайомство, звичайну роботу, помилки та зміну поведінки системи з часом. Вони були створені до сучасної хвилі LLM-агентів, але добре пояснюють, чому продукт має чесно повідомляти про свої можливості, підтримувати виправлення й не змінювати поведінку непомітно.

У 2026 році команда Apple дослідила UX агентів, які працюють безпосередньо з інтерфейсами. Спочатку дослідники узагальнили наявні рішення та поговорили з вісьмома UX- й AI-фахівцями, а потім провели Wizard-of-Oz дослідження з 20 учасниками. У ньому роль агента виконував дослідник. Люди хотіли бачити прогрес і розуміти причини важливих рішень, але не контролювати кожен клік. Вони також очікували можливості втрутитися, особливо коли задача ставала ризикованою або агент відходив від початкового плану. Це невелике якісне дослідження, а не універсальна статистика для всіх агентів, але воно допомагає формулювати тестовані UX-гіпотези.

Мабуть, найцікавіші цифри зʼявилися в дослідженні Anthropic Measuring AI Agent Autonomy in Practice (2026), яке аналізувало реальне використання Claude Code. Серед нових користувачів (до 50 сесій) повне автоматичне підтвердження дій використовувалося приблизно у 20% сесій; після 750 сесій ця частка перевищувала 40%. Водночас частота переривань зростала: новачки (близько 10 сесій) переривали агента приблизно у 5% кроків, досвідчені приблизно у 9%. Тобто досвідчені користувачі не просто «більше довіряють». Вони змінюють спосіб контролю: менше погоджують заздалегідь, але активніше втручаються за потреби. Ці цифри стосуються Claude Code, тобто переважно програмування, і не доводять, що така сама поведінка буде в фінансовому чи медичному агенті.

У тому ж дослідженні є ще одна знахідка, важлива для дизайнера: на найскладніших задачах Claude Code сам зупиняється, щоб уточнити, більш ніж удвічі частіше, ніж його перериває людина. Отже, момент «запитати людину» буває не лише кнопкою в інтерфейсі, а й поведінкою моделі, яку можна проєктувати й тренувати. Саме тому в сімох рішеннях «моменти зупинки» стоять окремим пунктом.

Є й обережніший погляд. Позиційна стаття AI Agents Push Humans Out of the Loop (NeurIPS 2026) стверджує, що сучасний дизайн агентів не підтримує ефективний нагляд, а тривале використання ще й послаблює навички, потрібні для нього. Формальне «так» на кожен запит не є контролем. Anthropic, зі свого боку, прийшла до схожого висновку з практики: коли дій десятки, люди перестають читати підтвердження, тому в Claude Code зʼявився Plan Mode, де людина погоджує й редагує план наперед, а не кожен крок. Хороший контроль не означає максимальну кількість підтверджень. Він означає, що людина може зрозуміти стан роботи й втрутитися саме тоді, коли це потрібно.

Ці дослідження допомагають переглянути класичні UX-евристики, але не замінити їх. Видимість статусу тепер означає не лише індикатор завантаження, а й зрозумілий прогрес довгої задачі. Контроль користувача включає права доступу, втручання та відновлення. Запобігання помилкам передбачає не тільки валідацію полів, але й межі дій, які модель взагалі може здійснювати. А послідовність інтерфейсу стає ще важливішою, коли система сама змінює свій план.

У чому гайдлайни згодні, а де розходяться

Якщо покласти Microsoft, Google PAIR, Apple і Anthropic поруч, ядро в них спільне. Розбіжності починаються там, де AI перестає підказувати і починає діяти сам.

Спільне

• Чесно показувати, що AI вміє і чого не вміє. У Microsoft це перші два гайдлайни, у PAIR розділ про ментальні моделі, в Apple окрема категорія, в Anthropic принцип прозорості.
• Контроль лишається за людиною. Зупинити, виправити, відмовитися, перехопити: про це пишуть і гайдлайни 2019 року, і дослідження агентів 2026-го.
• Помилки неминучі, тож відновлення проєктують заздалегідь. У Microsoft є ціла фаза «коли AI помиляється», у PAIR розділ про те, що робити, коли щось пішло не так, в Apple окрема частина знахідок про помилки агента.
• Довіра має бути відкаліброваною, а не максимальною. Людина має довіряти рівно настільки, наскільки система на це заслуговує.
• Пояснювати, чому система щось зробила. Не всю внутрішню кухню, а причину рішення.
• Поведінка змінюється з часом, і про це треба казати. Microsoft пише про оновлення поведінки, Apple про перепланування посеред задачі.

Розбіжності

• Наскільки жорсткі правила. Microsoft дає 18 конкретних гайдлайнів. PAIR дає патерни навколо питань команди. Apple свідомо не дає приписів, лише мапу і словник, бо галузь, на думку авторів, ще занадто молода.
• Хто діє. Microsoft і PAIR писали для AI, який підказує, а рішення ухвалює людина. Apple, Anthropic і Microsoft Magentic-UI пишуть про агента, який діє сам. Тому незворотні дії, як-от оплата чи листи людям, у ранніх гайдлайнах майже не згадуються.
• Де розмістити контроль. Magentic-UI і учасники тесту Apple виступають за дозвіл перед конкретною ризиковою дією. Anthropic вважає, що підтвердження на кожен крок втомлює, і переносить контроль на рівень плану. Feng, McDonald і Zhang (2025) пропонують обирати рівень автономії як окреме рішення: від оператора, який керує кожним кроком, до спостерігача, який лише може зупинити агента.
• Скільки показувати. Ранні гайдлайни радять пояснювати більше. У тесті Apple люди не збиралися стежити за кожним кроком, а один з учасників сам запропонував progressive disclosure.
• Хто зупиняє. Майже всі пишуть про те, як людина перериває агента. Anthropic додає другий бік: агент має сам зупинятися і питати.
• Чи потрібен AI взагалі. PAIR починає саме з цього питання. Microsoft і Apple виходять з того, що AI у продукті вже є.
• На чому тримаються висновки. Microsoft перевіряла гайдлайни з практиками на продуктах 2019 року, PAIR спирається на досвід Google, Apple на тест із 20 людьми, Anthropic на мільйони реальних взаємодій, але лише у власних продуктах.

Спільне ядро можна вчити як базу вже зараз. А розбіжності і є відкритими дизайнерськими питаннями, на які кожна команда відповідає під свій продукт.

Як перевіряти agentic UX до запуску

У класичних продуктах ми часто тестуємо, чи може людина виконати завдання. З агентами я б додала інше питання: чи здатна людина зрозуміти, що система вже зробила, що зробить далі та як зупинити небажані наслідки? Тому простого happy path недостатньо. Треба досліджувати сценарії невизначеності, помилки й зміни плану.

Наприклад, для агента, який організовує поїздку, я б тестувала такі ситуації: він знайшов дешевший рейс, але з невигідною пересадкою; потрібно змінити бронювання, яке не повертається; календар і повідомлення колеги суперечать одне одному; агент втратив доступ до пошти посеред задачі. Для кожного сценарію важливо перевірити, чи людина помітила ризик, зрозуміла наслідки та змогла відновити керування.

Почати можна навіть без готового агента. У Wizard-of-Oz тестуванні дослідник вручну імітує поведінку системи, а учасник взаємодіє з прототипом так, ніби агент працює самостійно. Це дозволяє перевірити політики підтверджень, реакції на помилки та очікування користувачів ще до складної інженерної реалізації. Пʼять ранніх інтервʼю можуть допомогти знайти проблеми, але їх недостатньо, щоб статистично довести перевагу одного рішення.

Я б пропонувала команді вимірювати не тільки task success rate, але й частку ризикових дій, виконаних із належним дозволом, time to intervention (як швидко користувач може зупинити небажану дію), успішність відновлення після помилки та кількість зайвих підтверджень на завершене завдання. Для фонових агентів окремо важливо перевіряти, чи люди дізнаються про суттєві зміни плану вчасно. Це кандидати на продуктові метрики, а не готові галузеві бенчмарки.

Де дизайнеру цьому вчитися

Я б не шукала один курс, після якого можна назвати себе дизайнером AI-агентів. Сфера змінюється швидко, а необхідні знання лежать на перетині human-computer interaction, продуктового мислення, поведінкових досліджень і технічного розуміння того, як працюють моделі та інструменти. Корисніше вибудувати власну програму навчання з трьох рівнів: принципи, патерни і розуміння того, як агент влаштований зсередини.

Найкраще доповнення до читання, на мою думку, це створення власного невеликого агента. Не обовʼязково одразу будувати повноцінний продукт. Достатньо сценарію, у якому агент читає інформацію, складає план і запитує дозвіл на одну важливу дію. Коли бачиш, як він помиляється, переплановує роботу й просить уточнень, дуже швидко стає зрозуміло, чому agentic UX не зводиться до дизайну чатового вікна.

За ким стежити

• Емілі Кемпбелл (The Shape of AI): найповніший каталог AI-патернів.
• Віталій Фрідман (Smashing Magazine): AI-патерни на сотнях реальних прикладів; веде воркшоп Design Patterns For AI Interfaces.
• Салеема Амерші (Microsoft): співавторка гайдлайнів Human-AI Interaction і агента Magentic-UI.
• Руйцзя Ченг і Джеффрі Ніколс (Apple): емпіричні дослідження UX агентів.
• Кевін Фенг (University of Washington): рівні автономії агентів.
• Якоб Нільсен (UX Tigers): прогнози про AI і UX, з якими цікаво сперечатися.

Що залишається незмінним

Евристики Нільсена не втратили сенсу. Людині й надалі потрібно розуміти стан системи, виправляти помилки, впізнавати знайомі патерни й мати контроль. І поведінка людини лишається в центрі: дизайнери роками вчилися її розуміти, і ця навичка тепер потрібна для нового питання, як люди поводяться з AI, чого очікують, коли довіряють і коли перевіряють. Саме тому чат так важко замінити, хоча його намагаються витіснити вже кілька років: це найзвичніший формат розмови, і люди приходять до AI з готовими очікуваннями від нього. Питання не «чат чи не чат», а що навколо нього: план, статус, дозволи, контроль. Але з агентами змінюється масштаб дизайнерських рішень. Тепер недостатньо передбачити, що станеться після натискання кнопки. Потрібно спроєктувати поведінку системи тоді, коли наступної кнопки може взагалі не бути.

Чи потрібен агент? Що йому дозволено? Коли він має зупинитися? Що користувач побачить, поки агент працює? Як дізнається про помилку та поверне контроль? Якщо команда не може відповісти на ці питання, проблема не в тому, що їй бракує AI-компонентів у дизайн-системі. Вона ще не визначила, як має працювати сам продукт.

“

Мені здається, майбутнє agentic UX не в тому, щоб зробити систему максимально автономною. Воно в тому, щоб зробити її автономію зрозумілою, доречною та керованою.

Що доведе, що я помиляюся

Цей аргумент ослаб би, якби агенти з повною автономією без підтверджень стабільно отримували більше довіри і менше помилок, ніж агенти з продуманими моментами зупинки. Або якби люди, які роками працюють з агентами, переставали втручатися взагалі, і нічого поганого не ставалося. Або якби дизайнери, навчені лише класичних евристик, проєктували агентів не гірше за тих, хто вчився на нових гайдлайнах. Якщо у вас є такі дані, дуже хочу їх побачити.

Коротко

• Евристики Нільсена досі актуальні, але написані для інтерфейсу, що чекає на команду. Агент сам планує і діє, тому старі правила отримують нові питання.
• Починайте не з екранів, а з семи рішень: чи потрібен агент, межі доступу, рівень автономії, моменти зупинки, що видно, як відкотити, як агент говорить про себе.
• Автономію обирають для кожної дії окремо: що ризикованіша й незворотніша дія, то раніше агент питає людину. І «можна видалити» не завжди означає «безпечно».
• З досвідом люди дають агенту більше свободи, але й частіше втручаються. Проєктуйте траєкторію довіри, а не один рівень контролю.
• Гайдлайни Microsoft, Google PAIR, Apple і Anthropic згодні в ядрі: чесність про можливості, контроль, відновлення, калібрована довіра. Розходяться в тому, де розмістити контроль і скільки показувати.
• Тестуйте сценарії помилок і зміни плану, а не лише happy path. Wizard-of-Oz дозволяє зробити це ще до того, як агент існує.
• Вчитися можна безкоштовно, але найкраще зібрати власного невеликого агента і подивитися, як він помиляється.

Якщо ви проєктуєте AI-агента і хочете перевірити, як він поводиться в ризикових сценаріях, напишіть мені.