Navrhovanie pre autonómnych agentov predstavuje jedinečnú frustráciu. Zložitú úlohu odovzdáme AI, tá zmizne na 30 sekúnd (alebo 30 minút) a potom sa vráti s výsledkom. Pozeráme sa na obrazovku. Podarilo sa to? Mala to halucinácie? Skontrolovala databázu súladu alebo tento krok preskočila? Zvyčajne na túto úzkosť reagujeme jedným z dvoch extrémov. Buď ponecháme systém ako čiernu skrinku, skryjeme všetko, aby sme zachovali jednoduchosť, alebo prepadneme panike a poskytneme dátový výpis, ktorý používateľovi streamuje každý riadok protokolu a volanie API. Ani jeden prístup priamo nerieši nuansy potrebné na poskytnutie ideálnej úrovne transparentnosti používateľom. Black Box necháva používateľov pocit bezmocnosti. Data Dump vytvára notifikačnú slepotu, čím ničí efektivitu, ktorú agent sľúbil poskytnúť. Používatelia ignorujú neustály tok informácií, kým sa niečo nezlomí, v tom momente im chýba kontext na nápravu. Potrebujeme organizovaný spôsob, ako nájsť rovnováhu. V mojom predchádzajúcom článku „Designing For Agentic AI“ sme sa zamerali na prvky rozhrania, ktoré budujú dôveru, ako je napríklad ukazovanie zamýšľanej akcie AI vopred (náhľady zámerov) a poskytnutie kontroly používateľom nad tým, koľko AI robí sama (Autonomy Dials). Ale vedieť, ktoré prvky použiť, je len časť výzvy. Ťažšou otázkou pre dizajnérov je vedieť, kedy ich použiť. Ako viete, ktorý konkrétny moment v 30-sekundovom pracovnom toku vyžaduje náhľad zámeru a ktorý možno spracovať jednoduchým záznamom v denníku? Tento článok poskytuje spôsob, ako odpovedať na túto otázku. Prejdeme si audit rozhodovacieho uzla. Tento proces dostane dizajnérov a inžinierov do rovnakej miestnosti, aby namapovali backendovú logiku do používateľského rozhrania. Dozviete sa, ako presne určiť momenty, kedy používateľ potrebuje aktualizáciu toho, čo robí AI. Pokryjeme aj maticu dopadu/rizika, ktorá pomôže určiť prioritu, ktoré rozhodovacie uzly sa majú zobraziť, a akýkoľvek súvisiaci vzor návrhu, ktorý sa má spárovať s týmto rozhodnutím. Transparency Moments: Príklad prípadovej štúdie Zvážte Meridian (nie skutočné meno), poisťovaciu spoločnosť, ktorá používa agentskú AI na spracovanie počiatočných nárokov na nehody. Používateľ nahrá fotografie poškodenia vozidla a správu polície. Agent potom na minútu zmizne a potom sa vráti s hodnotením rizika a navrhovaným rozsahom výplaty. Spočiatku rozhranie Meridian jednoducho zobrazovalo výpočet stavu nároku. Používatelia začali byť frustrovaní. Predložili niekoľko podrobných dokumentov a cítili neistotu, či AI vôbec preskúmala policajnú správu, ktorá obsahovala poľahčujúce okolnosti. Čierna skrinka vyvolala nedôveru. Aby sa to vyriešilo, tím dizajnérov vykonal audit rozhodovacieho uzla. Zistili, že AI vykonala tri odlišné kroky založené na pravdepodobnosti s množstvom menších krokov:
Analýza obrázkov Agent porovnal fotografie poškodenia s databázou typických scenárov autonehôd, aby odhadol náklady na opravu. To zahŕňalo skóre dôvery. Textual ReviewIt naskenoval policajnú správu, aby našiel kľúčové slová, ktoré ovplyvňujú zodpovednosť (napr. chyba, poveternostné podmienky, triezvosť). Išlo o posúdenie pravdepodobnosti právneho postavenia. Policy Cross ReferenceIt porovnal podrobnosti nároku so špecifickými podmienkami politiky používateľa, pričom hľadal výnimky alebo limity pokrytia. To zahŕňalo aj pravdepodobnostné párovanie.
Tím premenil tieto kroky na momenty transparentnosti. Postupnosť rozhrania bola aktualizovaná na:
Hodnotenie fotografií poškodenia: Porovnanie s 500 profilmi nárazu vozidla. Preskúmanie policajnej správy: Analýza kľúčových slov zodpovednosti a právneho precedensu. Overenie pokrytia zásadami: Kontrola konkrétnych výnimiek vo vašom pláne.
Systému to trvalo stále rovnako dlho, ale explicitná komunikácia o internom fungovaní agenta obnovila dôveru používateľov. Používatelia chápali, že AI vykonáva komplexnú úlohu, na ktorú bola navrhnutá, a presne vedeli, kam majú zamerať svoju pozornosť, ak sa im konečné hodnotenie zdalo nepresné. Táto voľba dizajnu premenila moment úzkosti na moment spojenia s používateľom. Použitie matice vplyvu a rizika: čo sme sa rozhodli skryť Väčšina skúseností AI nemá nedostatok udalostí a rozhodovacích uzlov, ktoré by sa potenciálne mohli zobraziť počas spracovania. Jedným z najdôležitejších výsledkov auditu bolo rozhodnúť, čo ponechať neviditeľné. V príklade Meridian vygenerovali backendové protokoly viac ako 50 udalostí na nárok. Mohli sme predvolene zobraziť každú udalosť tak, ako bola spracovaná ako súčasť používateľského rozhrania. Namiesto toho sme použili rizikovú maticu na ich orezanie:
Zaznamenať udalosť: Ping serverWest-2 pre kontrolu nadbytočnosti. Verdikt filtra: Skryť. (Low Stakes, High Technicality).
Zaznamenať udalosť: Porovnanie odhadu opravy s hodnotou BlueBook. Verdikt filtra: Zobraziť. (Vysoké stávky, ovplyvňuje výplatu používateľa).
Odstránením nepotrebných detailov boli dôležité informácie – ako napríklad overenie pokrytia – účinnejšie. Vytvorili sme otvorené rozhranie a navrhli otvorený zážitok. Tento prístup využíva myšlienku, že ľudia majú zo služby lepší pocit, keď vidia, ako sa práca robí. Ukázaním konkrétnych krokov (posudzovanie, kontrola, overovanie) sme zmenili 30-sekundové čakanie z času obáv („Je to rozbité?“) na čas, keď máme pocit, že sa vytvára niečo cenné („myslí sa“). Pozrime sa teraz bližšie na to, ako môžeme preskúmať proces rozhodovania v našich produktoch, aby sme identifikovali kľúčové momenty, ktoré si vyžadujú jasné informácie. Audit rozhodovacieho uzla Transparentnosť zlyháva, keď ju považujeme skôr za výber štýlu než za funkčnú požiadavku. Máme tendenciu sa pýtať: „Ako by malo vyzerať používateľské rozhranie? predtým, než sa opýtame: "O čom agent vlastne rozhoduje?" Audit rozhodovacieho uzla je jednoduchý spôsob, ako uľahčiť pochopenie systémov AI. Funguje to tak, že sa dôkladne zmapuje vnútorný proces systému. Hlavným cieľom je nájsť a jasne definovať presné momenty, kedy systém prestáva dodržiavať svoje nastavené pravidlá a namiesto toho sa rozhoduje na základe náhody alebo odhadu. Zmapovaním tejto štruktúry môžu tvorcovia ukázať tieto neistoty priamo ľuďom používajúcim systém. Aktualizácie systému sa tak menia z vágnych vyhlásení na konkrétne a spoľahlivé správy o tom, ako AI dospela k záveru. Okrem vyššie uvedenej prípadovej štúdie o poistení som nedávno spolupracoval s tímom, ktorý buduje obstarávateľa. Systém preskúmal zmluvy s dodávateľmi a označil riziká. Pôvodne sa na obrazovke zobrazoval jednoduchý indikátor priebehu: „Kontrola zmlúv“. Používatelia to nenávideli. Náš výskum ukázal, že mali obavy z právnych dôsledkov chýbajúceho ustanovenia. Opravili sme to vykonaním auditu rozhodovacieho uzla. Na záver tohto článku som zahrnul kontrolný zoznam krok za krokom na vykonanie tohto auditu. Uskutočnili sme stretnutie s inžiniermi a načrtli sme, ako systém funguje. Identifikovali sme „body rozhodovania“ – momenty, v ktorých si AI musela vybrať medzi dvoma dobrými možnosťami. V štandardných počítačových programoch je proces jasný: ak sa stane A, stane sa vždy B. V systémoch AI je tento proces často založený na náhode. AI si myslí, že A je pravdepodobne najlepšou voľbou, ale môže to byť len 65% isté. V zmluvnom systéme sme našli moment, keď AI skontrolovala podmienky zodpovednosti voči pravidlám našej spoločnosti. Málokedy to bol dokonalý zápas. AI sa musela rozhodnúť, či je 90% zhoda dosť dobrá. Toto bol kľúčový bod rozhodnutia.
Keď sme tento uzol identifikovali, sprístupnili sme ho používateľovi. Namiesto „Kontrola zmlúv“ sa rozhranie aktualizovalo a uvádza: „Doložka o zodpovednosti sa líši od štandardnej šablóny. Analýza úrovne rizika.“ Táto špecifická aktualizácia dala používateľom dôveru. Vedeli, že agent skontroloval doložku o zodpovednosti. Pochopili dôvod meškania a získali dôveru, že na zadnej strane prebieha požadovaná akcia. Vedeli tiež, kde majú siahnuť hlbšie, keď agent vytvorí zmluvu. Ak chcete skontrolovať, ako AI robí rozhodnutia, musíte úzko spolupracovať so svojimi inžiniermi, produktovými manažérmi, obchodnými analytikmi a kľúčovými ľuďmi, ktorí robia rozhodnutia (často skryté), ktoré ovplyvňujú fungovanie nástroja AI. Nakreslite kroky, ktoré nástroj vykoná. Označte každé miesto, kde proces mení smer, pretože je splnená pravdepodobnosť. Toto sú miesta, kde by ste sa mali zamerať na väčšiu transparentnosť. Ako je znázornené na obrázku 2 nižšie, audit rozhodovacieho uzla zahŕňa tieto kroky:
Spojte tím: Zapojte vlastníkov produktov, obchodných analytikov, dizajnérov, kľúčových tvorcov rozhodnutí a inžinierov, ktorí vytvorili AI. napr. Zamyslite sa nad produktovým tímom, ktorý vytvára nástroj AI určený na kontrolu chaotických právnych zmlúv. Tím zahŕňa dizajnéra UX, produktového manažéra, výskumníka UX, praktického právnika, ktorý pôsobí ako odborník na predmet, a backendového inžiniera, ktorý napísal kód textovej analýzy.
Nakreslite celý proces: Zdokumentujte každý krok, ktorý AI podnikne, od prvej akcie používateľa až po konečný výsledok. Tím stojí pri tabuli a načrtáva celú sekvenciu kľúčového pracovného postupu, ktorý zahŕňa AI hľadanie doložky o zodpovednosti v komplexnej zmluve. Právnik nahrávapäťdesiatstranový súbor PDF → Systém prevedie dokument na čitateľný text. → Umelá inteligencia naskenuje strany, či neobsahuje doložky o zodpovednosti. → Používateľ čaká. → O chvíľu alebo minúty neskôr nástroj v používateľskom rozhraní zvýrazní nájdené odseky žltou farbou. Robia to pre mnohé ďalšie pracovné postupy, ktoré tento nástroj tiež umožňuje.
Zistite, kde sú veci nejasné: Pozrite sa na mapu procesov, kde nájdete akékoľvek miesto, kde AI porovnáva možnosti alebo vstupy, ktoré nemajú dokonalú zhodu. Tím sa pozrie na tabuľu, aby zistil nejednoznačné kroky. Prevod obrázka na text sa riadi prísnymi pravidlami. Nájdenie konkrétnej doložky o zodpovednosti zahŕňa dohady. Každá firma píše tieto klauzuly inak, takže AI musí zvážiť viacero možností a urobiť predpoveď namiesto nájdenia presnej zhody slov.
Identifikujte kroky „najlepšieho odhadu“: Pri každom nejasnom mieste skontrolujte, či systém používa skóre spoľahlivosti (je napríklad istý na 85 %?). Toto sú body, v ktorých AI robí konečnú voľbu. Systém musí uhádnuť (uviesť pravdepodobnosť), ktorý odsek (odstavce) sa veľmi podobá štandardnej doložke o zodpovednosti. Najlepšiemu odhadu priradí skóre spoľahlivosti. Tento odhad je rozhodovací uzol. Rozhranie musí právnikovi povedať, že zdôrazňuje potenciálnu zhodu, a nie uviesť, že našlo definitívnu klauzulu.
Preskúmajte výber: Pre každý bod výberu zistite konkrétnu internú matematiku alebo porovnanie, ktoré sa vykonáva (napr. priraďovanie časti zmluvy k politike alebo porovnanie obrázka pokazeného auta s knižnicou poškodených fotografií áut). Inžinier vysvetľuje, že systém porovnáva rôzne odseky s databázou štandardných doložiek o zodpovednosti z minulých firemných prípadov. Vypočítava skóre podobnosti textu, aby rozhodla o zhode na základe pravdepodobnosti.
Napíšte jasné vysvetlenia: Vytvorte správy pre používateľa, ktoré jasne popisujú konkrétnu internú akciu, ktorá sa deje, keď sa AI rozhodne. Dizajnér obsahu napíše konkrétnu správu presne pre tento moment. Text znie: Porovnanie textu dokumentu so štandardnými záväznými doložkami s cieľom identifikovať potenciálne riziká zodpovednosti.
Aktualizujte obrazovku: Vložte tieto nové, jasné vysvetlenia do používateľského rozhrania a nahraďte vágne správy, ako napríklad „Kontrola zmlúv“. Dizajnérsky tím odstráni všeobecný spinner načítania Spracovanie PDF. Nové vysvetlenie vložia do stavového riadka umiestneného priamo nad prehliadačom dokumentov, zatiaľ čo AI premýšľa.
Kontrola dôvery: Uistite sa, že nové správy na obrazovke poskytujú používateľom jednoduchý dôvod čakania alebo výsledku, vďaka čomu by sa mali cítiť istejšie a dôveryhodnejšie.
Matica vplyvu a rizika Keď sa podrobne pozriete na proces AI, pravdepodobne nájdete veľa bodov, kde sa rozhoduje. AI môže urobiť desiatky malých rozhodnutí pre jednu komplexnú úlohu. Zobrazovanie všetkých vytvára príliš veľa nepotrebných informácií. Tieto voľby musíte zoskupiť. Môžete použiť maticu dopadu/rizika na zoradenie týchto možností na základe typov akcií, ktoré AI vykonáva. Tu sú príklady matíc dopadu/rizika: Po prvé, hľadajte nízke stávky a rozhodnutia s nízkym dopadom. Low Stakes / Low Impact
Príklad: Usporiadanie štruktúry súborov alebo premenovanie dokumentu. Potreba transparentnosti: Minimálna. Stačí jemné upozornenie na prípitok alebo záznam do denníka. Používatelia môžu tieto akcie jednoducho vrátiť späť.
Potom identifikujte dôležité rozhodnutia a rozhodnutia s veľkým dosahom. High Stakes / High Impact
Príklad: Odmietnutie žiadosti o úver alebo uskutočnenie obchodu s akciami. Potreba transparentnosti: Vysoká. Tieto akcie vyžadujú potvrdenie o práci. Systém musí preukázať opodstatnenosť pred alebo bezprostredne pri pôsobení.
Zvážte robota finančného obchodovania, ktorý zaobchádza so všetkými pokynmi na nákup/predaj rovnako. Vykonáva obchod v hodnote 5 USD s rovnakou nepriehľadnosťou ako obchod v hodnote 50 000 USD. Používatelia môžu pochybovať o tom, či nástroj rozpoznáva potenciálny vplyv transparentnosti na obchodovanie s vysokou sumou v dolároch. Potrebujú, aby sa systém zastavil a ukázal svoju prácu pre obchody s vysokými stávkami. Riešením je zaviesť stav kontrolnej logiky pre každú transakciu presahujúcu konkrétnu sumu v dolároch, čo umožňuje používateľovi vidieť faktory, ktoré riadia rozhodnutie pred vykonaním. Mapovanie uzlov na vzory: Rubrika výberu vzoru návrhu Po identifikácii kľúčových rozhodovacích uzlov vašej skúsenosti sa musíte rozhodnúť, ktorý vzor používateľského rozhrania sa použije na každý z nich, ktorý zobrazíte. V Designing For Agentic AI sme zaviedli vzory ako Intent Preview (pre kontrolu veľkých stávok) a Action Audit (pre retrospektívnu bezpečnosť). Rozhodujúcim faktorom pri výbere medzi nimi je reverzibilita. Filtrujeme každúrozhodovací uzol cez maticu dopadu, aby sa priradil správny vzor: High Stakes & Irreversible: Tieto uzly vyžadujú náhľad zámeru. Pretože používateľ nemôže jednoducho vrátiť späť akciu (napr. trvalé odstránenie databázy), moment transparentnosti musí nastať pred vykonaním. Systém sa musí pozastaviť, vysvetliť svoj zámer a vyžadovať potvrdenie. High Stakes & Reversible: Tieto uzly sa môžu spoľahnúť na vzor Action Audit & Undo. Ak obchodný zástupca s podporou AI presunie potenciálny zákazník do iného kanála, môže tak urobiť autonómne, pokiaľ na to upozorní používateľa a ponúkne okamžité tlačidlo Späť. Striktnou kategorizáciou uzlov týmto spôsobom sa vyhneme „pozornej únave“. Ukážku zámeru s vysokým trením si vyhradzujeme len pre skutočne nezvratné momenty, pričom sa spoliehame na to, že akčný audit udrží rýchlosť pre všetko ostatné.
Reverzibilné Nezvratné Nízky vplyv Typ: Auto-ExecuteUI: Passive Toast / LogEx: Premenovanie súboru Typ: ConfirmUI: Simple Undo optionEx: Archivácia e-mailu Vysoký vplyv Typ: ReviewUI: Notification + Review TrailEx: Odoslanie konceptu klientovi Typ: Intent previewUI: Modálne / Explicitné PermissionEx: Odstránenie servera
Tabuľka 1: Maticu dopadu a reverzibility potom možno použiť na mapovanie momentov transparentnosti do návrhových vzorov. Kvalitatívna validácia: "Čakanie, prečo?" Test Potenciálne uzly môžete identifikovať na tabuli, ale musíte ich overiť ľudským správaním. Musíte si overiť, či sa vaša mapa zhoduje s mentálnym modelom používateľa. Používam protokol s názvom „Počkaj, prečo?“ Test. Požiadajte používateľa, aby sledoval, ako agent dokončuje úlohu. Dajte im pokyn, aby hovorili nahlas. Kedykoľvek sa opýtajú: "Počkaj, prečo to urobil?" alebo "Je to zaseknuté?" alebo "Počul ma?" — označíte časovú pečiatku. Tieto otázky signalizujú zmätok používateľov. Používateľ cíti, že sa mu stráca kontrola. Napríklad v štúdii pre asistenta plánovania zdravotnej starostlivosti používatelia sledovali, ako si agent rezervuje stretnutie. Obrazovka zostala na štyri sekundy statická. Účastníci sa dôsledne pýtali: "Kontroluje môj kalendár alebo doktorov?"
Táto otázka odhalila chýbajúci moment transparentnosti. Systém potreboval rozdeliť toto štvorsekundové čakanie do dvoch odlišných krokov: „Kontrola dostupnosti“ a následne „Synchronizácia s plánom poskytovateľa“. Táto malá zmena znížila úroveň úzkosti používateľov. Transparentnosť zlyhá, keď popisuje iba akciu systému. Rozhranie musí spájať technický proces s konkrétnym cieľom používateľa. Obrazovka s textom „Kontrola dostupnosti“ padá, pretože jej chýba kontext. Používateľ chápe, že AI sa pozerá na kalendár, ale nevie prečo. Musíme spojiť akciu s výsledkom. Systém musí rozdeliť toto štvorsekundové čakanie na dva odlišné kroky. Najprv sa v rozhraní zobrazí „Kontrola kalendára, aby ste našli otvorené časy“. Potom sa aktualizuje na „Synchronizácia s plánom poskytovateľa na zabezpečenie vášho stretnutia“. Toto zakladá technický proces v skutočnom živote používateľa. Zvážte AI spravujúcu inventár pre miestnu kaviareň. Systém sa stretáva s nedostatkom dodávok. Rozhranie s textom „kontaktovanie dodávateľa“ alebo „kontrola možností“ vyvoláva úzkosť. Manažéra zaujíma, či systém ruší objednávku alebo kupuje drahú alternatívu. Lepším prístupom je vysvetliť zamýšľaný výsledok: „Hodnotenie alternatívnych dodávateľov, aby ste dodržali svoj piatkový harmonogram dodávok.“ Používateľovi to presne povie, čo sa AI snaží dosiahnuť. Operacionalizácia auditu Dokončili ste audit rozhodovacieho uzla a prefiltrovali ste svoj zoznam cez maticu dopadov a rizík. Teraz máte zoznam dôležitých momentov pre transparentnosť. Ďalej ich musíte vytvoriť v používateľskom rozhraní. Tento krok si vyžaduje tímovú prácu naprieč rôznymi oddeleniami. Priehľadnosť nemôžete navrhnúť sami pomocou nástroja na návrh. Musíte pochopiť, ako systém funguje v zákulisí. Začnite s prehľadom logiky. Stretnite sa so svojím vedúcim dizajnérom systému. Prineste si mapu rozhodovacích uzlov. Musíte potvrdiť, že systém môže skutočne zdieľať tieto stavy. Často zisťujem, že technický systém neodhaľuje presný stav, ktorý chcem ukázať. Inžinier by mohol povedať, že systém len vráti všeobecný „pracovný“ stav. Musíte tlačiť na podrobnú aktualizáciu. Potrebujete, aby systém poslal konkrétne oznámeniekeď sa prepne z čítania textu na kontrolu pravidiel. Bez tohto technického prepojenia nie je možné zostaviť váš dizajn. Ďalej zapojte tím dizajnu obsahu. Máte technický dôvod na činnosť AI, ale potrebujete jasné vysvetlenie priateľské k ľuďom. Inžinieri poskytujú základný proces, ale dizajnéri obsahu poskytujú spôsob, akým sa komunikuje. Nepíšte tieto správy sami. Vývojár môže napísať „Vykonávanie funkcie 402“, čo je technicky správne, ale pre používateľa to nemá význam. Dizajnér môže napísať „Myslenie“, čo je priateľské, ale príliš vágne. Obsahový stratég nájde správnu strednú cestu. Vytvárajú špecifické frázy, ako napríklad „Skenovanie rizík zodpovednosti“, ktoré ukazujú, že AI funguje bez toho, aby zmiatli používateľa. Nakoniec otestujte transparentnosť vašich správ. Nečakajte, kým sa vytvorí konečný produkt, aby ste zistili, či text funguje. Vykonávam porovnávacie testy na jednoduchých prototypoch, kde jediná vec, ktorá sa mení, je stavová správa. Napríklad jednej skupine (skupina A) ukážem správu, ktorá hovorí „Overovanie identity“ a ďalšej skupine (skupina B) správu, ktorá hovorí „Kontrola vládnych databáz“ (toto sú vymyslené príklady, ale rozumiete veci). Potom sa ich spýtam, ktorá AI sa cíti bezpečnejšia. Často zistíte, že niektoré slová spôsobujú obavy, zatiaľ čo iné budujú dôveru. So znením musíte zaobchádzať ako s niečím, čo musíte otestovať a dokázať, že je účinné. Ako to mení proces navrhovania Vykonávanie týchto auditov má potenciál posilniť spoluprácu tímu. Prestávame rozdávať vyleštené dizajnové súbory. Začíname používať chaotické prototypy a zdieľané tabuľky. Hlavným nástrojom sa stáva matica transparentnosti. Inžinieri a dizajnéri obsahu upravujú túto tabuľku spoločne. Mapujú presné technické kódy k slovám, ktoré bude používateľ čítať. Tímy zažijú trenie počas kontroly logiky. Predstavte si, že sa dizajnér spýta inžiniera, ako sa AI rozhodla odmietnuť transakciu predloženú vo výkaze výdavkov. Inžinier by mohol povedať, že backend vydáva iba všeobecný stavový kód ako „Chyba: chýbajúce údaje“. Dizajnér uvádza, že nejde o informácie na obrazovke, ktoré možno vykonať. Dizajnér rokuje s inžinierom o vytvorení špecifického technického háku. Inžinier napíše nové pravidlo, takže systém nahlási presne to, čo chýba, napríklad chýbajúci obrázok účtenky. Dizajnéri obsahu počas tejto fázy pôsobia ako prekladatelia. Vývojár môže napísať technicky presný reťazec, napríklad „Výpočet prahu spoľahlivosti pre párovanie dodávateľov“. Dizajnér obsahu preloží tento reťazec do frázy, ktorá buduje dôveru pre konkrétny výsledok. Stratég to prepíše ako „Porovnanie cien miestnych predajcov na zabezpečenie vášho piatkového doručenia“. Používateľ rozumie akcii a výsledku. Celý medzifunkčný tím sedí na reláciách testovania používateľov. Sledujú, ako skutočná osoba reaguje na rôzne stavové správy. Vidieť, že používateľ prepadá panike, pretože obrazovka hovorí „Prebieha obchod“ núti tím prehodnotiť svoj prístup. Inžinieri a dizajnéri sa prispôsobili lepším formuláciám. Pred nákupom akcií zmenia text na „Overenie dostatočných prostriedkov“. Spoločné testovanie zaručuje, že konečné rozhranie slúži logike systému aj k spokojnosti používateľa. Začlenenie týchto dodatočných aktivít do tímového kalendára si vyžaduje čas. Konečným výsledkom by však mal byť tím, ktorý komunikuje otvorenejšie, a používatelia, ktorí lepšie rozumejú tomu, čo ich nástroje poháňané AI robia v ich mene (a prečo). Tento integrovaný prístup je základným kameňom navrhovania skutočne dôveryhodných zážitkov AI. Dôvera je dizajnová voľba Dôveru často vnímame ako emocionálny vedľajší produkt dobrej používateľskej skúsenosti. Je jednoduchšie považovať dôveru za mechanický výsledok predvídateľnej komunikácie. Budujeme dôveru zobrazovaním správnych informácií v správnom čase. Zničíme ho tým, že zavalíme užívateľa alebo strojové zariadenie úplne skryjeme. Začnite s auditom rozhodovacieho uzla, najmä pre agentské nástroje a produkty AI. Nájdite momenty, kedy systém rozhodne. Mapujte tieto momenty do matice rizík. Ak sú stávky vysoké, otvorte krabicu. Ukážte prácu. V nasledujúcom článku sa pozrieme na to, ako navrhnúť tieto momenty: ako napísať kópiu, štruktúrovať používateľské rozhranie a zvládnuť nevyhnutné chyby, keď sa agent pomýli. Príloha: Kontrolný zoznam auditu rozhodovacieho uzla Fáza 1: Nastavenie a mapovanie ✅ Spojte tím: Priveďte vlastníkov produktov, obchodných analytikov, dizajnérov,kľúčoví tvorcovia rozhodnutí a inžinieri, ktorí vytvorili AI. Tip: Potrebujete, aby inžinieri vysvetlili skutočnú logiku backendu. Nepokúšajte sa o tento krok sami. ✅ Nakreslite celý proces: Zdokumentujte každý krok, ktorý AI podnikne, od prvej akcie používateľa až po konečný výsledok. Tip: Fyzická tabuľa často funguje najlepšie na nakreslenie týchto počiatočných krokov. Fáza 2: Nájdenie skrytej logiky ✅ Nájdite, kde sú veci nejasné: Pozrite sa na mapu procesov, kde nájdete akékoľvek miesto, kde AI porovnáva možnosti alebo vstupy, ktoré nemajú jednu dokonalú zhodu. ✅ Identifikujte najlepšie kroky odhadu: Pre každé nejasné miesto skontrolujte, či systém používa skóre spoľahlivosti. Opýtajte sa napríklad, či je systém istý na 85 percent. Toto sú body, v ktorých AI robí konečnú voľbu. ✅ Preskúmajte výber: Pre každý bod výberu zistite konkrétnu internú matematiku alebo porovnanie, ktoré sa vykonáva. Príkladom je priraďovanie časti zmluvy k politike. Ďalší príklad zahŕňa porovnanie obrázka rozbitého auta s knižnicou poškodených fotografií auta. Fáza 3: Vytvorenie používateľskej skúsenosti ✅ Napíšte jasné vysvetlenia: Vytvorte správy pre používateľa, ktoré jasne popisujú konkrétnu internú akciu, ktorá sa deje, keď sa AI rozhodne. Pomôcka: Upevnite svoje správy v konkrétnej realite. Ak si AI rezervuje stretnutie s klientom v miestnej kaviarni, povedzte používateľovi, že systém kontroluje rezervačný systém kaviarne. ✅ Aktualizujte obrazovku: Vložte tieto nové, jasné vysvetlenia do používateľského rozhrania. Nahraďte vágne správy, ako je Kontrola zmlúv, svojimi konkrétnymi vysvetleniami. ✅ Skontrolujte dôveru: Uistite sa, že nové správy na obrazovke poskytujú používateľom jednoduchý dôvod na akúkoľvek čakaciu dobu alebo výsledok. To by v nich malo vyvolať pocit istoty a dôvery. Tip: Otestujte tieto správy so skutočnými používateľmi, aby ste si overili, že rozumejú konkrétnemu dosiahnutému výsledku.
