The Dukes Studio / Journal
Je AI-interface is pas goed als het even misgaat
Ontwerp niet alleen de perfecte AI-uitkomst. Maak wachten, ontbrekende informatie, fouten en menselijke controle begrijpelijk met concrete UX/UI-patronen.
Een glanzend invoerveld. Een mooie animatie. Een antwoord dat precies klopt. Het ideale AI-scherm is snel ontworpen. De echte kwaliteit zit in wat je ziet wanneer de bron ontbreekt, de taak langer duurt of het voorstel niet klopt. Dan moet een interface overzicht geven, niet alleen indruk maken.
Ontwerp een taak, geen magische chatbox
Stel dat je een fictief klantportaal ontwerpt waarin AI een projectbrief samenvat. De gebruiker wil geen gesprek om het gesprek. Die wil weten wat is afgesproken, wat ontbreekt en wat de volgende stap is. Begin daarom met dat eindresultaat. Toon bijvoorbeeld de samenvatting, open vragen en gebruikte documenten als herkenbare onderdelen, in plaats van alles in één lange tekstwolk te stoppen.
De richtlijnen van Microsoft Research behandelen AI-interactie niet alleen bij de eerste kennismaking, maar ook tijdens gebruik, bij fouten en over langere tijd. Een praktische vertaling voor je ontwerp: teken niet één succesvol scherm, maar een complete reeks toestanden. Hieronder staan vier die in een eerste prototype al zichtbaar moeten zijn.
1. Leeg: maak starten concreet
Een leeg scherm met “Vraag maar raak” geeft veel vrijheid en weinig richting. Laat zien welke taak het product ondersteunt, welke invoer helpt en wat er daarna verschijnt. Bijvoorbeeld: “Voeg een goedgekeurde projectbrief toe. Je krijgt een samenvatting en een lijst met ontbrekende afspraken.” Gebruik een fictief voorbeeld, duidelijk als voorbeeld gemarkeerd. Zo hoeft niemand echte klantgegevens te uploaden om het product eerst te begrijpen.
2. Bezig: vertel wat werkelijk gebeurt
Een draaiend icoon zegt alleen dat er beweging is. Meld liever een echte processtap, zoals “Document ontvangen” of “Samenvatting wordt voorbereid”. Toon geen percentage of resterende tijd als je systeem die niet betrouwbaar meet. Bied waar mogelijk annuleren aan en leg uit of eerder ingevoerde informatie behouden blijft.
Denk ook aan mensen die de animatie niet zien. W3C beschrijft hoe statusmeldingen programmatisch herkenbaar moeten zijn, zodat ondersteunende technologie ze kan aankondigen zonder dat de focus erheen hoeft te springen. Laat belangrijke voortgang dus niet uitsluitend afhangen van kleur of beweging. Test daarnaast of de interface rustig blijft wanneer meerdere updates snel volgen.
3. Onzeker: toon het gat, niet een verzonnen antwoord
Heeft de projectbrief geen budget? Toon dan “Budget niet gevonden” in plaats van een plausibel bedrag. Onderscheid informatie uit de bron van een voorstel van AI. In ons voorbeeld kan een open vraag luiden: “Wie keurt extra werkzaamheden goed?” Dat is nuttig. Een zelfbedachte naam invullen omdat het scherm anders incompleet oogt, is dat niet.
Vermijd een los betrouwbaarheidspercentage zonder betekenis voor de gebruiker. Een bronpassage en een controleerbare toelichting bieden vaak meer houvast. Maak het eenvoudig om een onjuiste passage te corrigeren zonder de hele taak opnieuw te starten.
4. Fout: geef een uitweg
“Er ging iets mis” is een melding, geen hulp. Vertel welk onderdeel niet lukte, wat wel bewaard is en wat iemand kan doen. Bijvoorbeeld: “Het tweede document kon niet worden gelezen. De eerste samenvatting is bewaard. Upload het document opnieuw of ga verder zonder deze bron.” Bij invoerfouten vraagt W3C om een tekstuele beschrijving van de fout en herkenning van het betrokken invoeronderdeel. Alleen een rode rand is dus onvoldoende.
Controle moet een echte handeling zijn
Een knop “Goedkeuren” is te vaag als er daarna een klantmail uitgaat. Maak het gevolg zichtbaar: welke tekst, naar wie, met welke bijlage? Scheid “Voorstel bewaren” van “Versturen”. Toon na de actie een bevestigde uitkomst. Bij een onbekende uitkomst hoort controle van de actuele status vóór opnieuw uitvoeren, niet een uitnodiging om onbeperkt te klikken.
- Kan iemand de taak begrijpen zonder uitleg van de maker?
- Zijn broninformatie, AI-voorstel en ontbrekende informatie visueel te onderscheiden?
- Blijft invoer behouden bij een fout?
- Werkt de belangrijkste route met toetsenbord en ondersteunende technologie?
- Is duidelijk wat een bevestigingsknop daadwerkelijk verandert?
Laat een paar mensen het prototype met bewust onvolledige invoer gebruiken. Vraag niet alleen of het mooi is, maar wat ze denken dat er zojuist gebeurde. Als hun antwoord overeenkomt met de werkelijke systeemstatus, begint je ontwerp vertrouwen te verdienen.
Beeld: AI-gegenereerde clay-illustratie, geen productscreenshot of bewijs van klantresultaten.