Ontwerp vir outonome agente bied 'n unieke frustrasie. Ons gee 'n komplekse taak aan 'n KI, dit verdwyn vir 30 sekondes (of 30 minute), en dan keer dit terug met 'n resultaat. Ons staar na die skerm. Het dit gewerk? Het dit hallusineer? Het dit die voldoeningsdatabasis nagegaan of daardie stap oorgeslaan? Ons reageer tipies op hierdie angs met een van twee uiterstes. Ons hou óf die stelsel 'n Black Box, steek alles weg om eenvoud te handhaaf, óf ons word paniekerig en verskaf 'n Data Dump, wat elke loglyn en API-oproep na die gebruiker stroom. Geen van die benaderings spreek direk die nuanse aan wat nodig is om gebruikers die ideale vlak van deursigtigheid te bied nie. Die Black Box laat gebruikers magteloos voel. Die Data Dump skep kennisgewingblindheid, wat die doeltreffendheid wat die agent belowe het om te voorsien, vernietig. Gebruikers ignoreer die konstante stroom inligting totdat iets breek, op watter punt hulle nie die konteks het om dit reg te stel nie. Ons het 'n georganiseerde manier nodig om die balans te vind. In my vorige artikel, "Ontwerp vir Agentiese KI", het ons gekyk na koppelvlakelemente wat vertroue bou, soos om die KI se beoogde aksie vooraf te wys (Intent Previews) en om gebruikers beheer te gee oor hoeveel die KI op sy eie doen (Autonomy Dials). Maar om te weet watter elemente om te gebruik, is slegs deel van die uitdaging. Die moeiliker vraag vir ontwerpers is om te weet wanneer om dit te gebruik. Hoe weet jy watter spesifieke oomblik in 'n 30-sekonde-werkvloei 'n Voornemevoorskou vereis en watter kan met 'n eenvoudige loginskrywing hanteer word? Hierdie artikel verskaf 'n metode om daardie vraag te beantwoord. Ons sal deur die Besluitnodusoudit loop. Hierdie proses kry ontwerpers en ingenieurs in dieselfde kamer om backend-logika na die gebruikerskoppelvlak te karteer. Jy sal leer hoe om die presiese oomblikke vas te stel wat 'n gebruiker 'n opdatering benodig oor wat die KI doen. Ons sal ook 'n Impak/Risiko-matriks dek wat sal help om te prioritiseer watter besluitnodusse om te vertoon en enige gepaardgaande ontwerppatroon om met daardie besluit te koppel. Deursigtigheidsmomente: 'n Gevallestudie voorbeeld Oorweeg Meridian (nie regte naam nie), 'n versekeringsmaatskappy wat 'n agentiese KI gebruik om aanvanklike ongelukseise te verwerk. Die gebruiker laai foto's van voertuigskade en die polisieverslag op. Die agent verdwyn dan vir 'n minuut voordat hy terugkeer met 'n risikobepaling en 'n voorgestelde uitbetalingsreeks. Aanvanklik het Meridian se koppelvlak eenvoudig die berekening van eisstatus gewys. Gebruikers het gefrustreerd geraak. Hulle het verskeie gedetailleerde dokumente ingedien en het onseker gevoel of die KI selfs die polisieverslag, wat versagtende omstandighede bevat, nagegaan het. Die Black Box het wantroue geskep. Om dit reg te stel, het die ontwerpspan 'n Besluitnodusoudit uitgevoer. Hulle het gevind dat die KI drie afsonderlike, waarskynlikheidsgebaseerde stappe uitgevoer het, met talle kleiner stappe ingebed:
BeeldanaliseDie agent het die skadefoto's vergelyk met 'n databasis van tipiese motorongelukscenario's om die herstelkoste te skat. Dit het 'n vertrouetelling behels. Tekshersiening Dit het die polisieverslag geskandeer vir sleutelwoorde wat aanspreeklikheid beïnvloed (bv. skuld, weerstoestande, nugterheid). Dit het 'n waarskynlikheidsbepaling van regsaansien behels. Poliskruisverwysing Dit het ooreenstem met die eisbesonderhede teen die gebruiker se spesifieke polisbepalings, op soek na uitsonderings of dekkingsperke. Dit het ook waarskynlikheidspassing behels.
Die span het hierdie stappe in deursigtigheidsoomblikke omskep. Die koppelvlakvolgorde is opgedateer na:
Assessering van skadefoto's: Vergelyking met 500 voertuigimpakprofiele. Hersiening van polisieverslag: Ontleding van aanspreeklikheidsleutelwoorde en wetlike presedent. Verifieer polisdekking: Kyk vir spesifieke uitsluitings in jou plan.
Die stelsel het steeds dieselfde tyd geneem, maar die eksplisiete kommunikasie oor die agent se interne werking het gebruikersvertroue herstel. Gebruikers het verstaan dat die KI die komplekse taak verrig waarvoor dit ontwerp is, en hulle het presies geweet waar om hul aandag te vestig as die finale beoordeling onakkuraat lyk. Hierdie ontwerpkeuse het 'n oomblik van angs omskep in 'n oomblik van konneksie met die gebruiker. Pas die impak-/risikomatriks toe: wat ons gekies het om weg te steek Die meeste KI-ervarings het geen tekort aan gebeure en besluitknooppunte wat moontlik tydens verwerking vertoon kan word nie. Een van die mees kritieke uitkomste van die oudit was om te besluit wat om onsigbaar te hou. In die Meridian-voorbeeld het die backend-logboeke 50+ gebeurtenisse per eis gegenereer. Ons kon verstek het om elke gebeurtenis te vertoon aangesien dit as deel van die UI verwerk is. In plaas daarvan het ons die risikomatriks toegepas om hulle te snoei:
Log Gebeurtenis: Ping ServerWest-2 vir oortolligheidskontrole. Filteruitspraak: versteek. (Lae belange, hoë tegnikaliteit).
Log Gebeurtenis: Vergelyk herstelskatting met BlueBook-waarde. Filteruitspraak: Wys. (Hoë insette, beïnvloed gebruiker se uitbetaling).
Deur die onnodige besonderhede uit te sny, was die belangrike inligting - soos die dekkingsverifikasie - meer impakvol. Ons het 'n oop koppelvlak geskep en 'n oop ervaring ontwerp. Hierdie benadering gebruik die idee dat mense beter voel oor 'n diens wanneer hulle kan sien hoe die werk gedoen word. Deur die spesifieke stappe te wys (Assessering, Hersiening, Verifiëring), het ons 'n 30-sekonde wag verander van 'n tyd van bekommernis ("Is dit stukkend?") na 'n tyd van voel asof iets waardevol geskep word ("Dit is dink"). Kom ons kyk nou van naderby na hoe ons die besluitnemingsproses in ons produkte kan hersien om sleuteloomblikke te identifiseer wat duidelike inligting vereis. Die Besluitnodusoudit Deursigtigheid misluk wanneer ons dit as 'n stylkeuse eerder as 'n funksionele vereiste behandel. Ons is geneig om te vra: "Hoe moet die UI lyk?" voordat ons vra: "Wat besluit die agent nou eintlik?" Die Besluitknoop-oudit is 'n eenvoudige manier om KI-stelsels makliker te verstaan. Dit werk deur die stelsel se interne proses noukeurig te karteer. Die hoofdoel is om die presiese oomblikke te vind en duidelik te definieer waar die stelsel ophou om sy vasgestelde reëls te volg en eerder 'n keuse maak gebaseer op toeval of skatting. Deur hierdie struktuur te karteer, kan skeppers hierdie punte van onsekerheid direk aan die mense wat die stelsel gebruik, wys. Dit verander stelselopdaterings van vae stellings na spesifieke, betroubare verslae oor hoe die KI tot sy gevolgtrekking gekom het. Benewens die versekeringsgevallestudie hierbo, het ek onlangs saam met 'n span gewerk om 'n verkrygingsagent te bou. Die stelsel het verskafferkontrakte hersien en risiko's gemerk. Oorspronklik het die skerm 'n eenvoudige vorderingsbalk vertoon: "Hersien kontrakte." Gebruikers het dit gehaat. Ons navorsing het aangedui dat hulle angstig voel oor die wetlike implikasies van 'n ontbrekende klousule. Ons het dit reggestel deur 'n Besluitnodusoudit uit te voer. Ek het 'n stap-vir-stap kontrolelys ingesluit vir die uitvoering van hierdie oudit aan die einde van hierdie artikel. Ons het 'n sessie met die ingenieurs gehou en uiteengesit hoe die stelsel werk. Ons het "Besluitpunte" geïdentifiseer - oomblikke waar die KI tussen twee goeie opsies moes kies. In standaard rekenaarprogramme is die proses duidelik: as A gebeur, dan sal B altyd gebeur. In KI-stelsels is die proses dikwels op toeval gebaseer. Die KI dink A is waarskynlik die beste keuse, maar dit is dalk net 65% seker. In die kontrakstelsel het ons 'n oomblik gevind toe die KI die aanspreeklikheidsbepalings teen ons maatskappyreëls nagegaan het. Dit was selde 'n perfekte pasmaat. Die KI moes besluit of 'n 90%-wedstryd goed genoeg is. Dit was 'n belangrike besluit.
Sodra ons hierdie nodus geïdentifiseer het, het ons dit aan die gebruiker blootgestel. In plaas van "Hersien van kontrakte," het die koppelvlak opgedateer om te sê: "Aanspreeklikheidsklousule verskil van standaard sjabloon. Ontleed risikovlak." Hierdie spesifieke opdatering het gebruikers vertroue gegee. Hulle het geweet die agent het die aanspreeklikheidsklousule nagegaan. Hulle het die rede vir die vertraging verstaan en vertroue gekry dat die verlangde aksie aan die agterkant plaasvind. Hulle het ook geweet waar om dieper in te delf sodra die agent die kontrak gegenereer het. Om te kyk hoe die KI besluite neem, moet jy nou saamwerk met jou ingenieurs, produkbestuurders, besigheidsontleders en sleutelpersone wat die keuses maak (dikwels versteek) wat beïnvloed hoe die KI-instrument funksioneer. Teken die stappe wat die instrument neem uit. Merk elke plek waar die proses van rigting verander omdat daar aan 'n waarskynlikheid voldoen word. Dit is die plekke waar jy moet fokus om meer deursigtig te wees. Soos in Figuur 2 hieronder getoon, behels die Besluitnodusoudit hierdie stappe:
Kry die span bymekaar: Bring die produkeienaars, besigheidsontleders, ontwerpers, sleutelbesluitnemers en die ingenieurs in wat die KI gebou het. Byvoorbeeld, Dink aan 'n produkspan wat 'n KI-instrument bou wat ontwerp is om morsige wettige kontrakte te hersien. Die span sluit in die UX-ontwerper, die produkbestuurder, die UX-navorser, 'n praktiserende prokureur wat as die vakkundige optree, en die backend-ingenieur wat die teksanalise-kode geskryf het.
Teken die hele proses: Dokumenteer elke stap wat die KI neem, van die gebruiker se eerste aksie tot die finale resultaat. Die span staan by 'n witbord en skets die hele volgorde vir 'n sleutelwerkvloei wat behels dat die KI na 'n aanspreeklikheidsklousule in 'n komplekse kontrak soek. Die prokureur laai op'n PDF van vyftig bladsye → Die stelsel skakel die dokument om in leesbare teks. → Die KI skandeer die bladsye vir aanspreeklikheidsklousules. → Die gebruiker wag. → Oomblikke of minute later beklemtoon die hulpmiddel die gevind paragrawe in geel op die gebruikerskoppelvlak. Hulle doen dit vir baie ander werkstrome wat die instrument ook akkommodeer.
Vind waar dinge onduidelik is: Kyk na die proseskaart vir enige plek waar die KI opsies of insette vergelyk wat nie een perfekte pasmaat het nie. Die span kyk na die witbord om die dubbelsinnige stappe raak te sien. Die omskakeling van 'n prent na teks volg streng reëls. Om 'n spesifieke aanspreeklikheidsklousule te vind, behels raaiwerk. Elke firma skryf hierdie klousules anders, so die KI moet verskeie opsies weeg en 'n voorspelling maak in plaas daarvan om 'n presiese woordpassing te vind.
Identifiseer die 'beste raai'-stappe: Vir elke onduidelike plek, kyk of die stelsel 'n vertrouetelling gebruik (is dit byvoorbeeld 85% seker?). Dit is die punte waar die KI 'n finale keuse maak. Die stelsel moet raai ('n waarskynlikheid gee) watter paragraaf(s) baie ooreenstem met 'n standaardaanspreeklikheidsklousule. Dit ken 'n vertrouenstelling toe aan sy beste raaiskoot. Daardie raaiskoot is 'n besluitknooppunt. Die koppelvlak moet die prokureur vertel dat dit 'n potensiële passing uitlig, eerder as om te sê dat dit die definitiewe klousule gevind het.
Ondersoek die keuse: Bepaal vir elke keusepunt die spesifieke interne wiskunde of vergelyking wat gedoen word (bv. pas 'n deel van 'n kontrak by 'n polis of vergelyk 'n prentjie van 'n stukkende motor met 'n biblioteek van beskadigde motorfoto's). Die ingenieur verduidelik dat die stelsel die verskillende paragrawe vergelyk met 'n databasis van standaard aanspreeklikheidsklousules uit vorige vaste sake. Dit bereken 'n teksooreenkomstelling om op 'n passing te besluit gebaseer op waarskynlikhede.
Skryf duidelike verduidelikings: Skep boodskappe vir die gebruiker wat duidelik die spesifieke interne aksie beskryf wat plaasvind wanneer die KI 'n keuse maak. Die inhoudontwerper skryf 'n spesifieke boodskap vir hierdie presiese oomblik. Die teks lees: Vergelyk dokumentteks met standaard vaste klousules om potensiële aanspreeklikheidsrisiko's te identifiseer.
Dateer die skerm op: Plaas hierdie nuwe, duidelike verduidelikings in die gebruikerskoppelvlak, en vervang vae boodskappe soos "Hersien kontrakte." Die ontwerpspan verwyder die generiese Processing PDF-laaidraaier. Hulle voeg die nuwe verduideliking in 'n statusbalk reg bokant die dokumentkyker in terwyl die KI dink.
Kontroleer vir vertroue: Maak seker dat die nuwe skermboodskappe gebruikers 'n eenvoudige rede gee vir enige wagtyd of resultaat, wat hulle meer selfversekerd en vertrouend behoort te laat voel.
Die impak/risikomatriks Sodra jy noukeurig na die KI se proses kyk, sal jy waarskynlik baie punte vind waar dit 'n keuse maak. 'n KI kan dosyne klein keuses maak vir 'n enkele komplekse taak. Om hulle almal te wys, skep te veel onnodige inligting. Jy moet hierdie keuses groepeer. Jy kan 'n impak-/risikomatriks gebruik om hierdie keuses te sorteer op grond van die tipe aksie(s) wat die KI neem. Hier is voorbeelde van impak/risiko-matrikse: Kyk eers na besluite met 'n lae inset en 'n lae impak. Lae insette / Lae impak
Voorbeeld: Organiseer 'n lêerstruktuur of hernoem 'n dokument. Deursigtigheidsbehoefte: Minimaal. 'n Subtiele roosterbroodkennisgewing of 'n loginskrywing is voldoende. Gebruikers kan hierdie aksies maklik ongedaan maak.
Identifiseer dan die hoë-insette en hoë-impak besluite. Hoë insette / Hoë impak
Voorbeeld: Verwerping van 'n leningsaansoek of uitvoer van 'n aandelehandel. Deursigtigheidsbehoefte: hoog. Hierdie aksies vereis Bewys van Werk. Die stelsel moet die rasionaal demonstreer voor of onmiddellik soos dit optree.
Oorweeg 'n finansiële handel bot wat alle koop / verkoop bestellings dieselfde behandel. Dit voer 'n $5-handel uit met dieselfde ondeursigtigheid as 'n $50,000-handel. Gebruikers kan bevraagteken of die instrument die potensiële impak van deursigtigheid op handel op 'n groot dollarbedrag erken. Hulle het die stelsel nodig om te breek en sy werk vir die hoë-insette ambagte te wys. Die oplossing is om 'n hersieninglogika-toestand in te stel vir enige transaksie wat 'n spesifieke dollarbedrag oorskry, sodat die gebruiker die faktore kan sien wat die besluit dryf voordat dit uitgevoer word. Kartering van nodusse na patrone: 'n Ontwerppatroonkeuserubriek Sodra jy jou ervaring se sleutelbesluitnodes geïdentifiseer het, moet jy besluit watter UI-patroon van toepassing is op elkeen wat jy sal vertoon. In Designing For Agentic AI het ons patrone soos die Intent Preview (vir hoë-belang beheer) en die Action Audit (vir terugwerkende veiligheid) bekendgestel. Die deurslaggewende faktor in die keuse tussen hulle is omkeerbaarheid. Ons filter elkebesluitnodus deur die impakmatriks om die korrekte patroon toe te ken: Hoë insette en onomkeerbaar: Hierdie nodusse vereis 'n voornemevoorskou. Omdat die gebruiker nie maklik die aksie kan ongedaan maak nie (bv. permanente verwydering van 'n databasis), moet die deursigtigheidsmoment gebeur voor uitvoering. Die stelsel moet onderbreek, die bedoeling daarvan verduidelik en bevestiging vereis. Hoë insette en omkeerbaar: Hierdie nodusse kan staatmaak op die Aksie Oudit & Ontdoen patroon. As die KI-aangedrewe verkoopsagent 'n leidraad na 'n ander pyplyn skuif, kan dit dit outonoom doen solank dit die gebruiker in kennis stel en 'n onmiddellike Ontdoen-knoppie bied. Deur nodusse streng op hierdie manier te kategoriseer, vermy ons "waarskuwingsmoegheid." Ons behou die hoë-wrywing Voorneme Voorskou slegs vir die werklik onomkeerbare oomblikke, terwyl ons staatmaak op die Aksie Oudit om spoed te handhaaf vir alles anders.
Omkeerbaar Onomkeerbaar Lae impak Tipe: Auto-ExecuteUI: Passive Toast / LogEx: Hernoem 'n lêer Tik: BevestigUI: Eenvoudige Ontdoen-opsie Bv: Argiveer 'n e-pos Hoë impak Tipe: ReviewUI: Kennisgewing + Review TrailEx: Stuur 'n konsep aan 'n kliënt Tipe: Intent previewUI: Modale / Eksplisiete ToestemmingEx: Vee 'n bediener uit
Tabel 1: Die impak- en omkeerbaarheidsmatriks kan dan gebruik word om jou oomblikke van deursigtigheid na ontwerppatrone te karteer. Kwalitatiewe validering: "Die wag, hoekom?" Toets Jy kan potensiële nodusse op 'n witbord identifiseer, maar jy moet dit met menslike gedrag bekragtig. Jy moet verifieer of jou kaart by die gebruiker se verstandelike model pas. Ek gebruik 'n protokol genaamd die "Wag, hoekom?" Toets. Vra 'n gebruiker om te kyk hoe die agent 'n taak voltooi. Gee hulle opdrag om hardop te praat. Wanneer hulle 'n vraag vra: "Wag, hoekom het dit dit gedoen?" of "Sit dit vas?" of "Het dit my gehoor?" — jy merk 'n tydstempel. Hierdie vrae dui op gebruikersverwarring. Die gebruiker voel hoe hul beheer wegglip. Byvoorbeeld, in 'n studie vir 'n gesondheidsorgskeduleringsassistent, het gebruikers gekyk hoe die agent 'n afspraak maak. Die skerm het vir vier sekondes staties gesit. Deelnemers het konsekwent gevra: "Gaan dit my kalender of die dokter s'n na?"
Daardie vraag het 'n ontbrekende Transparency Moment onthul. Die stelsel moes daardie wag van vier sekondes in twee afsonderlike stappe verdeel: "Gaan jou beskikbaarheid na" gevolg deur "Sinkroniseer met verskafferskedule." Hierdie klein verandering het gebruikers se uitgedrukte vlakke van angs verminder. Deursigtigheid misluk wanneer dit slegs 'n stelselaksie beskryf. Die koppelvlak moet die tegniese proses aan die gebruiker se spesifieke doelwit koppel. 'n Skerm wat "Kontroleer jou beskikbaarheid" vertoon, val plat omdat dit 'n gebrek aan konteks het. Die gebruiker verstaan dat die KI na 'n kalender kyk, maar hulle weet nie hoekom nie. Ons moet die aksie met die uitkoms koppel. Die stelsel moet daardie wag van vier sekondes in twee afsonderlike stappe verdeel. Eerstens wys die koppelvlak "Gaan jou kalender na om oop tye te vind." Dan word dit opgedateer na "Sinkroniseer met die verskaffer se skedule om jou afspraak te verseker." Dit begrond die tegniese proses in die gebruiker se werklike lewe. Oorweeg 'n KI-bestuur van voorraad vir 'n plaaslike kafee. Die stelsel ondervind 'n toevoertekort. 'N koppelvlak wat lees "kontak verkoper" of "hersien opsies" skep angs. Die bestuurder wonder of die stelsel die bestelling kanselleer of 'n duur alternatief koop. 'n Beter benadering is om die beoogde resultaat te verduidelik: "Evalueer alternatiewe verskaffers om jou Vrydag-afleweringskedule te handhaaf." Dit vertel die gebruiker presies wat die KI probeer bereik. Operasionalisering van die Oudit Jy het die Besluitnodusoudit voltooi en jou lys deur die Impak- en Risikomatriks gefiltreer. Jy het nou 'n lys van noodsaaklike oomblikke om deursigtig te wees. Vervolgens moet u dit in die UI skep. Hierdie stap vereis spanwerk oor verskillende departemente. U kan nie self deursigtigheid ontwerp met 'n ontwerpinstrument nie. Jy moet verstaan hoe die stelsel agter die skerms werk. Begin met 'n Logic Review. Ontmoet jou hoofstelselontwerper. Bring jou kaart van besluitknooppunte. U moet bevestig dat die stelsel hierdie toestande werklik kan deel. Ek vind dikwels dat die tegniese stelsel nie die presiese toestand openbaar wat ek wil wys nie. Die ingenieur kan sê dat die stelsel net 'n algemene "werk"-status gee. Jy moet druk vir 'n gedetailleerde opdatering. Jy het die stelsel nodig om 'n spesifieke kennisgewing te stuurwanneer dit oorskakel van lees van teks na reëls nagaan. Sonder daardie tegniese verband is jou ontwerp onmoontlik om te bou. Betrek vervolgens die inhoudontwerpspan. Jy het die tegniese rede vir die KI se optrede, maar jy het 'n duidelike, mensvriendelike verduideliking nodig. Ingenieurs verskaf die onderliggende proses, maar inhoudontwerpers verskaf die manier waarop dit gekommunikeer word. Moenie hierdie boodskappe alleen skryf nie. 'n Ontwikkelaar kan skryf "Executing function 402," wat tegnies korrek is, maar betekenisloos vir die gebruiker. 'n Ontwerper kan dalk "Denk" skryf, wat vriendelik maar te vaag is. ’n Inhoudstrateeg vind die regte middeweg. Hulle skep spesifieke frases, soos "Skandeer vir aanspreeklikheidsrisiko's", wat wys dat die KI werk sonder om die gebruiker te verwar. Laastens, toets die deursigtigheid van jou boodskappe. Moenie wag totdat die finale produk gebou is om te sien of die teks werk nie. Ek doen vergelykingstoetse op eenvoudige prototipes waar die enigste ding wat verander die statusboodskap is. Ek wys byvoorbeeld vir een groep (Groep A) 'n boodskap wat sê "Verifieer identiteit" en vir 'n ander groep (Groep B) 'n boodskap wat sê "Kontroleer regeringsdatabasisse" (dit is opgemaakte voorbeelde, maar jy verstaan die punt). Dan vra ek hulle watter KI veiliger voel. Jy sal dikwels ontdek dat sekere woorde kommer veroorsaak, terwyl ander vertroue bou. Jy moet die bewoording hanteer as iets wat jy moet toets en effektief moet bewys. Hoe dit die ontwerpproses verander Die uitvoering van hierdie oudits het die potensiaal om te versterk hoe 'n span saamwerk. Ons hou op om gepoleerde ontwerplêers af te gee. Ons begin morsige prototipes en gedeelde sigblaaie gebruik. Die kerninstrument word 'n deursigtigheidsmatriks. Ingenieurs en die inhoudontwerpers redigeer hierdie sigblad saam. Hulle karteer die presiese tegniese kodes aan die woorde wat die gebruiker sal lees. Spanne sal wrywing ervaar tydens die logiese hersiening. Stel jou voor dat 'n ontwerper die ingenieur vra hoe die KI besluit om 'n transaksie wat op 'n uitgaweverslag ingedien is, te weier. Die ingenieur kan sê dat die agterkant slegs 'n generiese statuskode gee soos "Fout: Ontbrekende data". Die ontwerper sê dat dit nie aksiebare inligting op die skerm is nie. Die ontwerper onderhandel met die ingenieur om 'n spesifieke tegniese haak te skep. Die ingenieur skryf 'n nuwe reël sodat die stelsel presies rapporteer wat ontbreek, soos 'n ontbrekende kwitansiebeeld. Inhoudontwerpers tree tydens hierdie fase as vertalers op. 'n Ontwikkelaar kan 'n tegnies akkurate string skryf soos "Berekening van vertrouensdrempel vir verskafferpassing." 'n Inhoudontwerper vertaal daardie string in 'n frase wat vertroue bou vir 'n spesifieke uitkoms. Die strateeg herskryf dit as "Vergelyk plaaslike verskafferpryse om jou Vrydag-aflewering te verseker." Die gebruiker verstaan die aksie en die resultaat. Die hele kruisfunksionele span neem deel aan gebruikerstoetssessies. Hulle kyk hoe 'n regte persoon op verskillende statusboodskappe reageer. Om 'n gebruiker paniekbevange te sien omdat die skerm sê "Executing trade" dwing die span om hul benadering te heroorweeg. Die ingenieurs en ontwerpers stem ooreen met beter bewoording. Hulle verander die teks na "Verifieer voldoende fondse" voordat hulle voorraad koop. Om saam te toets waarborg die finale koppelvlak dien beide die stelsellogika en die gebruiker se gemoedsrus. Dit verg wel tyd om hierdie bykomende aktiwiteite in die span se kalender in te sluit. Die eindresultaat moet egter 'n span wees wat meer openlik kommunikeer, en gebruikers wat 'n beter begrip het van wat hul KI-aangedrewe gereedskap namens hulle doen (en hoekom). Hierdie geïntegreerde benadering is 'n hoeksteen van die ontwerp van werklik betroubare KI-ervarings. Vertroue is 'n ontwerpkeuse Ons beskou vertroue dikwels as 'n emosionele neweproduk van 'n goeie gebruikerservaring. Dit is makliker om vertroue as 'n meganiese resultaat van voorspelbare kommunikasie te beskou. Ons bou vertroue deur die regte inligting op die regte tyd te wys. Ons vernietig dit deur die gebruiker te oorweldig of die masjinerie heeltemal weg te steek. Begin met die Besluitnode-oudit, veral vir agentiese KI-gereedskap en -produkte. Vind die oomblikke waar die stelsel 'n oordeel oproep. Kaart daardie oomblikke na die Risikomatriks. As die spel hoog is, maak die boks oop. Wys die werk. In die volgende artikel sal ons kyk hoe om hierdie oomblikke te ontwerp: hoe om die kopie te skryf, die UI te struktureer en die onvermydelike foute te hanteer wanneer die agent dit verkeerd maak. Bylaag: Die Besluitnodusouditkontrolelys Fase 1: Opstelling en kartering ✅ Kry die span bymekaar: Bring die produkeienaars, sake-ontleders, ontwerpers,sleutelbesluitnemers, en die ingenieurs wat die KI gebou het. Wenk: Jy het die ingenieurs nodig om die werklike backend-logika te verduidelik. Moenie hierdie stap alleen probeer nie. ✅ Teken die hele proses: Dokumenteer elke stap wat die KI neem, van die gebruiker se eerste aksie tot die finale resultaat. Wenk: 'n Fisiese witbordsessie werk dikwels die beste om hierdie aanvanklike stappe uit te teken. Fase 2: Opspoor van die verborge logika ✅ Vind waar dinge onduidelik is: Kyk na die proseskaart vir enige plek waar die KI opsies of insette vergelyk wat nie een perfekte pasmaat het nie. ✅ Identifiseer die beste raaistappe: Vir elke onduidelike plek, kyk of die stelsel 'n vertrouetelling gebruik. Vra byvoorbeeld of die stelsel 85 persent seker is. Dit is die punte waar die KI 'n finale keuse maak. ✅ Ondersoek die keuse: Vir elke keusepunt, bepaal die spesifieke interne wiskunde of vergelyking wat gedoen word. 'n Voorbeeld is om 'n deel van 'n kontrak by 'n polis te pas. Nog 'n voorbeeld behels die vergelyking van 'n foto van 'n stukkende motor met 'n biblioteek van beskadigde motorfoto's. Fase 3: Skep die gebruikerservaring ✅ Skryf duidelike verduidelikings: Skep boodskappe vir die gebruiker wat duidelik die spesifieke interne aksie beskryf wat plaasvind wanneer die KI 'n keuse maak. Wenk: Grond jou boodskappe in konkrete werklikheid. As 'n KI 'n vergadering met 'n kliënt by 'n plaaslike kafee bespreek, vertel die gebruiker dat die stelsel die kafeebesprekingstelsel nagaan. ✅ Dateer die skerm op: plaas hierdie nuwe, duidelike verduidelikings in die gebruikerskoppelvlak. Vervang vae boodskappe soos Hersiening van kontrakte met jou spesifieke verduidelikings. ✅ Kyk vir vertroue: Maak seker dat die nuwe skermboodskappe gebruikers 'n eenvoudige rede gee vir enige wagtyd of resultaat. Dit moet hulle selfversekerd en vertrouend laat voel. Wenk: Toets hierdie boodskappe met werklike gebruikers om te verifieer dat hulle die spesifieke uitkoms verstaan wat bereik word.
