Проектування для автономних агентів викликає унікальне розчарування. Ми передаємо складне завдання ШІ, він зникає на 30 секунд (або 30 хвилин), а потім повертається з результатом. Ми дивимося на екран. Це спрацювало? Це галюцинації? Він перевірив базу даних відповідності чи пропустив цей крок? Зазвичай ми реагуємо на цю тривогу однією з двох крайнощів. Ми або зберігаємо систему як чорну скриньку, приховуючи все, щоб зберегти простоту, або ми панікуємо та створюємо дамп даних, передаючи кожен рядок журналу та виклик API користувачеві. Жоден із підходів безпосередньо не стосується нюансів, необхідних для надання користувачам ідеального рівня прозорості. Чорна скринька змушує користувачів почуватися безсилими. Дамп даних створює сліпоту сповіщень, руйнуючи ефективність, яку обіцяв забезпечити агент. Користувачі ігнорують постійний потік інформації, поки щось не зламається, після чого їм не вистачає контексту, щоб це виправити. Нам потрібен організований спосіб знайти баланс. У моїй попередній статті «Проектування для агентського штучного інтелекту» ми розглянули елементи інтерфейсу, які зміцнюють довіру, як-от попереднє відображення запланованої дії штучного інтелекту (попередній перегляд намірів) і надання користувачам контролю над тим, скільки штучного інтелекту робить самостійно (автономні перемикачі). Але знати, які елементи використовувати, це лише частина завдання. Найважче питання для дизайнерів — знати, коли їх використовувати. Як дізнатися, який конкретний момент у 30-секундному робочому процесі потребує попереднього перегляду намірів, а який можна обробити за допомогою простого запису в журналі? Ця стаття пропонує спосіб відповісти на це запитання. Ми пройдемося по аудиту вузла прийняття рішень. Цей процес збирає дизайнерів та інженерів в одній кімнаті, щоб зіставити логіку серверної частини з інтерфейсом користувача. Ви дізнаєтесь, як визначити точні моменти, коли користувачеві потрібна інформація про те, що робить ШІ. Ми також розглянемо матрицю впливу/ризику, яка допоможе визначити пріоритетність вузлів рішень для відображення та будь-який пов’язаний шаблон проектування для поєднання з цим рішенням. Моменти прозорості: приклад прикладу Розглянемо Meridian (не справжнє ім’я), страхову компанію, яка використовує агентський штучний інтелект для обробки первинних заяв про нещасні випадки. Користувач викладає фотографії пошкоджень автомобіля та протокол поліції. Потім агент зникає на хвилину, а потім повертається з оцінкою ризику та запропонованим діапазоном виплат. Спочатку інтерфейс Meridian просто показував Calculating Claim Status. Користувачі розчарувалися. Вони надали кілька детальних документів і не були впевнені, чи AI навіть переглянув поліцейський звіт, який містив пом’якшувальні обставини. Чорна скринька викликала недовіру. Щоб виправити це, команда розробників провела аудит вузла прийняття рішень. Вони виявили, що штучний інтелект виконує три окремі кроки, засновані на ймовірності, з численними вбудованими меншими кроками:
Аналіз зображень. Агент порівняв фотографії пошкоджень із базою даних типових сценаріїв автомобільних аварій, щоб оцінити вартість ремонту. Це включало оцінку впевненості. Перевірка тексту. Він перевірив поліцейський звіт на предмет ключових слів, які впливають на відповідальність (наприклад, вина, погодні умови, тверезість). Це включало оцінку ймовірності правового статусу. Перехресне посилання на політику. Він зіставив деталі претензії з конкретними умовами політики користувача, шукаючи винятки чи обмеження покриття. Це також включало ймовірнісне зіставлення.
Команда перетворила ці кроки на моменти прозорості. Послідовність інтерфейсу оновлено до:
Оцінка фотографій пошкоджень: порівняння з 500 профілями ударів транспортних засобів. Перегляд поліцейського звіту: аналіз ключових слів щодо відповідальності та правового прецеденту. Перевірка покриття політики: перевірка певних винятків у вашому плані.
Система все ще займала стільки ж часу, але чітке повідомлення про внутрішню роботу агента відновило довіру користувачів. Користувачі розуміли, що штучний інтелект виконує складне завдання, для якого він був розроблений, і вони точно знали, на що зосередити свою увагу, якщо остаточна оцінка буде неточною. Такий вибір дизайну перетворив момент тривоги на момент спілкування з користувачем. Застосування матриці впливу/ризику: що ми вирішили приховати Більшість досвіду штучного інтелекту не мають недоліку в подіях і вузлах рішень, які потенційно можуть відображатися під час обробки. Одним із найважливіших результатів аудиту було рішення про те, що залишити невидимим. У прикладі Meridian серверні журнали генерували 50+ подій на претензію. Ми могли за замовчуванням відображати кожну подію під час її обробки як частину інтерфейсу користувача. Замість цього ми застосували матрицю ризиків, щоб їх скоротити:
Подія журналу: пінгування сервераЗахід-2 для перевірки резервування. Вердикт фільтра: приховати. (Низькі ставки, висока технічність).
Подія журналу: порівняння оцінки ремонту зі значенням BlueBook. Вердикт фільтра: Показати. (Високі ставки, впливають на виплату користувача).
Завдяки видаленню непотрібних деталей важлива інформація, як-от перевірка покриття, була більш впливовою. Ми створили відкритий інтерфейс і розробили відкритий досвід. Цей підхід використовує ідею, що люди почуваються краще про послугу, коли бачать, як виконується робота. Показуючи конкретні кроки (оцінка, перегляд, перевірка), ми змінили 30-секундне очікування з часу хвилювання («Він зламався?») на час відчуття, ніби створюється щось цінне («Він думає»). Тепер давайте детальніше розглянемо, як ми можемо переглянути процес прийняття рішень у наших продуктах, щоб визначити ключові моменти, які потребують чіткої інформації. Аудит вузла прийняття рішень Прозорість зазнає невдачі, коли ми розглядаємо її як вибір стилю, а не функціональну вимогу. Ми маємо тенденцію запитувати: «Як має виглядати інтерфейс користувача?» перш ніж запитати: «Що насправді вирішує агент?» Аудит вузла прийняття рішень — це простий спосіб полегшити розуміння систем ШІ. Він працює, ретельно відображаючи внутрішні процеси системи. Основна мета полягає в тому, щоб знайти і чітко визначити точні моменти, коли система перестає слідувати встановленим правилам і замість цього робить вибір на основі випадковості або оцінки. Відображаючи цю структуру, творці можуть показати ці точки невизначеності безпосередньо людям, які використовують систему. Це змінює системні оновлення з розпливчастих заяв на конкретні надійні звіти про те, як ШІ дійшов висновку. Окрім згаданого вище прикладу зі страхування, я нещодавно працював із агентом із закупівель, який створював команду. Система перевіряла контракти постачальників і позначала ризики. Спочатку на екрані відображався простий рядок прогресу: «Перегляд контрактів». Користувачі ненавиділи це. Наше дослідження показало, що вони відчували занепокоєння щодо правових наслідків відсутнього пункту. Ми виправили це, провівши аудит вузла прийняття рішень. У кінці цієї статті я включив покроковий контрольний список для проведення цього аудиту. Ми провели сесію з інженерами та окреслили, як працює система. Ми визначили «точки прийняття рішення» — моменти, коли штучному інтелекту доводилося вибирати між двома хорошими варіантами. У стандартних комп’ютерних програмах процес зрозумілий: якщо відбувається А, то Б завжди відбуватиметься. У системах штучного інтелекту процес часто базується на випадковості. ШІ вважає, що А є, ймовірно, найкращим вибором, але він може бути впевненим лише на 65%. У контрактній системі ми знайшли момент, коли штучний інтелект перевіряв умови відповідальності відповідно до правил нашої компанії. Це рідко був ідеальний матч. ШІ мав вирішити, чи відповідність у 90% є достатньою. Це був ключовий момент прийняття рішення.
Коли ми визначили цей вузол, ми відкрили його для користувача. Замість «Перегляд контрактів» інтерфейс оновлено: «Застереження про відповідальність відрізняється від стандартного шаблону. Аналіз рівня ризику». Це конкретне оновлення додало користувачам впевненості. Вони знали, що агент перевірив положення про відповідальність. Вони зрозуміли причину затримки та переконалися, що бажана дія виконується на сервері. Вони також знали, де копати глибше, коли агент згенерував контракт. Щоб перевірити, як ШІ приймає рішення, вам потрібно тісно співпрацювати зі своїми інженерами, менеджерами з продуктів, бізнес-аналітиками та ключовими людьми, які роблять вибір (часто прихований), що впливає на роботу інструменту ШІ. Намалюйте кроки, які виконує інструмент. Позначте кожне місце, де процес змінює напрямок, оскільки зустрічається ймовірність. Це ті місця, де вам слід зосередитися на тому, щоб бути більш прозорими. Як показано на малюнку 2 нижче, аудит вузла прийняття рішень включає такі кроки:
Зберіть команду разом: залучіть власників продуктів, бізнес-аналітиків, дизайнерів, ключових осіб, які приймають рішення, та інженерів, які створили ШІ. Наприклад, Подумайте про команду продукту, яка розробляє інструмент штучного інтелекту, призначений для перевірки безладних юридичних контрактів. До команди входять UX-дизайнер, менеджер із продуктів, UX-дослідник, практикуючий юрист, який виступає в якості експерта з певної теми, та інженер серверної частини, який написав код для аналізу тексту.
Намалюйте весь процес: задокументуйте кожен крок, який робить штучний інтелект, від першої дії користувача до кінцевого результату. Команда стоїть біля дошки та малює всю послідовність ключового робочого процесу, який передбачає пошук ШІ положення про відповідальність у складному контракті. Юрист завантажуєPDF-файл на п’ятдесят сторінок → Система перетворює документ на читабельний текст. → AI сканує сторінки на предмет положень про відповідальність. → Користувач чекає. → Через кілька хвилин чи хвилин інструмент підсвічує знайдені абзаци жовтим кольором в інтерфейсі користувача. Вони роблять це для багатьох інших робочих процесів, які також підтримує інструмент.
Знайдіть, де щось незрозуміле: подивіться на карту процесу, щоб знайти будь-яку точку, де штучний інтелект порівнює параметри або вхідні дані, які не мають ідеального збігу. Команда дивиться на дошку, щоб помітити неоднозначні кроки. Перетворення зображення на текст відбувається за суворими правилами. Пошук конкретного положення про відповідальність передбачає припущення. Кожна фірма пише ці речення по-різному, тому штучному інтелекту доводиться зважувати кілька варіантів і робити прогноз замість того, щоб знаходити точний збіг слів.
Визначте кроки «найкращого припущення»: для кожної незрозумілої точки перевірте, чи використовує система оцінку достовірності (наприклад, чи 85% впевненості?). Це точки, де ШІ робить остаточний вибір. Система має вгадати (визначити ймовірність), який абзац(и) дуже нагадує стандартне положення про відповідальність. Він призначає оцінку достовірності своєму найкращому припущенню. Це припущення є вузлом рішення. Інтерфейс повинен повідомляти юристу, що він виділяє потенційний збіг, а не заявляти, що він знайшов остаточне положення.
Перевірте вибір: для кожного пункту вибору з’ясуйте конкретну внутрішню математику або порівняння, яке виконується (наприклад, зіставлення частини договору з полісом або порівняння зображення розбитого автомобіля з бібліотекою фотографій пошкодженого автомобіля). Інженер пояснює, що система порівнює різні параграфи з базою даних стандартних положень про відповідальність із минулих справ фірм. Він обчислює оцінку подібності тексту, щоб прийняти рішення про відповідність на основі ймовірностей.
Напишіть чіткі пояснення: створюйте повідомлення для користувача, які чітко описують конкретні внутрішні дії, що відбуваються, коли ШІ робить вибір. Контент-дизайнер пише конкретне повідомлення саме для цього моменту. У тексті зазначено: Порівняння тексту документа зі стандартними положеннями фірми для визначення потенційних ризиків відповідальності.
Оновіть екран: додайте ці нові чіткі пояснення в інтерфейс користувача, замінивши розпливчасті повідомлення на зразок «Перегляд контрактів». Команда розробників видаляє загальну кнопку завантаження PDF-файлів. Вони вставляють нове пояснення в рядок стану, розташований прямо над засобом перегляду документів, поки ШІ думає.
Перевірте довіру: переконайтеся, що нові повідомлення на екрані дають користувачам просту причину будь-якого часу очікування або результату, що повинно змусити їх відчувати себе впевненіше та довіряти.
Матриця впливу/ризику Уважно придивившись до процесу ШІ, ви, ймовірно, знайдете багато моментів, де він робить вибір. ШІ може зробити десятки маленьких варіантів для одного складного завдання. Відображення їх усіх створює забагато непотрібної інформації. Вам потрібно згрупувати ці варіанти. Ви можете використовувати матрицю впливу/ризику, щоб відсортувати ці варіанти на основі типів дій, які виконує ШІ. Ось приклади матриць впливу/ризику: По-перше, шукайте рішення з низькими ставками та незначним впливом. Низькі ставки / низький вплив
Приклад: упорядкування файлової структури або перейменування документа. Необхідність прозорості: мінімальна. Досить тонкого сповіщення або запису в журналі. Користувачі можуть легко скасувати ці дії.
Потім визначте рішення з високими ставками та результативними рішеннями. Високі ставки / Високий вплив
Приклад: відхилення заявки на отримання кредиту або здійснення операції з акціями. Потреба в прозорості: висока. Ці дії потребують підтвердження роботи. Система повинна продемонструвати обґрунтування до або відразу, коли вона діє.
Розглянемо фінансовий торговий бот, який однаково обробляє всі замовлення на купівлю/продаж. Він виконує угоду на 5 доларів з такою ж непрозорістю, як і на 50 000 доларів. Користувачі можуть сумніватися, чи інструмент визнає потенційний вплив прозорості на торгівлю великою сумою в доларах. Їм потрібно, щоб система призупинилася та показала свою роботу для угод з високими ставками. Рішення полягає в тому, щоб запровадити стан перегляду логіки для будь-якої транзакції, яка перевищує певну суму в доларах, що дозволяє користувачеві бачити фактори, що впливають на прийняття рішення, перед його виконанням. Відображення вузлів у шаблони: рубрика вибору шаблону проектування Після того, як ви визначили ключові вузли прийняття рішень, ви повинні вирішити, який шаблон інтерфейсу користувача буде застосовано до кожного з них, які ви відображатимете. У Designing For Agentic AI ми запровадили такі шаблони, як Intent Preview (для контролю над високими ставками) і Action Audit (для ретроспективної безпеки). Вирішальним фактором у виборі між ними є оборотність. Кожну фільтруємовузол прийняття рішень через матрицю впливу, щоб призначити правильний шаблон: Високі ставки та незворотні: для цих вузлів потрібен попередній перегляд намірів. Оскільки користувач не може легко скасувати дію (наприклад, остаточне видалення бази даних), момент прозорості має відбутися перед виконанням. Система повинна призупинити, пояснити свій намір і вимагати підтвердження. Високі ставки та оборотність: ці вузли можуть покладатися на шаблон Action Audit & Undo. Якщо торговий агент на основі штучного інтелекту переміщує потенційного клієнта в інший конвеєр, він може робити це автономно, якщо сповіщає користувача та пропонує негайну кнопку «Скасувати». Суворо класифікуючи вузли таким чином, ми уникаємо «втоми від тривоги». Ми зберігаємо Intent Preview із високим рівнем тертя лише для справді незворотних моментів, а для всього іншого покладаємось на Action Audit для підтримки швидкості.
Реверсивний Необоротний Низький вплив Тип: Auto-ExecuteUI: Passive Toast / LogEx: Перейменування файлу Тип: ConfirmUI: простий варіант скасування. Наприклад: архівування електронної пошти Високий вплив Тип: ReviewUI: сповіщення + перегляд TrailEx: надсилання чернетки клієнту Тип: Intent previewUI: Модальний / Явний дозвілEx: Видалення сервера
Таблиця 1. Матрицю впливу та оборотності можна використовувати для відображення ваших моментів прозорості в шаблонах проектування. Якісна перевірка: «Чекати, чому?» Тест Ви можете ідентифікувати потенційні вузли на дошці, але ви повинні підтвердити їх поведінкою людини. Вам потрібно перевірити, чи відповідає ваша карта розумовій моделі користувача. Я використовую протокол під назвою «Зачекай, чому?» Тест. Попросіть користувача спостерігати, як агент виконує завдання. Доручіть їм говорити вголос. Кожного разу, коли вони ставлять запитання: «Почекай, чому це зроблено?» або «Він застряг?» або «Він почув мене?» — ви ставите мітку часу. Ці запитання сигналізують про замішання користувачів. Користувач відчуває, що його контроль вислизає. Наприклад, у дослідженні для асистента медичного персоналу користувачі спостерігали, як агент записувався на прийом. Екран залишався нерухомим протягом чотирьох секунд. Учасники постійно запитували: «Це перевірка мого календаря чи лікаря?»
Це запитання виявило відсутній момент прозорості. Системі потрібно було розділити це чотирисекундне очікування на два окремі кроки: «Перевірка вашої доступності», а потім «Синхронізація з розкладом постачальника». Ця невелика зміна зменшила рівень занепокоєння користувачів. Прозорість не працює, якщо вона описує лише дію системи. Інтерфейс повинен пов’язувати технічний процес із конкретною метою користувача. Екран із надписом «Перевірка вашої доступності» не працює, оскільки йому бракує контексту. Користувач розуміє, що ШІ дивиться на календар, але не знає, чому. Ми повинні поєднати дію з результатом. Системі потрібно розділити чотирисекундне очікування на два окремі кроки. Спочатку в інтерфейсі відображається «Перевірка вашого календаря, щоб знайти години роботи». Потім він оновлюється до «Синхронізація з розкладом постачальника, щоб забезпечити вашу зустріч». Це ґрунтує технічний процес на реальному житті користувача. Розглянемо ШІ, який керує інвентарем для місцевого кафе. Система стикається з дефіцитом запасів. Інтерфейс із написом «зв’язатися з постачальником» або «огляд варіантів» викликає занепокоєння. Менеджер цікавиться, система скасовує замовлення чи купує дорогу альтернативу. Кращий підхід полягає в тому, щоб пояснити очікуваний результат: «Оцінка альтернативних постачальників, щоб зберегти ваш графік доставки в п’ятницю». Це повідомляє користувачеві, чого саме намагається досягти ШІ. Операціоналізація аудиту Ви завершили перевірку вузла прийняття рішень і відфільтрували свій список за допомогою матриці впливу та ризику. Тепер у вас є список важливих моментів для прозорості. Далі вам потрібно створити їх в інтерфейсі користувача. Цей крок вимагає спільної роботи різних відділів. Ви не можете створити прозорість самостійно, використовуючи інструмент дизайну. Ви повинні зрозуміти, як система працює за лаштунками. Почніть з логічного огляду. Зустріньтеся зі своїм провідним системним розробником. Принесіть свою карту вузлів рішень. Вам потрібно підтвердити, що система дійсно може ділитися цими станами. Я часто виявляю, що технічна система не показує точний стан, який я хочу показати. Інженер може сказати, що система просто повертає загальний «робочий» статус. Ви повинні наполягати на детальному оновленні. Вам потрібно, щоб система надсилала конкретне повідомленняколи він переходить від читання тексту до перевірки правил. Без цього технічного зв’язку створити ваш дизайн неможливо. Далі залучіть команду Content Design. У вас є технічна причина дій штучного інтелекту, але вам потрібне чітке, зрозуміле пояснення. Інженери забезпечують основний процес, але дизайнери контенту забезпечують спосіб його передачі. Не пишіть ці повідомлення на самоті. Розробник може написати «Виконується функція 402», що є технічно правильним, але безглуздим для користувача. Дизайнер може написати «Мислення», що є дружнім, але надто розпливчастим. Контент-стратег знаходить правильну золоту середину. Вони створюють спеціальні фрази, наприклад «Сканування ризиків відповідальності», які показують, що ШІ працює, не заплутуючи користувача. Нарешті, перевірте прозорість своїх повідомлень. Не чекайте, поки буде створено кінцевий продукт, щоб побачити, чи працює текст. Я проводжу порівняльні тести на простих прототипах, де змінюється лише повідомлення про статус. Наприклад, я показую одній групі (групі A) повідомлення «Перевірка особи», а іншій групі (групі B) повідомлення «Перевірка державних баз даних» (це вигадані приклади, але ви розумієте суть). Тоді я запитую їх, який ШІ почувається безпечнішим. Ви часто виявлятимете, що певні слова викликають занепокоєння, а інші зміцнюють довіру. Ви повинні розглядати формулювання як щось, що вам потрібно перевірити та довести ефективність. Як це змінює процес проектування Проведення таких аудитів має потенціал для зміцнення спільної роботи команди. Ми припиняємо передачу відшліфованих файлів дизайну. Ми починаємо використовувати безладні прототипи та спільні електронні таблиці. Основним інструментом стає матриця прозорості. Інженери та дизайнери вмісту разом редагують цю електронну таблицю. Вони зіставляють точні технічні коди зі словами, які читатиме користувач. Команди зазнають суперечок під час перевірки логіки. Уявіть, що дизайнер запитує інженера, як штучний інтелект вирішує відхилити транзакцію, представлену у звіті про витрати. Інженер може сказати, що бекенд видає лише загальний код статусу, наприклад «Помилка: відсутні дані». Дизайнер заявляє, що це неактивна інформація на екрані. Дизайнер домовляється з інженером про створення конкретного технічного гачка. Інженер пише нове правило, щоб система повідомляла саме те, чого не вистачає, наприклад відсутнє зображення квитанції. На цьому етапі дизайнери контенту виконують роль перекладачів. Розробник може написати технічно точний рядок, наприклад «Обчислення порогу достовірності для відповідності постачальника». Дизайнер контенту перетворює цей рядок на фразу, яка створює довіру для певного результату. Стратег переписує це як «Порівняння цін місцевих постачальників, щоб забезпечити доставку в п’ятницю». Користувач розуміє дію і результат. Уся багатофункціональна команда бере участь у сеансах тестування користувачів. Вони спостерігають, як реальна людина реагує на різні повідомлення про статус. Побачивши паніку користувача через те, що на екрані написано «Виконання торгівлі», команда змушує команду переглянути свій підхід. Інженери та дизайнери погоджуються на кращі формулювання. Вони змінюють текст на «Перевірка достатніх коштів» перед покупкою акцій. Спільне тестування гарантує, що кінцевий інтерфейс відповідає як системній логіці, так і душевному спокою користувача. Для включення цих додаткових заходів у календар команди потрібен час. Однак кінцевим результатом має бути команда, яка спілкується більш відкрито, і користувачі, які краще розуміють, що їхні інструменти на основі ШІ роблять від їх імені (і чому). Цей інтегрований підхід є наріжним каменем розробки справді надійного досвіду ШІ. Довіра – це вибір дизайну Ми часто розглядаємо довіру як емоційний побічний продукт хорошої взаємодії з користувачем. Легше розглядати довіру як механічний результат передбачуваного спілкування. Ми будуємо довіру, показуючи правильну інформацію в потрібний час. Ми знищуємо його, перевантажуючи користувача або повністю ховаючи обладнання. Почніть з аудиту вузла прийняття рішень, особливо для агентських інструментів і продуктів ШІ. Знайдіть моменти, коли система виносить рішення. Відобразіть ці моменти в матриці ризиків. Якщо ставки високі, відкрийте коробку. Покажіть роботу. У наступній статті ми розглянемо, як розробити ці моменти: як написати копію, структурувати інтерфейс користувача та впоратися з неминучими помилками, коли агент помиляється. Додаток: контрольний список аудиту вузла прийняття рішень Етап 1: налаштування та відображення ✅ Зберіть команду: залучіть власників продуктів, бізнес-аналітиків, дизайнерів,ключових осіб, які приймають рішення, та інженерів, які створили ШІ. Підказка: вам потрібно, щоб інженери пояснили справжню логіку серверної частини. Не намагайтеся зробити цей крок поодинці. ✅ Намалюйте весь процес: задокументуйте кожен крок, який робить штучний інтелект, від першої дії користувача до кінцевого результату. Підказка: сеанс на фізичній дошці часто найкраще підходить для накреслення цих початкових кроків. Фаза 2: Пошук прихованої логіки ✅ Знайдіть, де щось незрозуміле: подивіться на карту процесу, щоб знайти будь-яку точку, де штучний інтелект порівнює параметри або вхідні дані, які не мають ідеального збігу. ✅ Визначте найкращі кроки припущення: перевірте, чи використовує система оцінку достовірності для кожної незрозумілої точки. Наприклад, запитайте, чи система впевнена на 85 відсотків. Це точки, де ШІ робить остаточний вибір. ✅ Перегляньте вибір: для кожної точки вибору з’ясуйте конкретну внутрішню математику або порівняння, яке виконується. Прикладом є відповідність частини контракту полісу. Інший приклад включає порівняння зображення розбитого автомобіля з бібліотекою фотографій пошкодженого автомобіля. Фаза 3: Створення взаємодії з користувачем ✅ Пишіть чіткі пояснення: створюйте повідомлення для користувача, які чітко описують конкретну внутрішню дію, що відбувається, коли ШІ робить вибір. Підказка: ґрунтуйте свої повідомлення на конкретній реальності. Якщо штучний інтелект замовляє зустріч із клієнтом у місцевому кафе, скажіть користувачеві, що система перевіряє систему бронювання кафе. ✅ Оновіть екран: додайте ці нові чіткі пояснення в інтерфейс користувача. Замініть розпливчасті повідомлення на зразок Перегляд контрактів своїми конкретними поясненнями. ✅ Перевірте довіру: переконайтеся, що нові екранні повідомлення дають користувачам просту причину будь-якого часу очікування або результату. Це має викликати в них відчуття впевненості та довіри. Підказка: протестуйте ці повідомлення з реальними користувачами, щоб переконатися, що вони розуміють конкретний результат, який досягається.
