Design til autonome agenter giver en unik frustration. Vi giver en kompleks opgave til en AI, den forsvinder i 30 sekunder (eller 30 minutter), og så vender den tilbage med et resultat. Vi stirrer på skærmen. Virkede det? Hallucinerede det? Har den tjekket compliance-databasen eller springet det trin over? Vi reagerer typisk på denne angst med en af to yderpunkter. Vi beholder enten systemet som en sort boks, skjuler alt for at bevare enkelheden, eller vi går i panik og leverer et datadump, der streamer hver loglinje og API-kald til brugeren. Ingen af tilgangene adresserer direkte den nuance, der er nødvendig for at give brugerne det ideelle niveau af gennemsigtighed. Black Box efterlader brugerne magtesløse. Datadumpen skaber meddelelsesblindhed, hvilket ødelægger effektiviteten, som agenten lovede at levere. Brugere ignorerer den konstante strøm af information, indtil noget går i stykker, hvorefter de mangler konteksten til at rette det. Vi har brug for en organiseret måde at finde balancen på. I min tidligere artikel, "Designing For Agentic AI", så vi på grænsefladeelementer, der opbygger tillid, som at vise AI'ens tilsigtede handling på forhånd (Intent Previews) og give brugerne kontrol over, hvor meget AI'en gør på egen hånd (Autonomy Dials). Men at vide, hvilke elementer der skal bruges, er kun en del af udfordringen. Det sværere spørgsmål for designere er at vide, hvornår de skal bruge dem. Hvordan ved du, hvilket specifikt øjeblik i en 30-sekunders arbejdsgang der kræver en Intent Preview, og hvilket der kan håndteres med en simpel logindtastning? Denne artikel giver en metode til at besvare dette spørgsmål. Vi vil gennemgå beslutningsknude-revisionen. Denne proces får designere og ingeniører i samme rum til at kortlægge backend-logik til brugergrænsefladen. Du vil lære, hvordan du lokaliserer de nøjagtige øjeblikke, en bruger har brug for en opdatering om, hvad AI laver. Vi vil også dække en Impact/Risk-matrix, der vil hjælpe med at prioritere, hvilke beslutningsknuder der skal vises, og ethvert tilhørende designmønster, der skal parres med denne beslutning. Transparency Moments: Et eksempel på casestudie Overvej Meridian (ikke rigtigt navn), et forsikringsselskab, der bruger en agent AI til at behandle indledende ulykkeskrav. Brugeren uploader billeder af køretøjsskader og politianmeldelsen. Agenten forsvinder derefter i et minut, før han vender tilbage med en risikovurdering og et foreslået udbetalingsområde. Oprindeligt viste Meridians interface simpelthen Calculating Claim Status. Brugerne blev frustrerede. De havde indsendt flere detaljerede dokumenter og følte sig usikre på, om AI overhovedet havde gennemgået politirapporten, som indeholdt formildende omstændigheder. Black Box skabte mistillid. For at rette op på dette gennemførte designteamet en Decision Node Audit. De fandt ud af, at AI udførte tre forskellige, sandsynlighedsbaserede trin, med adskillige mindre trin indlejret:
Billedanalyse Agenten sammenlignede skadesbillederne med en database over typiske bilulykkesscenarier for at estimere reparationsomkostningerne. Dette indebar en tillidsscore. TekstgennemgangDet scannede politirapporten for nøgleord, der påvirker ansvar (f.eks. fejl, vejrforhold, ædruelighed). Dette indebar en sandsynlighedsvurdering af juridisk status. PolitikkrydsreferenceDet matchede kravoplysningerne mod brugerens specifikke forsikringsvilkår, og søgte efter undtagelser eller dækningsgrænser. Dette involverede også probabilistisk matchning.
Holdet forvandlede disse trin til gennemsigtighedsøjeblikke. Interfacesekvensen blev opdateret til:
Vurdering af skadesbilleder: Sammenligning med 500 køretøjskollisionsprofiler. Gennemgang af politirapport: Analyse af ansvarsnøgleord og juridisk præcedens. Bekræftelse af politikdækning: Tjek for specifikke ekskluderinger i din plan.
Systemet tog stadig den samme tid, men den eksplicitte kommunikation om agentens interne funktion genoprettede brugernes tillid. Brugerne forstod, at AI'en udførte den komplekse opgave, den var designet til, og de vidste præcis, hvor de skulle fokusere deres opmærksomhed, hvis den endelige vurdering virkede unøjagtig. Dette designvalg forvandlede et øjebliks angst til et øjebliks forbindelse med brugeren. Anvendelse af effekt-/risikomatricen: Hvad vi valgte at skjule De fleste AI-oplevelser har ingen mangel på begivenheder og beslutningsknuder, der potentielt kan blive vist under behandlingen. Et af de mest kritiske resultater af revisionen var at beslutte, hvad der skulle holdes usynligt. I Meridian-eksemplet genererede backend-logfilerne 50+ hændelser pr. krav. Vi kunne som standard have vist hver hændelse, da de blev behandlet som en del af brugergrænsefladen. I stedet anvendte vi risikomatricen til at beskære dem:
Loghændelse: Ping-serverWest-2 til redundanskontrol. Filtrer dom: Skjul. (Low Stakes, High Technicality).
Loghændelse: Sammenligning af reparationsestimat med BlueBook-værdi. Filterbedømmelse: Vis. (Høj indsats, påvirker brugerens udbetaling).
Ved at fjerne de unødvendige detaljer var den vigtige information - som dækningsbekræftelsen - mere virkningsfuld. Vi skabte en åben grænseflade og designet en åben oplevelse. Denne tilgang bruger ideen om, at folk har det bedre med en service, når de kan se arbejdet udføres. Ved at vise de specifikke trin (Vurdering, Gennemgang, Verificering) ændrede vi en 30-sekunders ventetid fra en tid med bekymring (“Er den i stykker?”) til en tid, hvor vi føler, at noget værdifuldt bliver skabt (“Det tænker”). Lad os nu se nærmere på, hvordan vi kan gennemgå beslutningsprocessen i vores produkter for at identificere nøgleøjeblikke, der kræver klar information. Beslutningsknude-revisionen Gennemsigtighed svigter, når vi behandler det som et stilvalg snarere end et funktionelt krav. Vi har en tendens til at spørge: "Hvordan skal brugergrænsefladen se ud?" før vi spørger: "Hvad beslutter agenten egentlig?" Decision Node Audit er en ligetil måde at gøre AI-systemer lettere at forstå. Det fungerer ved omhyggeligt at kortlægge systemets interne proces. Hovedmålet er at finde og klart definere de nøjagtige tidspunkter, hvor systemet stopper med at følge sine fastsatte regler og i stedet træffer et valg baseret på tilfældigheder eller skøn. Ved at kortlægge denne struktur kan skabere vise disse usikkerhedspunkter direkte til de personer, der bruger systemet. Dette ændrer systemopdateringer fra at være vage udsagn til specifikke, pålidelige rapporter om, hvordan AI nåede frem til sin konklusion. Ud over forsikringscasestudiet ovenfor, arbejdede jeg for nylig med et team, der byggede en indkøbsagent. Systemet gennemgik leverandørkontrakter og markerede risici. Oprindeligt viste skærmen en simpel statuslinje: "Gennemgang af kontrakter." Brugerne hadede det. Vores forskning viste, at de følte sig bekymrede over de juridiske konsekvenser af en manglende klausul. Vi løste dette ved at udføre en beslutningsknudeaudit. Jeg har inkluderet en trin-for-trin tjekliste til udførelse af denne revision i slutningen af denne artikel. Vi kørte en session med ingeniørerne og skitserede, hvordan systemet fungerer. Vi identificerede "Beslutningspunkter" - øjeblikke, hvor AI'en skulle vælge mellem to gode muligheder. I standard computerprogrammer er processen klar: Hvis A sker, så vil B altid ske. I AI-systemer er processen ofte baseret på tilfældigheder. AI'en mener, at A nok er det bedste valg, men det er måske kun 65% sikkert. I kontraktsystemet fandt vi et øjeblik, hvor AI kontrollerede ansvarsvilkårene i forhold til vores virksomhedsregler. Det var sjældent et perfekt match. AI'en skulle afgøre, om et 90% match var godt nok. Dette var et vigtigt beslutningspunkt.
Når vi identificerede denne node, afslørede vi den for brugeren. I stedet for "Gennemgang af kontrakter" opdaterede grænsefladen til at sige: "Ansvarsklausul varierer fra standardskabelonen. Analyserer risikoniveau." Denne specifikke opdatering gav brugerne tillid. De vidste, at agenten tjekkede ansvarsklausulen. De forstod årsagen til forsinkelsen og fik tillid til, at den ønskede handling fandt sted på bagsiden. De vidste også, hvor de skulle grave dybere ind, når agenten havde genereret kontrakten. For at kontrollere, hvordan AI'en træffer beslutninger, skal du arbejde tæt sammen med dine ingeniører, produktchefer, forretningsanalytikere og nøglepersoner, som træffer de valg (ofte skjulte), der påvirker, hvordan AI-værktøjet fungerer. Tegn de trin, værktøjet tager. Marker hvert sted, hvor processen ændrer retning, fordi en sandsynlighed er opfyldt. Det er de steder, hvor du bør fokusere på at være mere gennemsigtig. Som vist i figur 2 nedenfor, involverer beslutningsknudeaudit disse trin:
Få holdet sammen: Få produktejere, forretningsanalytikere, designere, nøglebeslutningstagere og ingeniørerne, der byggede AI'en, med. f.eks. Tænk på et produktteam, der bygger et AI-værktøj designet til at gennemgå rodede juridiske kontrakter. Teamet omfatter UX-designeren, produktchefen, UX-forskeren, en praktiserende advokat, der fungerer som emneeksperten, og backend-ingeniøren, der skrev tekstanalysekoden.
Tegn hele processen: Dokumenter hvert trin, AI tager, fra brugerens første handling til det endelige resultat. Holdet står ved en tavle og skitserer hele sekvensen for en nøglearbejdsgang, der involverer AI, der søger efter en ansvarsklausul i en kompleks kontrakt. Advokaten uploaderen 50-siders PDF → Systemet konverterer dokumentet til læsbar tekst. → AI'en scanner siderne for ansvarsklausuler. → Brugeren venter. → Øjeblikke eller minutter senere fremhæver værktøjet de fundne afsnit med gult på brugergrænsefladen. Det gør de til mange andre arbejdsgange, som værktøjet også rummer.
Find, hvor tingene er uklare: Se på proceskortet for ethvert sted, hvor AI'en sammenligner muligheder eller input, der ikke har ét perfekt match. Holdet ser på tavlen for at få øje på de tvetydige trin. Konvertering af et billede til tekst følger strenge regler. At finde en specifik ansvarsklausul involverer gætværk. Hvert firma skriver disse klausuler forskelligt, så AI'en skal afveje flere muligheder og lave en forudsigelse i stedet for at finde et nøjagtigt ordmatch.
Identificer de 'bedste gæt'-trin: For hvert uklart sted skal du kontrollere, om systemet bruger en konfidensscore (er det for eksempel 85 % sikkert?). Det er de punkter, hvor AI'en træffer et endeligt valg. Systemet skal gætte (give en sandsynlighed), hvilke paragraf(er) der ligner en standardansvarsklausul. Det tildeler en tillidsscore til sit bedste gæt. Det gæt er en beslutningsknude. Grænsefladen skal fortælle advokaten, at den fremhæver et potentielt match, i stedet for at angive, at det fandt den endelige klausul.
Undersøg valget: For hvert valgpunkt skal du finde ud af den specifikke interne matematik eller sammenligning, der udføres (f.eks. matche en del af en kontrakt med en politik eller sammenligne et billede af en ødelagt bil med et bibliotek med beskadigede bilbilleder). Ingeniøren forklarer, at systemet sammenligner de forskellige paragraffer med en database med standardansvarsklausuler fra tidligere sager. Den beregner en tekstlighedsscore for at afgøre et match baseret på sandsynligheder.
Skriv klare forklaringer: Opret beskeder til brugeren, der klart beskriver den specifikke interne handling, der sker, når AI'en træffer et valg. Indholdsdesigneren skriver en specifik besked til netop dette øjeblik. Teksten lyder: Sammenligning af dokumenttekst med standard faste klausuler for at identificere potentielle ansvarsrisici.
Opdater skærmen: Sæt disse nye, klare forklaringer i brugergrænsefladen, og erstatte vage beskeder som "Gennemgang af kontrakter." Designteamet fjerner den generiske Processing PDF loading spinner. De indsætter den nye forklaring i en statuslinje placeret lige over dokumentfremviseren, mens AI'en tænker.
Tjek for tillid: Sørg for, at de nye skærmmeddelelser giver brugerne en simpel grund til enhver ventetid eller resultat, hvilket burde få dem til at føle sig mere selvsikre og tillidsfulde.
Impact/Risk Matrix Når du ser nærmere på AI's proces, vil du sandsynligvis finde mange punkter, hvor den træffer et valg. En AI kan træffe dusinvis af små valg til en enkelt kompleks opgave. At vise dem alle skaber for meget unødvendig information. Du skal gruppere disse valg. Du kan bruge en Impact/Risk Matrix til at sortere disse valg baseret på den eller de typer handlinger, AI'en udfører. Her er eksempler på påvirknings-/risikomatricer: Se først efter beslutninger med lav indsats og lav indvirkning. Lav indsats / lav effekt
Eksempel: Organisering af en filstruktur eller omdøbning af et dokument. Behov for gennemsigtighed: Minimalt. En subtil toast-meddelelse eller en logindtastning er tilstrækkelig. Brugere kan nemt fortryde disse handlinger.
Identificer derefter de høje indsatser og storslåede beslutninger. High Stakes / High Impact
Eksempel: Afvisning af en låneansøgning eller gennemførelse af en aktiehandel. Behov for gennemsigtighed: Højt. Disse handlinger kræver bevis for arbejde. Systemet skal demonstrere rationalet før eller umiddelbart efterhånden som det handler.
Overvej en finansiel handelsbot, der behandler alle købs-/salgsordrer ens. Den udfører en handel på $5 med samme uigennemsigtighed som en handel på $50.000. Brugere kan stille spørgsmålstegn ved, om værktøjet genkender den potentielle indvirkning af gennemsigtighed på handel med et stort dollarbeløb. De har brug for, at systemet holder pause og viser dets arbejde for de højindsatte handler. Løsningen er at indføre en Reviewing Logic-tilstand for enhver transaktion, der overstiger et specifikt dollarbeløb, hvilket giver brugeren mulighed for at se de faktorer, der driver beslutningen, før den udføres. Kortlægning af noder til mønstre: En rubrik til valg af designmønster Når du har identificeret din oplevelses vigtigste beslutningsknuder, skal du beslutte, hvilket UI-mønster, der gælder for hver enkelt, du vil vise. I Designing For Agentic AI introducerede vi mønstre som Intent Preview (til kontrol med høje indsatser) og Action Audit (til retrospektiv sikkerhed). Den afgørende faktor i valget mellem dem er reversibilitet. Vi filtrerer hverbeslutningsknudepunkt gennem effektmatricen for at tildele det korrekte mønster: Høje indsatser og irreversible: Disse noder kræver en Intent Preview. Fordi brugeren ikke nemt kan fortryde handlingen (f.eks. permanent sletning af en database), skal gennemsigtighedsøjeblikket ske før udførelse. Systemet skal holde pause, forklare sin hensigt og kræve bekræftelse. Høje indsatser og reversible: Disse noder kan stole på Action Audit & Fortryd-mønsteret. Hvis den AI-drevne salgsagent flytter et kundeemne til en anden pipeline, kan den gøre det autonomt, så længe den giver brugeren besked og tilbyder en øjeblikkelig Fortryd-knap. Ved strengt at kategorisere noder på denne måde undgår vi "alarmtræthed". Vi reserverer kun den friktionsfri Intent Preview til de virkelig irreversible øjeblikke, mens vi stoler på Action Audit for at opretholde hastigheden til alt andet.
Vendbar Irreversibel Lav påvirkning Type: Auto-ExecuteUI: Passive Toast / LogEx: Omdøbning af en fil Type: ConfirmUI: Simple Fortryd optionEx: Arkivering af en e-mail Høj effekt Type: ReviewUI: Notification + Review TrailEx: Sender en kladde til en klient Type: Intent previewUI: Modal / Eksplicit PermissionEx: Sletning af en server
Tabel 1: Slag- og reversibilitetsmatrixen kan derefter bruges til at kortlægge dine øjeblikke af gennemsigtighed til designmønstre. Kvalitativ validering: "Ventetiden, hvorfor?" Test Du kan identificere potentielle noder på en tavle, men du skal validere dem med menneskelig adfærd. Du skal verificere, om dit kort matcher brugerens mentale model. Jeg bruger en protokol kaldet "Vent, hvorfor?" Prøve. Bed en bruger om at se agenten udføre en opgave. Bed dem om at tale højt. Hver gang de stiller et spørgsmål: "Vent, hvorfor gjorde det det?" eller "Sidder den fast?" eller "Hørte det mig?" — du markerer et tidsstempel. Disse spørgsmål signalerer brugerforvirring. Brugeren mærker deres kontrol glide væk. For eksempel i en undersøgelse for en planlægningsassistent i sundhedsvæsenet, så brugerne agenten booke en tid. Skærmen sad statisk i fire sekunder. Deltagerne spurgte konsekvent: "Tjekker det min kalender eller lægens?"
Det spørgsmål afslørede et manglende Transparency Moment. Systemet skulle opdele den fire sekunders ventetid i to adskilte trin: "Tjekker din tilgængelighed" efterfulgt af "Synkronisering med udbyderens tidsplan." Denne lille ændring reducerede brugernes udtrykte niveauer af angst. Gennemsigtighed fejler, når den kun beskriver en systemhandling. Interfacet skal forbinde den tekniske proces med brugerens specifikke mål. En skærm, der viser "Tjekker din tilgængelighed", falder flad, fordi den mangler kontekst. Brugeren forstår, at AI kigger på en kalender, men de ved ikke hvorfor. Vi skal parre handlingen med resultatet. Systemet skal opdele denne fire sekunders ventetid i to adskilte trin. Først viser grænsefladen "Tjekker din kalender for at finde åbningstider." Derefter opdateres det til "Synkroniserer med udbyderens tidsplan for at sikre din aftale." Dette begrunder den tekniske proces i brugerens faktiske liv. Overvej en AI, der administrerer inventar for en lokal cafe. Systemet støder på en forsyningsmangel. En grænseflade, der læser "kontakt leverandør" eller "gennemgang af muligheder", skaber angst. Lederen spekulerer på, om systemet annullerer ordren eller køber et dyrt alternativ. En bedre tilgang er at forklare det tilsigtede resultat: "Evaluering af alternative leverandører for at opretholde din fredags leveringsplan." Dette fortæller brugeren præcis, hvad AI forsøger at opnå. Operationalisering af revisionen Du har gennemført beslutningsknude-revisionen og filtreret din liste gennem Impact and Risk Matrix. Du har nu en liste over vigtige øjeblikke for at være gennemsigtig. Dernæst skal du oprette dem i brugergrænsefladen. Dette trin kræver teamwork på tværs af forskellige afdelinger. Du kan ikke designe gennemsigtighed selv ved hjælp af et designværktøj. Du skal forstå, hvordan systemet fungerer bag kulisserne. Start med en logisk gennemgang. Mød din ledende systemdesigner. Medbring dit kort over beslutningsknuder. Du skal bekræfte, at systemet rent faktisk kan dele disse tilstande. Jeg oplever ofte, at det tekniske system ikke afslører den nøjagtige tilstand, jeg ønsker at vise. Ingeniøren siger måske, at systemet bare returnerer en generel "fungerende" status. Du skal presse på for en detaljeret opdatering. Du skal bruge systemet til at sende en specifik meddelelsenår den skifter fra at læse tekst til at tjekke regler. Uden den tekniske forbindelse er dit design umuligt at bygge. Inddrag derefter Content Design-teamet. Du har den tekniske årsag til AI'ens handling, men du har brug for en klar, menneskevenlig forklaring. Ingeniører leverer den underliggende proces, men indholdsdesignere leverer den måde, det kommunikeres på. Skriv ikke disse beskeder alene. En udvikler kan skrive "Udfører funktion 402", hvilket er teknisk korrekt, men meningsløst for brugeren. En designer kan skrive "Thinking", hvilket er venligt, men for vagt. En indholdsstrateg finder den rigtige mellemvej. De skaber specifikke sætninger, såsom "Scanning for ansvarsrisici", der viser, at AI fungerer uden at forvirre brugeren. Til sidst skal du teste gennemsigtigheden af dine beskeder. Vent ikke, indtil det endelige produkt er bygget, for at se, om teksten virker. Jeg udfører sammenligningstests på simple prototyper, hvor det eneste, der ændrer sig, er statusmeddelelsen. For eksempel viser jeg en gruppe (Gruppe A) en besked, der siger "Verificerer identitet" og en anden gruppe (Gruppe B) en besked, der siger "Kontrollerer offentlige databaser" (disse er opdigtede eksempler, men du forstår pointen). Så spørger jeg dem, hvilken AI der føles mere sikker. Du vil ofte opdage, at visse ord skaber bekymring, mens andre opbygger tillid. Du skal behandle ordlyden som noget, du skal teste og bevise effektivt. Hvordan dette ændrer designprocessen Udførelse af disse audits har potentialet til at styrke, hvordan et team arbejder sammen. Vi holder op med at aflevere polerede designfiler. Vi begynder at bruge rodede prototyper og delte regneark. Kerneværktøjet bliver en gennemsigtighedsmatrix. Ingeniører og indholdsdesignerne redigerer dette regneark sammen. De kortlægger de nøjagtige tekniske koder til de ord, brugeren vil læse. Hold vil opleve gnidninger under den logiske gennemgang. Forestil dig en designer, der spørger ingeniøren, hvordan AI'en beslutter at afvise en transaktion indsendt på en udgiftsrapport. Ingeniøren siger måske, at backend kun udsender en generisk statuskode som "Fejl: Manglende data". Designeren siger, at dette ikke er handlingsvenlig information på skærmen. Designeren forhandler med ingeniøren om at skabe en specifik teknisk krog. Ingeniøren skriver en ny regel, så systemet rapporterer præcist, hvad der mangler, såsom et manglende kvitteringsbillede. Indholdsdesignere fungerer som oversættere i denne fase. En udvikler kan skrive en teknisk nøjagtig streng som "Beregning af konfidensgrænse for leverandørmatching." En indholdsdesigner oversætter denne streng til en sætning, der opbygger tillid til et bestemt resultat. Strategen omskriver det som "Sammenligning af lokale leverandørpriser for at sikre din fredagslevering." Brugeren forstår handlingen og resultatet. Hele det tværfunktionelle team deltager i brugertestsessioner. De ser en rigtig person reagere på forskellige statusbeskeder. At se en bruger panik, fordi skærmen siger "Udførelse af handel", tvinger holdet til at genoverveje deres tilgang. Ingeniørerne og designerne er på linje med bedre formuleringer. De ændrer teksten til "Bekræftelse af tilstrækkelige midler", før de køber aktier. At teste sammen garanterer, at den endelige grænseflade tjener både systemlogikken og brugerens ro i sindet. Det kræver tid at inkorporere disse ekstra aktiviteter i holdets kalender. Slutresultatet bør dog være et team, der kommunikerer mere åbent, og brugere, der har en bedre forståelse af, hvad deres AI-drevne værktøjer gør på deres vegne (og hvorfor). Denne integrerede tilgang er en hjørnesten i at designe virkelig troværdige AI-oplevelser. Tillid er et designvalg Vi ser ofte tillid som et følelsesmæssigt biprodukt af en god brugeroplevelse. Det er lettere at se tillid som et mekanisk resultat af forudsigelig kommunikation. Vi opbygger tillid ved at vise den rigtige information på det rigtige tidspunkt. Vi ødelægger det ved at overvælde brugeren eller skjule maskineriet fuldstændigt. Start med Decision Node Audit, især for agentiske AI-værktøjer og -produkter. Find de øjeblikke, hvor systemet foretager en dom. Kortlæg disse øjeblikke til risikomatrixen. Hvis indsatsen er høj, skal du åbne kassen. Vis værket. I den næste artikel vil vi se på, hvordan man designer disse øjeblikke: hvordan man skriver kopien, strukturerer brugergrænsefladen og håndterer de uundgåelige fejl, når agenten tager fejl. Bilag: Beslutningsknudepunktets revisionstjekliste Fase 1: Opsætning og kortlægning ✅ Få holdet sammen: Få produktejere, forretningsanalytikere, designere,nøglebeslutningstagere og ingeniørerne, der byggede AI. Tip: Du har brug for ingeniørerne til at forklare den faktiske backend-logik. Forsøg ikke dette trin alene. ✅ Tegn hele processen: Dokumenter hvert trin, AI tager, fra brugerens første handling til det endelige resultat. Tip: En fysisk tavlesession fungerer ofte bedst til at tegne disse indledende trin. Fase 2: Lokalisering af den skjulte logik ✅ Find, hvor tingene er uklare: Se på proceskortet for ethvert sted, hvor AI'en sammenligner muligheder eller input, der ikke har ét perfekt match. ✅ Identificer de bedste gættrin: For hvert uklart sted skal du kontrollere, om systemet bruger en tillidsscore. Spørg for eksempel, om systemet er 85 procent sikkert. Det er de punkter, hvor AI'en træffer et endeligt valg. ✅ Undersøg valget: For hvert valgpunkt skal du finde ud af den specifikke interne matematik eller sammenligning, der udføres. Et eksempel er at matche en del af en kontrakt med en police. Et andet eksempel involverer at sammenligne et billede af en ødelagt bil med et bibliotek af beskadigede bilbilleder. Fase 3: Oprettelse af brugeroplevelsen ✅ Skriv klare forklaringer: Opret beskeder til brugeren, der klart beskriver den specifikke interne handling, der sker, når AI'en træffer et valg. Tip: Forbind dine budskaber i konkret virkelighed. Hvis en AI booker et møde med en klient på en lokal cafe, skal du fortælle brugeren, at systemet tjekker cafereservationssystemet. ✅ Opdater skærmen: Sæt disse nye, klare forklaringer i brugergrænsefladen. Erstat vage beskeder som gennemgang af kontrakter med dine specifikke forklaringer. ✅ Tjek for tillid: Sørg for, at de nye skærmmeddelelser giver brugerne en simpel grund til enhver ventetid eller resultat. Dette bør få dem til at føle sig selvsikre og tillidsfulde. Tip: Test disse meddelelser med faktiske brugere for at bekræfte, at de forstår det specifikke resultat, der opnås.
