Ontwerpen voor autonome agenten brengt een unieke frustratie met zich mee. We geven een complexe taak aan een AI, deze verdwijnt gedurende 30 seconden (of 30 minuten) en komt dan terug met een resultaat. Wij staren naar het scherm. Heeft het gewerkt? Hallucineerde het? Heeft zij de nalevingsdatabase gecontroleerd of die stap overgeslagen? Meestal reageren we op deze angst met een van de twee uitersten. Of we houden het systeem als een Black Box en verbergen alles om de eenvoud te behouden, of we raken in paniek en zorgen voor een datadump, waarbij elke logregel en API-oproep naar de gebruiker wordt gestreamd. Geen van beide benaderingen gaat rechtstreeks in op de nuance die nodig is om gebruikers het ideale niveau van transparantie te bieden. De Black Box zorgt ervoor dat gebruikers zich machteloos voelen. De Data Dump zorgt voor blindheid voor meldingen en vernietigt de efficiëntie die de agent beloofde te bieden. Gebruikers negeren de constante stroom aan informatie totdat er iets kapot gaat, waarna ze de context missen om het probleem op te lossen. We hebben een georganiseerde manier nodig om de balans te vinden. In mijn vorige artikel, “Ontwerpen voor Agentic AI”, hebben we gekeken naar interface-elementen die vertrouwen opbouwen, zoals het vooraf laten zien van de beoogde actie van de AI (Intent Previews) en het geven van controle aan gebruikers over hoeveel de AI zelf doet (Autonomy Dials). Maar weten welke elementen je moet gebruiken, is slechts een deel van de uitdaging. De moeilijkere vraag voor ontwerpers is weten wanneer ze ze moeten gebruiken. Hoe weet u welk specifiek moment in een workflow van 30 seconden een Intent Preview vereist en welk moment kan worden afgehandeld met een eenvoudige loginvoer? Dit artikel biedt een methode om die vraag te beantwoorden. We zullen de Decision Node Audit doornemen. Dit proces brengt ontwerpers en ingenieurs in dezelfde ruimte om de backend-logica aan de gebruikersinterface toe te wijzen. Je leert hoe je de exacte momenten kunt bepalen waarop een gebruiker een update nodig heeft over wat de AI doet. We zullen ook een impact-/risicomatrix bespreken die helpt bij het prioriteren van de beslissingsknooppunten die moeten worden weergegeven en elk bijbehorend ontwerppatroon dat aan die beslissing moet worden gekoppeld. Transparantiemomenten: een voorbeeld van een casestudy Neem Meridian (geen echte naam), een verzekeringsmaatschappij die een AI-agent gebruikt om initiële ongevallenclaims te verwerken. De gebruiker uploadt foto's van voertuigschade en het politierapport. De agent verdwijnt vervolgens een minuut voordat hij terugkeert met een risicobeoordeling en een voorgesteld uitbetalingsbereik. Aanvankelijk toonde de interface van Meridian eenvoudigweg Berekening van claimstatus. Gebruikers raakten gefrustreerd. Ze hadden verschillende gedetailleerde documenten ingediend en waren onzeker of de AI het politierapport, dat verzachtende omstandigheden bevatte, wel had ingezien. De Black Box zorgde voor wantrouwen. Om dit op te lossen heeft het ontwerpteam een Decision Node Audit uitgevoerd. Ze ontdekten dat de AI drie verschillende, op waarschijnlijkheid gebaseerde stappen uitvoerde, met talloze kleinere stappen:
Beeldanalyse De agent vergeleek de schadefoto's met een database met typische auto-ongelukscenario's om de reparatiekosten te schatten. Dit betrof een betrouwbaarheidsscore. Tekstuele beoordelingHet scande het politierapport op trefwoorden die van invloed zijn op de aansprakelijkheid (bijvoorbeeld fouten, weersomstandigheden, nuchterheid). Dit betrof een waarschijnlijkheidsbeoordeling van de juridische status. Policy Cross ReferenceIt koppelde de claimdetails aan de specifieke polisvoorwaarden van de gebruiker, op zoek naar uitzonderingen of dekkingslimieten. Hierbij ging het ook om probabilistische matching.
Het team heeft deze stappen omgezet in transparantiemomenten. De interfacereeks is bijgewerkt naar:
Schadefoto's beoordelen: vergelijking met 500 voertuiginslagprofielen. Herziening van het politierapport: analyse van trefwoorden voor aansprakelijkheid en juridisch precedent. Beleidsdekking verifiëren: Controleren op specifieke uitsluitingen in uw plan.
Het systeem kostte nog steeds evenveel tijd, maar de expliciete communicatie over de interne werking van de agent herstelde het vertrouwen van de gebruiker. Gebruikers begrepen dat de AI de complexe taak uitvoerde waarvoor deze was ontworpen, en ze wisten precies waar ze hun aandacht op moesten richten als de uiteindelijke beoordeling onnauwkeurig leek. Deze ontwerpkeuze transformeerde een moment van angst in een moment van verbinding met de gebruiker. De Impact/Risico-matrix toepassen: wat we kozen om te verbergen De meeste AI-ervaringen hebben geen tekort aan gebeurtenissen en beslissingsknooppunten die mogelijk tijdens de verwerking kunnen worden weergegeven. Een van de meest kritische uitkomsten van de audit was de beslissing wat onzichtbaar moest blijven. In het Meridian-voorbeeld genereerden de backend-logboeken meer dan 50 gebeurtenissen per claim. We hadden standaard elke gebeurtenis kunnen weergeven terwijl deze werd verwerkt als onderdeel van de gebruikersinterface. In plaats daarvan hebben we de risicomatrix toegepast om ze te snoeien:
Logboekgebeurtenis: PingserverWest-2 voor redundantiecontrole. Filteroordeel: Verbergen. (Lage inzet, hoge technische details).
Logboekgebeurtenis: vergelijking van reparatieschatting met BlueBook-waarde. Filteroordeel: tonen. (Hoge inzet, heeft invloed op de uitbetaling van de gebruiker).
Door de onnodige details weg te laten, had de belangrijke informatie – zoals de dekkingsverificatie – meer impact. We creëerden een open interface en ontwierpen een open ervaring. Deze aanpak maakt gebruik van het idee dat mensen zich beter voelen over een dienst als ze kunnen zien hoe het werk wordt gedaan. Door de specifieke stappen te tonen (beoordelen, beoordelen, verifiëren), hebben we de wachttijd van 30 seconden veranderd van een tijd van zorgen (“Is het kapot?”) in een tijd waarin we het gevoel hebben dat er iets waardevols wordt gecreëerd (“Het denkt na”). Laten we nu eens nader bekijken hoe we het besluitvormingsproces in onze producten kunnen beoordelen om belangrijke momenten te identificeren die duidelijke informatie vereisen. De beslissingsknooppuntaudit Transparantie faalt als we het als een stijlkeuze beschouwen in plaats van als een functionele vereiste. We hebben de neiging om te vragen: “Hoe moet de gebruikersinterface eruitzien?” voordat we vragen: “Wat beslist de agent eigenlijk?” De Decision Node Audit is een eenvoudige manier om AI-systemen begrijpelijker te maken. Het werkt door het interne proces van het systeem zorgvuldig in kaart te brengen. Het belangrijkste doel is het vinden en duidelijk definiëren van de exacte momenten waarop het systeem stopt met het volgen van de vastgestelde regels en in plaats daarvan een keuze maakt op basis van toeval of inschatting. Door deze structuur in kaart te brengen, kunnen makers deze punten van onzekerheid rechtstreeks laten zien aan de mensen die het systeem gebruiken. Dit verandert systeemupdates van vage uitspraken in specifieke, betrouwbare rapporten over hoe de AI tot haar conclusie kwam. Naast de bovenstaande verzekeringscasestudie heb ik onlangs met een teambuilding van een inkoper gewerkt. Het systeem beoordeelde leverancierscontracten en signaleerde risico's. Oorspronkelijk vertoonde het scherm een eenvoudige voortgangsbalk: ‘Contracten beoordelen.’ Gebruikers hadden er een hekel aan. Uit ons onderzoek bleek dat ze zich zorgen maakten over de juridische implicaties van een ontbrekende clausule. We hebben dit opgelost door een Decision Node Audit uit te voeren. Aan het einde van dit artikel heb ik een stapsgewijze checklist voor het uitvoeren van deze audit opgenomen. We hielden een sessie met de ingenieurs en schetsten hoe het systeem werkt. We identificeerden ‘beslissingspunten’: momenten waarop de AI moest kiezen tussen twee goede opties. In standaard computerprogramma's is het proces duidelijk: als A gebeurt, zal B altijd gebeuren. Bij AI-systemen is het proces vaak gebaseerd op toeval. De AI denkt dat A waarschijnlijk de beste keuze is, maar het is misschien maar 65% zeker. In het contractsysteem vonden we een moment waarop de AI de aansprakelijkheidsvoorwaarden controleerde aan de hand van onze bedrijfsregels. Het was zelden een perfecte match. De AI moest beslissen of een match van 90% goed genoeg was. Dit was een belangrijk beslissingspunt.
Nadat we dit knooppunt hadden geïdentificeerd, hebben we het aan de gebruiker getoond. In plaats van 'Contracten beoordelen' werd de interface bijgewerkt met de tekst: 'Aansprakelijkheidsclausule verschilt van standaardsjabloon. Risiconiveau wordt geanalyseerd.' Deze specifieke update gaf gebruikers vertrouwen. Ze wisten dat de agent de aansprakelijkheidsclausule controleerde. Ze begrepen de reden voor de vertraging en kregen het vertrouwen dat de gewenste actie aan de achterkant plaatsvond. Ze wisten ook waar ze dieper in moesten duiken zodra de agent het contract had gegenereerd. Om te controleren hoe de AI beslissingen neemt, moet u nauw samenwerken met uw ingenieurs, productmanagers, bedrijfsanalisten en sleutelfiguren die de keuzes maken (vaak verborgen) die van invloed zijn op de manier waarop de AI-tool functioneert. Teken de stappen die de tool doorloopt. Markeer elke plek waar het proces van richting verandert omdat er aan een waarschijnlijkheid wordt voldaan. Dit zijn de plaatsen waar u zich moet concentreren op meer transparantie. Zoals weergegeven in figuur 2 hieronder, omvat de Decision Node Audit de volgende stappen:
Breng het team samen: breng de producteigenaren, bedrijfsanalisten, ontwerpers, belangrijke besluitvormers en de ingenieurs die de AI hebben gebouwd erbij. Bijvoorbeeld Denk aan een productteam dat een AI-tool bouwt die is ontworpen om rommelige juridische contracten te beoordelen. Het team bestaat uit de UX-ontwerper, de productmanager, de UX-onderzoeker, een praktiserend jurist die optreedt als materiedeskundige en de backend-ingenieur die de tekstanalysecode heeft geschreven.
Teken het hele proces: documenteer elke stap die de AI zet, van de eerste actie van de gebruiker tot het eindresultaat. Het team staat bij een whiteboard en schetst de hele reeks voor een belangrijke workflow waarbij de AI op zoek gaat naar een aansprakelijkheidsclausule in een complex contract. De advocaat uploadteen pdf van vijftig pagina's → Het systeem converteert het document naar leesbare tekst. → De AI scant de pagina's op aansprakelijkheidsclausules. → De gebruiker wacht. → Even of minuten later markeert de tool de gevonden paragrafen in geel op de gebruikersinterface. Ze doen dit ook voor veel andere workflows die de tool mogelijk maakt.
Ontdek waar dingen onduidelijk zijn: kijk naar de proceskaart voor elke plek waar de AI opties of invoer vergelijkt die niet één perfecte match hebben. Het team kijkt naar het whiteboard om de dubbelzinnige stappen te ontdekken. Het converteren van een afbeelding naar tekst volgt strikte regels. Het vinden van een specifieke aansprakelijkheidsclausule brengt giswerk met zich mee. Elk bedrijf schrijft deze clausules anders, dus de AI moet meerdere opties afwegen en een voorspelling doen in plaats van een exacte woordovereenkomst te vinden.
Identificeer de ‘beste gok’-stappen: Controleer voor elke onduidelijke plek of het systeem een betrouwbaarheidsscore gebruikt (is het bijvoorbeeld 85% zeker?). Dit zijn de punten waarop de AI een definitieve keuze maakt. Het systeem moet raden (een waarschijnlijkheid geven) welke paragraaf(en) sterk lijkt op een standaard aansprakelijkheidsclausule. Het kent een betrouwbaarheidsscore toe aan de beste schatting. Die gok is een beslissingsknooppunt. De interface moet de advocaat vertellen dat hij een potentiële match benadrukt, in plaats van te melden dat hij de definitieve clausule heeft gevonden.
Onderzoek de keuze: zoek voor elk keuzepunt uit welke specifieke interne berekeningen of vergelijkingen worden uitgevoerd (bijvoorbeeld het matchen van een deel van een contract met een polis of het vergelijken van een foto van een kapotte auto met een bibliotheek met foto's van beschadigde auto's). De ingenieur legt uit dat het systeem de verschillende paragrafen vergelijkt met een database met standaardaansprakelijkheidsclausules uit eerdere zaken. Het berekent een tekstgelijkenisscore om op basis van kansen een overeenkomst te bepalen.
Schrijf duidelijke uitleg: Creëer berichten voor de gebruiker die duidelijk de specifieke interne actie beschrijven die plaatsvindt wanneer de AI een keuze maakt. De contentontwerper schrijft een specifieke boodschap voor dit exacte moment. De tekst luidt: Documenttekst vergelijken met standaard vaste clausules om potentiële aansprakelijkheidsrisico's te identificeren.
Update het scherm: plaats deze nieuwe, duidelijke uitleg in de gebruikersinterface en vervang vage berichten als ‘Contracten beoordelen’. Het ontwerpteam verwijdert de generieke Processing PDF-laadspinner. Ze voegen de nieuwe uitleg in een statusbalk direct boven de documentviewer in, terwijl de AI nadenkt.
Controleer op vertrouwen: zorg ervoor dat de nieuwe schermberichten gebruikers een eenvoudige reden geven voor eventuele wachttijden of resultaten, waardoor ze zich zelfverzekerder en zelfverzekerder zouden moeten voelen.
De Impact/Risico-matrix Als je goed naar het proces van de AI kijkt, zul je waarschijnlijk veel punten tegenkomen waarop AI een keuze maakt. Een AI kan tientallen kleine keuzes maken voor één enkele complexe taak. Als u ze allemaal laat zien, ontstaat er te veel onnodige informatie. U moet deze keuzes groeperen. U kunt een Impact/Risico-matrix gebruiken om deze keuzes te sorteren op basis van de soorten actie(s) die de AI onderneemt. Hier zijn voorbeelden van impact/risico-matrices: Zoek eerst naar beslissingen met een lage inzet en weinig impact. Lage inzet / lage impact
Voorbeeld: het organiseren van een bestandsstructuur of het hernoemen van een document. Transparantiebehoefte: minimaal. Een subtiele toastmelding of een loginvoer is voldoende. Gebruikers kunnen deze acties eenvoudig ongedaan maken.
Identificeer vervolgens de beslissingen met een hoge inzet en een grote impact. Hoge inzet / hoge impact
Voorbeeld: een leningaanvraag afwijzen of een aandelenhandel uitvoeren. Transparantiebehoefte: hoog. Voor deze acties is Proof of Work vereist. Het systeem moet de grondgedachte aantonen vóór of onmiddellijk terwijl het handelt.
Overweeg een financiële handelsbot die alle koop- en verkooporders op dezelfde manier behandelt. Het voert een transactie van €5 uit met dezelfde transparantie als een transactie van €50.000. Gebruikers kunnen zich afvragen of de tool de potentiële impact van transparantie op de handel in grote dollars onderkent. Ze hebben het systeem nodig om te pauzeren en zijn werk te laten zien voor transacties met hoge inzetten. De oplossing is om een Reviewing Logic-status te introduceren voor elke transactie die een bepaald bedrag in dollars overschrijdt, zodat de gebruiker de factoren kan zien die de beslissing bepalen voordat deze wordt uitgevoerd. Knooppunten aan patronen toewijzen: een selectierubriek voor ontwerppatronen Zodra u de belangrijkste beslissingsknooppunten van uw ervaring heeft geïdentificeerd, moet u beslissen welk UI-patroon van toepassing is op elk knooppunt dat u weergeeft. Bij Designing For Agentic AI hebben we patronen geïntroduceerd zoals de Intent Preview (voor controle waarbij veel op het spel staat) en de Action Audit (voor veiligheid achteraf). De beslissende factor bij de keuze tussen beide is de omkeerbaarheid. Wij filteren elkebeslissingsknooppunt door de impactmatrix om het juiste patroon toe te wijzen: Hoge inzet en onomkeerbaar: deze knooppunten vereisen een intentievoorbeeld. Omdat de gebruiker de actie niet gemakkelijk ongedaan kan maken (bijvoorbeeld het definitief verwijderen van een database), moet het transparantiemoment vóór de uitvoering plaatsvinden. Het systeem moet pauzeren, zijn bedoeling uitleggen en bevestiging vereisen. Hoge inzet en omkeerbaar: deze knooppunten kunnen vertrouwen op het Action Audit & Undo-patroon. Als de door AI aangedreven verkoopagent een lead naar een andere pijplijn verplaatst, kan hij dit autonoom doen, zolang hij de gebruiker hiervan op de hoogte stelt en een onmiddellijke knop Ongedaan maken aanbiedt. Door knooppunten strikt op deze manier te categoriseren, vermijden we ‘alertvermoeidheid’. We reserveren de frictieve Intent Preview alleen voor de echt onomkeerbare momenten, terwijl we vertrouwen op de Action Audit om de snelheid voor al het andere te behouden.
Omkeerbaar Onomkeerbaar Lage impact Type: Auto-ExecuteUI: Passieve Toast / LogEx: De naam van een bestand wijzigen Type: BevestigUI: Eenvoudige optie Ongedaan makenBijv.: Een e-mail archiveren Hoge impact Type: ReviewUI: Notificatie + Review TrailEx: Een concept naar een klant sturen Type: Intent previewUI: Modale / Expliciete toestemmingEx: Een server verwijderen
Tabel 1: De impact- en omkeerbaarheidsmatrix kan vervolgens worden gebruikt om uw momenten van transparantie in kaart te brengen in ontwerppatronen. Kwalitatieve validatie: “Het wachten, waarom?” Testen U kunt potentiële knooppunten op een whiteboard identificeren, maar u moet ze valideren met menselijk gedrag. U moet verifiëren of uw kaart overeenkomt met het mentale model van de gebruiker. Ik gebruik een protocol genaamd "Wacht, waarom?" Test. Vraag een gebruiker om te kijken hoe de agent een taak voltooit. Instrueer hen om hardop te spreken. Elke keer dat ze een vraag stellen: "Wacht, waarom deed het dat?" of “Staat het vast?” of "Heeft het mij gehoord?" — u markeert een tijdstempel. Deze vragen duiden op verwarring bij de gebruiker. De gebruiker voelt de controle wegglippen. In een onderzoek voor een zorgplanningsassistent zagen gebruikers bijvoorbeeld hoe de agent een afspraak boekte. Het scherm bleef vier seconden statisch. Deelnemers vroegen consequent: “Is het mijn agenda of die van de dokter?”
Die vraag bracht een ontbrekend Transparantiemoment aan het licht. Het systeem moest die wachttijd van vier seconden opsplitsen in twee afzonderlijke stappen: 'Uw beschikbaarheid controleren', gevolgd door 'Synchroniseren met het schema van de provider'. Deze kleine verandering verminderde de angstgevoelens van gebruikers. Transparantie faalt als het alleen een systeemactie beschrijft. De interface moet het technische proces verbinden met het specifieke doel van de gebruiker. Een scherm met de tekst ‘Controleer uw beschikbaarheid’ valt plat omdat het context mist. De gebruiker begrijpt dat de AI naar een kalender kijkt, maar weet niet waarom. We moeten de actie koppelen aan de uitkomst. Het systeem moet die wachttijd van vier seconden opsplitsen in twee afzonderlijke stappen. Eerst toont de interface 'Controleer uw agenda om open tijden te vinden'. Vervolgens wordt het bijgewerkt naar 'Synchroniseren met het schema van de provider om uw afspraak veilig te stellen.' Hierdoor wordt het technische proces gebaseerd op het werkelijke leven van de gebruiker. Overweeg een AI die de inventaris beheert voor een plaatselijk café. Het systeem stuit op een aanbodtekort. Een interface met de tekst 'contact opnemen met de leverancier' of 'opties bekijken' schept angst. De manager vraagt zich af of het systeem de bestelling annuleert of een duur alternatief koopt. Een betere aanpak is om het beoogde resultaat uit te leggen: “Evalueer alternatieve leveranciers om je bezorgschema op vrijdag te behouden.” Dit vertelt de gebruiker precies wat de AI probeert te bereiken. Operationaliseren van de audit U heeft de Decision Node Audit voltooid en uw lijst gefilterd via de Impact- en Risicomatrix. Je hebt nu een lijst met essentiële momenten om transparant te zijn. Vervolgens moet u ze in de gebruikersinterface maken. Deze stap vereist teamwerk tussen verschillende afdelingen. Transparantie kun je niet zelf ontwerpen met een ontwerptool. U moet begrijpen hoe het systeem achter de schermen werkt. Begin met een logische beoordeling. Ontmoet uw hoofdsysteemontwerper. Neem uw kaart met beslissingsknooppunten mee. U moet bevestigen dat het systeem deze statussen daadwerkelijk kan delen. Ik merk vaak dat het technische systeem niet precies de staat onthult die ik wil laten zien. De ingenieur zou kunnen zeggen dat het systeem gewoon een algemene ‘werkende’ status retourneert. U moet aandringen op een gedetailleerde update. U hebt het systeem nodig om een specifieke melding te verzendenwanneer het overschakelt van het lezen van tekst naar het controleren van regels. Zonder die technische connectie is jouw ontwerp onmogelijk te bouwen. Betrek vervolgens het Content Design-team. Je hebt de technische reden voor de actie van de AI, maar je hebt een duidelijke, mensvriendelijke uitleg nodig. Ingenieurs zorgen voor het onderliggende proces, maar contentontwerpers zorgen voor de manier waarop dit wordt gecommuniceerd. Schrijf deze berichten niet alleen. Een ontwikkelaar zou 'Executing function 402' kunnen schrijven, wat technisch correct is, maar betekenisloos voor de gebruiker. Een ontwerper zou 'Denken' kunnen schrijven, wat vriendelijk maar te vaag is. Een contentstrateeg vindt de juiste middenweg. Ze creëren specifieke zinnen, zoals ‘Scannen op aansprakelijkheidsrisico’s’, die laten zien dat de AI werkt zonder de gebruiker in verwarring te brengen. Test ten slotte de transparantie van uw berichten. Wacht niet tot het eindproduct is gebouwd om te zien of de tekst werkt. Ik voer vergelijkingstests uit op eenvoudige prototypes waarbij het enige dat verandert de statusmelding is. Ik laat bijvoorbeeld aan de ene groep (Groep A) een bericht zien met de tekst ‘Identiteit verifiëren’ en aan een andere groep (Groep B) een bericht met de tekst ‘Overheidsdatabases controleren’ (dit zijn verzonnen voorbeelden, maar u begrijpt het punt). Dan vraag ik hen welke AI veiliger voelt. Je zult vaak ontdekken dat bepaalde woorden zorgen veroorzaken, terwijl andere vertrouwen opbouwen. U moet de formulering beschouwen als iets dat u moet testen en effectief moet bewijzen. Hoe dit het ontwerpproces verandert Het uitvoeren van deze audits heeft het potentieel om de manier waarop een team samenwerkt te versterken. We stoppen met het uitdelen van gepolijste ontwerpbestanden. We beginnen rommelige prototypes en gedeelde spreadsheets te gebruiken. Het kerninstrument wordt een transparantiematrix. Ingenieurs en de inhoudontwerpers bewerken deze spreadsheet samen. Ze koppelen de exacte technische codes aan de woorden die de gebruiker zal lezen. Teams zullen wrijving ervaren tijdens de logicabeoordeling. Stel je voor dat een ontwerper aan de ingenieur vraagt hoe de AI besluit een transactie af te wijzen die op een onkostendeclaratie is ingediend. De ingenieur zou kunnen zeggen dat de backend alleen een generieke statuscode uitvoert, zoals "Fout: ontbrekende gegevens". De ontwerper stelt dat dit geen bruikbare informatie op het scherm is. De ontwerper onderhandelt met de ingenieur om een specifiek technisch haakje te creëren. De engineer schrijft een nieuwe regel zodat het systeem precies meldt wat er ontbreekt, zoals een ontbrekende bonafbeelding. Contentontwerpers fungeren in deze fase als vertalers. Een ontwikkelaar kan een technisch nauwkeurige tekenreeks schrijven, zoals 'Berekening van de betrouwbaarheidsdrempel voor leveranciersmatching'. Een contentontwerper vertaalt die string in een zin die vertrouwen schept voor een specifiek resultaat. De strateeg herschrijft het als “Het vergelijken van de prijzen van lokale leveranciers om uw bezorging op vrijdag veilig te stellen.” De gebruiker begrijpt de actie en het resultaat. Het hele cross-functionele team neemt deel aan gebruikerstestsessies. Ze zien hoe een echt persoon reageert op verschillende statusberichten. Het zien van een gebruiker die in paniek raakt omdat op het scherm 'Handel uitvoeren' staat, dwingt het team om hun aanpak te heroverwegen. De ingenieurs en ontwerpers komen op één lijn met een betere formulering. Ze veranderen de tekst in 'Voldoende saldo verifiëren' voordat ze aandelen kopen. Samen testen garandeert dat de uiteindelijke interface zowel de systeemlogica als de gemoedsrust van de gebruiker dient. Het vergt wel tijd om deze extra activiteiten in de teamkalender op te nemen. Het eindresultaat zou echter een team moeten zijn dat opener communiceert, en gebruikers die een beter begrip hebben van wat hun AI-aangedreven tools namens hen doen (en waarom). Deze geïntegreerde aanpak is een hoeksteen van het ontwerpen van werkelijk betrouwbare AI-ervaringen. Vertrouwen is een ontwerpkeuze We zien vertrouwen vaak als een emotioneel bijproduct van een goede gebruikerservaring. Het is gemakkelijker om vertrouwen te zien als een mechanisch resultaat van voorspelbare communicatie. Wij bouwen vertrouwen op door de juiste informatie op het juiste moment te tonen. We vernietigen het door de gebruiker te overweldigen of door de machine volledig te verbergen. Begin met de Decision Node Audit, vooral voor agentische AI-tools en -producten. Vind de momenten waarop het systeem een oordeel velt. Breng die momenten in kaart in de Risicomatrix. Als de inzet hoog is, open dan de doos. Laat het werk zien. In het volgende artikel zullen we bekijken hoe we deze momenten kunnen ontwerpen: hoe we de kopie moeten schrijven, hoe we de gebruikersinterface moeten structureren en hoe we moeten omgaan met de onvermijdelijke fouten als de agent het bij het verkeerde eind heeft. Bijlage: De beslissingsknooppunt-auditchecklist Fase 1: Opstelling en mapping ✅ Breng het team samen: breng de producteigenaren, bedrijfsanalisten, ontwerpers,belangrijke besluitvormers en de ingenieurs die de AI hebben gebouwd. Tip: je hebt de technici nodig om de feitelijke backend-logica uit te leggen. Probeer deze stap niet alleen. ✅ Teken het hele proces: documenteer elke stap die de AI zet, van de eerste actie van de gebruiker tot het eindresultaat. Tip: een fysieke whiteboardsessie werkt vaak het beste om deze eerste stappen uit te tekenen. Fase 2: Het lokaliseren van de verborgen logica ✅ Vind waar dingen onduidelijk zijn: kijk naar de proceskaart voor elke plek waar de AI opties of invoer vergelijkt die niet één perfecte match hebben. ✅ Identificeer de beste gokstappen: controleer voor elke onduidelijke plek of het systeem een betrouwbaarheidsscore gebruikt. Vraag bijvoorbeeld of het systeem 85 procent zeker is. Dit zijn de punten waarop de AI een definitieve keuze maakt. ✅ Onderzoek de keuze: zoek voor elk keuzepunt uit welke specifieke interne wiskunde of vergelijking wordt uitgevoerd. Een voorbeeld is het matchen van een deel van een contract met een polis. Een ander voorbeeld is het vergelijken van een foto van een kapotte auto met een bibliotheek met foto's van beschadigde auto's. Fase 3: Het creëren van de gebruikerservaring ✅ Schrijf duidelijke uitleg: maak berichten voor de gebruiker die duidelijk de specifieke interne actie beschrijven die plaatsvindt wanneer de AI een keuze maakt. Tip: Grond uw berichten in de concrete realiteit. Als een AI een afspraak boekt met een klant in een plaatselijk café, vertel de gebruiker dan dat het systeem het caféreserveringssysteem controleert. ✅ Update het scherm: plaats deze nieuwe, duidelijke uitleg in de gebruikersinterface. Vervang vage berichten zoals het beoordelen van contracten door uw specifieke uitleg. ✅ Controleer op vertrouwen: zorg ervoor dat de nieuwe schermberichten gebruikers een eenvoudige reden geven voor eventuele wachttijden of resultaten. Dit moet ervoor zorgen dat ze zich zelfverzekerd en vertrouwend voelen. Tip: Test deze berichten met echte gebruikers om er zeker van te zijn dat ze het specifieke resultaat begrijpen dat wordt bereikt.
