Å designe for autonome agenter gir en unik frustrasjon. Vi gir en kompleks oppgave til en AI, den forsvinner i 30 sekunder (eller 30 minutter), og så kommer den tilbake med et resultat. Vi stirrer på skjermen. Fungerte det? Hallusinerte det? Sjekket den samsvarsdatabasen eller hoppet over det trinnet? Vi reagerer vanligvis på denne angsten med en av to ytterpunkter. Enten holder vi systemet en Black Box, skjuler alt for å opprettholde enkelheten, eller vi får panikk og gir en datadump, som streamer hver logglinje og API-kall til brukeren. Ingen av tilnærmingene adresserer direkte nyansen som trengs for å gi brukerne det ideelle nivået av åpenhet. Black Box lar brukerne føle seg maktesløse. Datadumpen skaper varslingsblindhet, og ødelegger effektiviteten agenten lovet å gi. Brukere ignorerer den konstante strømmen av informasjon til noe går i stykker, og da mangler de konteksten for å fikse det. Vi trenger en organisert måte å finne balansen på. I min forrige artikkel, "Designing For Agentic AI", så vi på grensesnittelementer som bygger tillit, som å vise AIs tiltenkte handling på forhånd (Intent Previews) og gi brukere kontroll over hvor mye AI gjør på egen hånd (Autonomy Dials). Men å vite hvilke elementer som skal brukes er bare en del av utfordringen. Det vanskeligste spørsmålet for designere er å vite når de skal brukes. Hvordan vet du hvilket spesifikt øyeblikk i en 30-sekunders arbeidsflyt som krever en Intent Preview og hvilket som kan håndteres med en enkel loggoppføring? Denne artikkelen gir en metode for å svare på det spørsmålet. Vi vil gå gjennom Decision Node Audit. Denne prosessen får designere og ingeniører i samme rom til å kartlegge backend-logikk til brukergrensesnittet. Du vil lære hvordan du kan finne de nøyaktige øyeblikkene en bruker trenger en oppdatering om hva AI gjør. Vi vil også dekke en Impact/Risk-matrise som vil bidra til å prioritere hvilke beslutningsnoder som skal vises og et eventuelt tilhørende designmønster som skal pares med den beslutningen. Transparency Moments: A Case Study Eksempel Tenk på Meridian (ikke ekte navn), et forsikringsselskap som bruker en agent AI for å behandle første ulykkeskrav. Brukeren laster opp bilder av kjøretøyskader og politianmeldelsen. Agenten forsvinner deretter i et minutt før han returnerer med en risikovurdering og et foreslått utbetalingsområde. Opprinnelig viste Meridians grensesnitt ganske enkelt Calculating Claim Status. Brukerne ble frustrerte. De hadde sendt inn flere detaljerte dokumenter og følte seg usikre på om AI i det hele tatt hadde gjennomgått politirapporten, som inneholdt formildende omstendigheter. Black Box skapte mistillit. For å fikse dette, gjennomførte designteamet en Decision Node Audit. De fant at AI utførte tre distinkte, sannsynlighetsbaserte trinn, med mange mindre trinn innebygd:
Bildeanalyse Agenten sammenlignet skadebildene med en database med typiske bilulykkesscenarier for å estimere reparasjonskostnadene. Dette innebar en selvtillitsscore. Tekstgjennomgang Den skannet politirapporten for nøkkelord som påvirker ansvar (f.eks. feil, værforhold, edruelighet). Dette innebar en sannsynlighetsvurdering av rettslig stilling. Policy Cross ReferenceIt matchet kravdetaljene mot brukerens spesifikke policyvilkår, og søkte etter unntak eller dekningsgrenser. Dette innebar også sannsynlighetsmatching.
Teamet gjorde disse trinnene til åpenhetsøyeblikk. Grensesnittsekvensen ble oppdatert til:
Vurdere skadebilder: Sammenligning med 500 kjøretøykollisjonsprofiler. Gjennomgang av politirapport: Analyserer søkeord for ansvar og juridisk presedens. Bekrefte policydekning: Se etter spesifikke ekskluderinger i planen din.
Systemet tok fortsatt like lang tid, men den eksplisitte kommunikasjonen om agentens interne funksjoner gjenopprettet brukertilliten. Brukerne forsto at AI-en utførte den komplekse oppgaven den var designet for, og de visste nøyaktig hvor de skulle fokusere oppmerksomheten hvis den endelige vurderingen virket unøyaktig. Dette designvalget forvandlet et øyeblikk av angst til et øyeblikk av forbindelse med brukeren. Bruk av innvirkning/risikomatrisen: hva vi valgte å skjule De fleste AI-opplevelser har ingen mangel på hendelser og beslutningsnoder som potensielt kan vises under behandlingen. Et av de mest kritiske resultatene av tilsynet var å bestemme hva som skulle holdes usynlig. I Meridian-eksemplet genererte backend-loggene 50+ hendelser per krav. Vi kunne som standard ha vist hver hendelse ettersom de ble behandlet som en del av brukergrensesnittet. I stedet brukte vi risikomatrisen for å beskjære dem:
Logghendelse: Ping-serverWest-2 for redundanssjekk. Filtrer dom: Skjul. (Low Stakes, High Technicality).
Logghendelse: Sammenligner reparasjonsestimat med BlueBook-verdi. Filterbedømmelse: Vis. (Høy innsats, påvirker brukerens utbetaling).
Ved å kutte ut de unødvendige detaljene, var den viktige informasjonen – som dekningsbekreftelsen – mer virkningsfull. Vi laget et åpent grensesnitt og designet en åpen opplevelse. Denne tilnærmingen bruker ideen om at folk føler seg bedre med en tjeneste når de kan se arbeidet som utføres. Ved å vise de spesifikke trinnene (Vurdere, gjennomgå, verifisere), endret vi en 30-sekunders ventetid fra en tid med bekymring («Er den ødelagt?») til en tid da vi føler at noe verdifullt blir skapt («Det tenker»). La oss nå se nærmere på hvordan vi kan gjennomgå beslutningsprosessen i produktene våre for å identifisere nøkkeløyeblikk som krever tydelig informasjon. Beslutningsnoden Revisjon Åpenhet svikter når vi behandler det som et stilvalg snarere enn et funksjonskrav. Vi har en tendens til å spørre: "Hvordan skal brukergrensesnittet se ut?" før vi spør: "Hva bestemmer agenten egentlig?" Decision Node Audit er en enkel måte å gjøre AI-systemer lettere å forstå. Det fungerer ved å nøye kartlegge systemets interne prosess. Hovedmålet er å finne og tydelig definere de nøyaktige øyeblikkene hvor systemet slutter å følge sine fastsatte regler og i stedet foretar et valg basert på tilfeldigheter eller estimering. Ved å kartlegge denne strukturen kan skapere vise disse usikkerhetspunktene direkte til personene som bruker systemet. Dette endrer systemoppdateringer fra å være vage utsagn til spesifikke, pålitelige rapporter om hvordan AI kom til sin konklusjon. I tillegg til forsikringscasestudien ovenfor, har jeg nylig jobbet med et team som bygger en anskaffelsesagent. Systemet gjennomgikk leverandørkontrakter og flagget risikoer. Opprinnelig viste skjermen en enkel fremdriftslinje: "Gjennomgå kontrakter." Brukere hatet det. Vår forskning indikerte at de følte seg engstelige for de juridiske implikasjonene av en manglende klausul. Vi fikset dette ved å gjennomføre en Decision Node Audit. Jeg har inkludert en trinn-for-trinn-sjekkliste for gjennomføring av denne revisjonen ved avslutningen av denne artikkelen. Vi kjørte en økt med ingeniørene og skisserte hvordan systemet fungerer. Vi identifiserte "Beslutningspunkter" - øyeblikk hvor AI måtte velge mellom to gode alternativer. I standard dataprogrammer er prosessen klar: Hvis A skjer, vil B alltid skje. I AI-systemer er prosessen ofte basert på tilfeldigheter. AI tror A sannsynligvis er det beste valget, men det er kanskje bare 65 % sikkert. I kontraktssystemet fant vi et øyeblikk da AI sjekket ansvarsvilkårene mot selskapets regler. Det var sjelden en perfekt match. AI-en måtte avgjøre om en 90 % match var god nok. Dette var et sentralt beslutningspunkt.
Når vi identifiserte denne noden, eksponerte vi den for brukeren. I stedet for "Gjennomgå kontrakter", oppdaterte grensesnittet for å si: "Ansvarsklausul varierer fra standardmal. Analyserer risikonivå." Denne spesifikke oppdateringen ga brukere tillit. De visste at agenten sjekket ansvarsklausulen. De forsto årsaken til forsinkelsen og fikk tillit til at den ønskede handlingen skjedde på baksiden. De visste også hvor de skulle grave dypere når agenten genererte kontrakten. For å sjekke hvordan AI tar beslutninger, må du jobbe tett med ingeniørene, produktsjefene, forretningsanalytikerne og nøkkelpersoner som tar valgene (ofte skjulte) som påvirker hvordan AI-verktøyet fungerer. Tegn frem trinnene verktøyet tar. Merk hvert sted hvor prosessen endrer retning fordi en sannsynlighet er oppfylt. Dette er stedene du bør fokusere på å være mer transparent. Som vist i figur 2 nedenfor, involverer beslutningsnoderevisjonen disse trinnene:
Få teamet sammen: Ta med produkteiere, forretningsanalytikere, designere, viktige beslutningstakere og ingeniørene som bygde AI. For eksempel Tenk på et produktteam som bygger et AI-verktøy designet for å gjennomgå rotete juridiske kontrakter. Teamet inkluderer UX-designeren, produktsjefen, UX-forskeren, en praktiserende advokat som fungerer som sakseksperten, og backend-ingeniøren som skrev tekstanalysekoden.
Tegn hele prosessen: Dokumenter hvert trinn AI tar, fra brukerens første handling til det endelige resultatet. Teamet står ved en tavle og skisserer hele sekvensen for en nøkkelarbeidsflyt som innebærer at AI søker etter en ansvarsklausul i en kompleks kontrakt. Advokaten laster oppen femti siders PDF → Systemet konverterer dokumentet til lesbar tekst. → AI-en skanner sidene for ansvarsklausuler. → Brukeren venter. → Øyeblikk eller minutter senere fremhever verktøyet de funnet avsnittene i gult på brukergrensesnittet. De gjør dette for mange andre arbeidsflyter som verktøyet også imøtekommer.
Finn hvor ting er uklart: Se på prosesskartet for ethvert sted der AI sammenligner alternativer eller innganger som ikke har en perfekt match. Teamet ser på tavlen for å oppdage de tvetydige trinnene. Konvertering av et bilde til tekst følger strenge regler. Å finne en spesifikk ansvarsklausul innebærer gjetting. Hvert firma skriver disse klausulene forskjellig, så AI må veie flere alternativer og lage en prediksjon i stedet for å finne en eksakt ordmatch.
Identifiser trinnene for «beste gjetning»: For hvert uklart sted, sjekk om systemet bruker en konfidensscore (er det for eksempel 85 % sikkert?). Dette er punktene hvor AI tar et endelig valg. Systemet må gjette (gi en sannsynlighet) hvilken(e) paragraf(er) som ligner en standard ansvarsklausul. Den tildeler en konfidensscore til sin beste gjetning. Den gjetningen er en beslutningsnode. Grensesnittet må fortelle advokaten at det fremhever en potensiell match, i stedet for å si at den fant den definitive klausulen.
Undersøk valget: For hvert valgpunkt, finn ut den spesifikke interne matematikken eller sammenligningen som gjøres (f.eks. matche en del av en kontrakt med en policy eller sammenligne et bilde av en ødelagt bil med et bibliotek med skadede bilbilder). Ingeniøren forklarer at systemet sammenligner de ulike avsnittene med en database med standard ansvarsklausuler fra tidligere firmasaker. Den beregner en tekstlikhetsscore for å avgjøre en kamp basert på sannsynligheter.
Skriv klare forklaringer: Lag meldinger til brukeren som tydelig beskriver den spesifikke interne handlingen som skjer når AI tar et valg. Innholdsdesigneren skriver en spesifikk melding for akkurat dette øyeblikket. Teksten lyder: Sammenligning av dokumenttekst med standard faste klausuler for å identifisere potensielle ansvarsrisikoer.
Oppdater skjermen: Sett disse nye, klare forklaringene inn i brukergrensesnittet, og erstatt vage meldinger som "Gjennomgå kontrakter." Designteamet fjerner den generiske Processing PDF-innlastingsspinneren. De setter inn den nye forklaringen i en statuslinje som ligger rett over dokumentvisningen mens AI-en tenker.
Sjekk for tillit: Sørg for at de nye skjermmeldingene gir brukerne en enkel grunn til ventetid eller resultat, noe som bør få dem til å føle seg mer selvsikre og tillitsfulle.
Effekt/risikomatrisen Når du ser nøye på AI-prosessen, vil du sannsynligvis finne mange punkter der den tar et valg. En AI kan gjøre dusinvis av små valg for en enkelt kompleks oppgave. Å vise dem alle skaper for mye unødvendig informasjon. Du må gruppere disse valgene. Du kan bruke en Impact/Risk Matrix for å sortere disse valgene basert på typene handling(er) AI tar. Her er eksempler på innvirkning/risikomatriser: Se først etter beslutninger med lav innsats og lav innvirkning. Lav innsats / lav innvirkning
Eksempel: Organisere en filstruktur eller gi nytt navn til et dokument. Gjennomsiktighetsbehov: Minimalt. Et subtilt toastvarsel eller en loggoppføring er tilstrekkelig. Brukere kan enkelt angre disse handlingene.
Identifiser deretter avgjørelsene med høy innsats og stor innvirkning. High Stakes / High Impact
Eksempel: Å avslå en lånesøknad eller gjennomføre en aksjehandel. Behov for åpenhet: Høyt. Disse handlingene krever bevis på arbeid. Systemet må demonstrere begrunnelsen før eller umiddelbart etter hvert som det virker.
Vurder en finansiell handelsrobot som behandler alle kjøps-/salgsordrer likt. Den utfører en handel på $5 med samme opasitet som en handel på $50 000. Brukere kan stille spørsmål ved om verktøyet gjenkjenner den potensielle effekten av åpenhet på handel på et stort dollarbeløp. De trenger at systemet stopper og viser arbeidet sitt for handel med høy innsats. Løsningen er å introdusere en vurderingslogikktilstand for enhver transaksjon som overstiger et spesifikt dollarbeløp, slik at brukeren kan se faktorene som styrer beslutningen før utførelse. Kartlegging av noder til mønstre: en rubrikk for valg av designmønster Når du har identifisert opplevelsens viktigste beslutningsnoder, må du bestemme hvilket brukergrensesnittmønster som gjelder for hver enkelt du skal vise. I Designing For Agentic AI introduserte vi mønstre som Intent Preview (for kontroll med høy innsats) og Action Audit (for retrospektiv sikkerhet). Den avgjørende faktoren for å velge mellom dem er reversibilitet. Vi filtrerer hverbeslutningsnode gjennom påvirkningsmatrisen for å tildele riktig mønster: Høy innsats og irreversibel: Disse nodene krever en forhåndsvisning av intensjon. Fordi brukeren ikke enkelt kan angre handlingen (f.eks. permanent sletting av en database), må åpenhetsøyeblikket skje før utførelse. Systemet må pause, forklare intensjonen og kreve bekreftelse. Høy innsats og reversibel: Disse nodene kan stole på Action Audit & Undo-mønsteret. Hvis den AI-drevne salgsagenten flytter en kundeemne til en annen pipeline, kan den gjøre det autonomt så lenge den varsler brukeren og tilbyr en umiddelbar Angre-knapp. Ved å strengt kategorisere noder på denne måten, unngår vi "varslingstretthet." Vi reserverer forhåndsvisningen av intensjon med høy friksjon kun for de virkelig irreversible øyeblikkene, mens vi stoler på Action Audit for å opprettholde hastigheten for alt annet.
Vendbar Irreversibel Lav innvirkning Type: Auto-ExecuteUI: Passive Toast / LogEx: Gi nytt navn til en fil Type: ConfirmUI: Enkelt angrealternativEks: Arkivering av en e-post Høy effekt Type: ReviewUI: Notification + Review TrailEx: Sender et utkast til en klient Type: Intent previewUI: Modal / eksplisitt tillatelseEx: Sletting av en server
Tabell 1: Slag- og reversibilitetsmatrisen kan deretter brukes til å kartlegge øyeblikkene dine med åpenhet til designmønstre. Kvalitativ validering: "Venten, hvorfor?" Test Du kan identifisere potensielle noder på en tavle, men du må validere dem med menneskelig atferd. Du må bekrefte om kartet ditt samsvarer med brukerens mentale modell. Jeg bruker en protokoll kalt "Vent, hvorfor?" Test. Be en bruker om å se agenten fullføre en oppgave. Be dem om å snakke høyt. Hver gang de stiller et spørsmål: "Vent, hvorfor gjorde det det?" eller "Sitter den fast?" eller "Hørte det meg?" — du merker et tidsstempel. Disse spørsmålene signaliserer brukerforvirring. Brukeren kjenner at kontrollen glipper. For eksempel, i en studie for en planleggingsassistent for helsetjenester, så brukerne at agenten booket en avtale. Skjermen satt statisk i fire sekunder. Deltakerne spurte konsekvent: "Sjekker det kalenderen min eller legens?"
Det spørsmålet avslørte et manglende Transparency Moment. Systemet trengte å dele den fire sekunder lange ventetiden i to forskjellige trinn: "Sjekker tilgjengeligheten din" etterfulgt av "Synkroniserer med leverandørens tidsplan." Denne lille endringen reduserte brukernes uttrykte nivåer av angst. Åpenhet mislykkes når den bare beskriver en systemhandling. Grensesnittet må koble den tekniske prosessen til brukerens spesifikke mål. En skjerm som viser "Sjekker tilgjengeligheten din" faller flatt fordi den mangler kontekst. Brukeren forstår at AI ser på en kalender, men de vet ikke hvorfor. Vi må pare handlingen med resultatet. Systemet må dele den fire sekunder lange ventetiden i to forskjellige trinn. Først viser grensesnittet "Sjekker kalenderen din for å finne åpningstider." Deretter oppdateres den til "Synkroniserer med leverandørens tidsplan for å sikre avtalen din." Dette begrunner den tekniske prosessen i brukerens faktiske liv. Vurder en AI som administrerer inventar for en lokal kafé. Systemet møter mangel på forsyning. Et grensesnitt som leser "kontakte leverandør" eller "gjennomgangsalternativer" skaper angst. Lederen lurer på om systemet kansellerer bestillingen eller kjøper et dyrt alternativ. En bedre tilnærming er å forklare det tiltenkte resultatet: "Vurdere alternative leverandører for å opprettholde leveringsplanen din på fredag." Dette forteller brukeren nøyaktig hva AI prøver å oppnå. Operasjonalisering av revisjonen Du har fullført Decision Node Audit og filtrert listen gjennom Impact and Risk Matrix. Du har nå en liste over viktige øyeblikk for å være gjennomsiktig. Deretter må du opprette dem i brukergrensesnittet. Dette trinnet krever teamarbeid på tvers av ulike avdelinger. Du kan ikke designe åpenhet selv ved å bruke et designverktøy. Du må forstå hvordan systemet fungerer bak kulissene. Start med en logisk gjennomgang. Møt din ledende systemdesigner. Ta med kartet over beslutningsnoder. Du må bekrefte at systemet faktisk kan dele disse tilstandene. Jeg opplever ofte at det tekniske systemet ikke avslører den nøyaktige tilstanden jeg vil vise. Ingeniøren kan si at systemet bare returnerer en generell "fungerende" status. Du må presse på for en detaljert oppdatering. Du trenger at systemet sender en spesifikk meldingnår den bytter fra å lese tekst til å sjekke regler. Uten den tekniske forbindelsen er designet ditt umulig å bygge. Deretter involverer du innholdsdesignteamet. Du har den tekniske grunnen til AIs handling, men du trenger en klar, menneskevennlig forklaring. Ingeniører gir den underliggende prosessen, men innholdsdesignere gir måten det kommuniseres på. Ikke skriv disse meldingene alene. En utvikler kan skrive "Utfører funksjon 402", som er teknisk korrekt, men meningsløst for brukeren. En designer kan skrive "Thinking", som er vennlig, men for vagt. En innholdsstrateg finner den rette mellomveien. De lager spesifikke setninger, for eksempel "Skanning etter ansvarsrisiko", som viser at AI fungerer uten å forvirre brukeren. Til slutt, test åpenheten til meldingene dine. Ikke vent til det endelige produktet er bygget for å se om teksten fungerer. Jeg gjennomfører sammenligningstester på enkle prototyper der det eneste som endrer seg er statusmeldingen. For eksempel viser jeg en gruppe (Gruppe A) en melding som sier «Bekrefter identitet» og en annen gruppe (Gruppe B) en melding som sier «Sjekker offentlige databaser» (dette er oppdiktede eksempler, men du forstår poenget). Så spør jeg dem hvilken AI som føles tryggere. Du vil ofte oppdage at visse ord skaper bekymring, mens andre bygger tillit. Du må behandle ordlyden som noe du trenger for å teste og bevise effektivt. Hvordan dette endrer designprosessen Gjennomføring av disse revisjonene har potensial til å styrke hvordan et team jobber sammen. Vi slutter å levere polerte designfiler. Vi begynner å bruke rotete prototyper og delte regneark. Kjerneverktøyet blir en åpenhetsmatrise. Ingeniører og innholdsdesignerne redigerer dette regnearket sammen. De kartlegger de eksakte tekniske kodene til ordene brukeren skal lese. Lag vil oppleve friksjon under den logiske gjennomgangen. Se for deg en designer som spør ingeniøren hvordan AI bestemmer seg for å avslå en transaksjon som er sendt inn på en utgiftsrapport. Ingeniøren kan si at backend bare gir ut en generisk statuskode som "Feil: Manglende data". Designeren sier at dette ikke er handlingsbar informasjon på skjermen. Designeren forhandler med ingeniøren for å lage en spesifikk teknisk krok. Ingeniøren skriver en ny regel slik at systemet rapporterer nøyaktig hva som mangler, for eksempel et manglende kvitteringsbilde. Innholdsdesignere fungerer som oversettere i denne fasen. En utvikler kan skrive en teknisk nøyaktig streng som "Beregner konfidensgrense for leverandørmatching." En innholdsdesigner oversetter den strengen til en setning som bygger tillit for et bestemt resultat. Strategen omskriver det som "Sammenligning av lokale leverandørpriser for å sikre leveringen din på fredag." Brukeren forstår handlingen og resultatet. Hele det tverrfunksjonelle teamet deltar i brukertesting. De ser på en ekte person reagere på forskjellige statusmeldinger. Å se en bruker panikk fordi skjermen sier "Utføre handel" tvinger teamet til å revurdere sin tilnærming. Ingeniørene og designerne innretter seg etter bedre ordlyd. De endrer teksten til "Bekrefte tilstrekkelige midler" før de kjøper aksjer. Testing sammen garanterer at det endelige grensesnittet tjener både systemlogikken og brukerens trygghet. Det krever tid å inkludere disse tilleggsaktivitetene i teamets kalender. Sluttresultatet bør imidlertid være et team som kommuniserer mer åpent, og brukere som har en bedre forståelse av hva deres AI-drevne verktøy gjør på deres vegne (og hvorfor). Denne integrerte tilnærmingen er en hjørnestein i å designe virkelig pålitelige AI-opplevelser. Tillit er et designvalg Vi ser ofte på tillit som et følelsesmessig biprodukt av en god brukeropplevelse. Det er lettere å se tillit som et mekanisk resultat av forutsigbar kommunikasjon. Vi bygger tillit ved å vise riktig informasjon til rett tid. Vi ødelegger det ved å overvelde brukeren eller skjule maskineriet fullstendig. Start med Decision Node Audit, spesielt for agentiske AI-verktøy og produkter. Finn øyeblikkene hvor systemet foretar en vurdering. Kartlegg disse øyeblikkene til risikomatrisen. Hvis innsatsen er høy, åpne boksen. Vis verket. I den neste artikkelen vil vi se på hvordan du utformer disse øyeblikkene: hvordan du skriver kopien, strukturerer brukergrensesnittet og håndterer de uunngåelige feilene når agenten tar feil. Vedlegg: Beslutningsnodens revisjonssjekkliste Fase 1: Oppsett og kartlegging ✅ Få teamet sammen: Ta med produkteiere, forretningsanalytikere, designere,sentrale beslutningstakere, og ingeniørene som bygde AI. Hint: Du trenger ingeniørene til å forklare den faktiske backend-logikken. Ikke prøv dette trinnet alene. ✅ Tegn hele prosessen: Dokumenter hvert trinn AI tar, fra brukerens første handling til det endelige resultatet. Tips: En fysisk tavleøkt fungerer ofte best for å tegne disse innledende trinnene. Fase 2: Finne den skjulte logikken ✅ Finn hvor ting er uklart: Se på prosesskartet for et hvilket som helst sted der AI sammenligner alternativer eller innganger som ikke har en perfekt match. ✅ Identifiser de beste gjetningstrinnene: For hvert uklart sted, sjekk om systemet bruker en konfidensscore. Spør for eksempel om systemet er 85 prosent sikkert. Dette er punktene hvor AI tar et endelig valg. ✅ Undersøk valget: For hvert valgpunkt, finn ut den spesifikke interne matematikken eller sammenligningen som gjøres. Et eksempel er å matche en del av en kontrakt med en polise. Et annet eksempel innebærer å sammenligne et bilde av en ødelagt bil med et bibliotek med skadede bilbilder. Fase 3: Lage brukeropplevelsen ✅ Skriv klare forklaringer: Lag meldinger til brukeren som tydelig beskriver den spesifikke interne handlingen som skjer når AI tar et valg. Hint: Jord budskapene dine i konkret virkelighet. Hvis en AI bestiller et møte med en klient på en lokal kafé, fortell brukeren at systemet sjekker kaféreservasjonssystemet. ✅ Oppdater skjermen: Sett disse nye, klare forklaringene inn i brukergrensesnittet. Erstatt vage meldinger som gjennomgang av kontrakter med dine spesifikke forklaringer. ✅ Sjekk for tillit: Sørg for at de nye skjermmeldingene gir brukerne en enkel grunn for ventetid eller resultat. Dette bør få dem til å føle seg trygge og tillitsfulle. Hint: Test disse meldingene med faktiske brukere for å bekrefte at de forstår det spesifikke resultatet som oppnås.
