Design Principles
Bij het ontwerpen van AI-systemen gelden specifieke ontwerpprincipes. Je moet nadenken over hoeveel autonomie het systeem krijgt, wat er gebeurt als alles goed gaat én als het misgaat, en hoe je verwachtingen bij gebruikers managet.
Level of Automation
Level of Automation beschrijft hoeveel controle het systeem heeft versus de mens. Dit spectrum loopt van volledig handmatig tot volledig autonoom.
Het spectrum
| Level |
Beschrijving |
Voorbeeld |
| 1. Geen automatisering |
Mens doet alles, systeem biedt geen hulp |
Handmatig e-mails sorteren |
| 2. Systeem suggereert |
Systeem geeft opties, mens beslist en voert uit |
Autocomplete suggesties |
| 3. Systeem adviseert |
Systeem beveelt één optie aan, mens beslist |
"Dit lijkt op spam, wil je blokkeren?" |
| 4. Systeem voert uit na goedkeuring |
Systeem handelt, maar vraagt eerst toestemming |
"Wil je deze afspraak inplannen?" |
| 5. Systeem voert uit, mens kan ingrijpen |
Systeem handelt automatisch, mens kan annuleren |
Gmail's "Verzenden ongedaan maken" |
| 6. Systeem voert uit, rapporteert achteraf |
Systeem handelt, informeert achteraf |
Spamfilter met rapportage |
| 7. Volledig autonoom |
Systeem handelt zonder menselijke tussenkomst |
Automatische voorraadaanvulling |
Keuze maken
De juiste keuze hangt af van meerdere factoren:
| Factor |
Meer automatisering |
Minder automatisering |
| Risico bij fouten |
Laag risico, makkelijk te corrigeren |
Hoog risico, onomkeerbare gevolgen |
| Frequentie |
Hoge frequentie, repetitieve taken |
Incidentele, unieke situaties |
| Tijdsdruk |
Snelle beslissing nodig |
Tijd voor reflectie beschikbaar |
| Expertise gebruiker |
Niet-experts, drukbezet |
Experts die controle willen |
| Betrouwbaarheid model |
Hoge accuracy, weinig edge cases |
Onzeker model, veel uitzonderingen |
Voorbeelden in de praktijk
| Toepassing |
Level |
Rationale |
| Spamfilter |
6 |
Lage impact per fout, hoog volume |
| Medische diagnose |
3 |
Hoge impact, arts moet beslissen |
| Zelfrijdende auto |
5-7 |
Afhankelijk van situatie (snelweg vs. stad) |
| Kredietaanvraag |
3-4 |
Wettelijke eisen, uitlegbaarheid nodig |
| Muziekaanbevelingen |
7 |
Laag risico, personalisatie gewenst |
!!! tip "Start conservatief"
Begin met een lager automation level en verhoog dit pas als je vertrouwen hebt in de betrouwbaarheid van het systeem én de acceptatie door gebruikers.
Happy Flow
De happy flow (ook wel "happy path") is het ideale scenario waarin alles gaat zoals bedoeld: de gebruiker volgt het verwachte pad, de input is correct, en het systeem werkt perfect.
Waarom de happy flow ontwerpen?
- Het is je primaire gebruikerservaring — de meeste interacties zouden hier moeten vallen
- Het bepaalt de baseline waaraan je andere flows meet
- Het helpt je de kernwaarde van je product te definiëren
Happy flow in kaart brengen
| Stap |
Vraag |
| 1 |
Wat is het doel van de gebruiker? |
| 2 |
Welke stappen doorloopt de gebruiker idealiter? |
| 3 |
Wat is de output/feedback bij elke stap? |
| 4 |
Hoe weet de gebruiker dat het doel bereikt is? |
Voorbeeld: AI-chatbot voor klantenservice
| Happy Flow:
1. Klant opent chat
2. Klant stelt vraag: "Wat is de status van mijn bestelling?"
3. Bot herkent intent correct
4. Bot vraagt om ordernummer
5. Klant geeft ordernummer
6. Bot haalt status op en toont deze
7. Klant is geholpen, sluit chat
|
!!! note "Happy flow is niet genoeg"
De happy flow is je startpunt, maar niet je eindpunt. De meeste ontwerpuitdagingen zitten in wat er gebeurt als de flow afwijkt — zie "Designing for Failure".
Creating Expectation
Expectation management gaat over het sturen van verwachtingen zodat gebruikers begrijpen wat het systeem wel en niet kan.
Waarom verwachtingen managen?
| Probleem |
Gevolg |
| Verwachtingen te hoog |
Teleurstelling, wantrouwen, klachten |
| Verwachtingen te laag |
Onderbenutting, gemiste kansen |
| Onduidelijke verwachtingen |
Verwarring, verkeerd gebruik, frustratie |
Technieken voor expectation management
| Techniek |
Beschrijving |
Voorbeeld |
| Onboarding |
Leg uit wat het systeem doet bij eerste gebruik |
"Ik kan je helpen met vragen over bestellingen en retourneren" |
| Scopebepaling |
Communiceer expliciet de grenzen |
"Ik kan geen medisch advies geven" |
| Confidence indicators |
Toon zekerheid van voorspellingen |
"85% zeker dat dit spam is" |
| Voorbeelden geven |
Laat zien wat goede input is |
"Probeer iets als: 'Waar is mijn pakket?'" |
| Progressieve onthulling |
Toon mogelijkheden geleidelijk |
Suggesties na eerste interactie |
Communiceren van onzekerheid
Bij AI-systemen is het eerlijk communiceren van onzekerheid extra belangrijk:
| Niet doen |
Wel doen |
| "Het antwoord is X" |
"Op basis van de data is X het meest waarschijnlijk" |
| Geen indicatie van zekerheid |
"Betrouwbaarheid: hoog/middel/laag" |
| Altijd een antwoord geven |
"Ik weet dit niet zeker, wil je een medewerker spreken?" |
Voorbeeld: verwachtingen bij een AI-assistent
1
2
3
4
5
6
7
8
9
10
11
12 | Goed:
"Ik ben een AI-assistent getraind op productinformatie.
Ik kan je helpen met:
✓ Productvragen
✓ Bestelstatus
✓ Retourprocedures
Voor complexe klachten verbind ik je door met een medewerker."
Slecht:
"Hoi! Vraag me alles!"
→ Leidt tot frustratie als het systeem iets niet kan
|
Designing for Failure
Designing for failure betekent dat je anticipeert op wat er mis kan gaan en daar een goede ervaring voor ontwerpt. Bij AI-systemen is falen geen uitzondering maar een zekerheid.
Typen falen
| Type |
Beschrijving |
Voorbeeld |
| Model faalt |
Verkeerde voorspelling |
Chatbot begrijpt vraag niet |
| Systeem faalt |
Technische fout |
API timeout, server down |
| Gebruiker faalt |
Verkeerde input |
Typo's, onduidelijke vraag |
| Context faalt |
Situatie past niet bij ontwerp |
Edge case niet voorzien |
Strategieën voor failure handling
| Strategie |
Toepassing |
| Graceful degradation |
Val terug op een simpelere maar werkende oplossing |
| Fallback opties |
Bied alternatief (bijv. menselijke medewerker) |
| Duidelijke foutmeldingen |
Leg uit wat er mis ging en wat de gebruiker kan doen |
| Retry mechanisme |
Laat gebruiker het opnieuw proberen |
| Undo mogelijkheid |
Maak acties ongedaan te maken |
| Feedback loop |
Laat gebruikers fouten rapporteren |
Ontwerpen van foutmeldingen
| Element |
Slecht |
Goed |
| Wat ging er mis |
"Error 500" |
"Ik kon je vraag niet verwerken" |
| Waarom |
- |
"De service is tijdelijk niet beschikbaar" |
| Wat nu |
- |
"Probeer het over een minuut opnieuw, of neem contact op met support" |
Failure flows uitwerken
Voor elke stap in je happy flow, vraag:
- Wat kan hier misgaan?
- Hoe detecteren we dat het misgaat?
- Wat is de fallback?
- Hoe communiceren we dit naar de gebruiker?
Voorbeeld: chatbot failure flow
| Happy flow stap: Bot herkent intent van vraag
Wat kan misgaan?
├── Confidence te laag (<0.6)
│ └── Fallback: "Bedoel je A, B, of iets anders?"
├── Geen match gevonden
│ └── Fallback: "Ik begrijp je vraag niet. Kun je het anders formuleren?"
└── Meerdere intents even waarschijnlijk
└── Fallback: "Gaat je vraag over X of over Y?"
|
!!! tip "Test je failures"
Simuleer actief faalscenario's tijdens het testen. Veel teams testen alleen de happy flow en worden verrast door problemen in productie.
Paper Prototyping
Paper prototyping is een snelle, goedkope manier om ontwerpen te testen voordat je begint met bouwen.
Wat is paper prototyping?
- Low-fidelity prototypes gemaakt van papier, post-its, of schetsen
- Snel te maken (minuten tot uren, niet dagen)
- Makkelijk aan te passen op basis van feedback
- Nodigt uit tot eerlijke kritiek (het ziet er niet "af" uit)
Wanneer gebruiken?
| Fase |
Paper prototyping? |
| Eerste ideëen verkennen |
✅ Ideaal |
| Verschillende flows vergelijken |
✅ Ideaal |
| Usability testen van concepten |
✅ Goed |
| Visueel design testen |
❌ Te low-fidelity |
| Interactiedetails testen |
⚠️ Beperkt |
Hoe maak je een paper prototype?
- Schets de schermen — elk scherm op een apart vel
- Maak interactieve elementen — knoppen, menu's op losse stukjes
- Bereid states voor — wat verandert na een klik?
- Speel de "computer" — wissel schermen handmatig tijdens test
Testen met paper prototypes
| Rol |
Taak |
| Facilitator |
Geeft de gebruiker taken, stelt vragen |
| Computer |
Verwisselt schermen en elementen op basis van gebruikersacties |
| Observer |
Noteert observaties en quotes |
| Gebruiker |
Denkt hardop, wijst naar elementen die ze zouden aanklikken |
Tips
| Tip |
Reden |
| Houd het rommelig |
Perfecte schetsen nodigen minder uit tot kritiek |
| Test vroeg |
Hoe eerder je test, hoe goedkoper aanpassingen zijn |
| Focus op flow |
Visueel design komt later |
| Bereid scenario's voor |
Geef gebruikers concrete taken |
| Itereer snel |
Pas aan en test opnieuw, dezelfde dag |
Paper prototype voor AI-systeem
Bij AI-systemen kun je paper prototypes gebruiken om te testen:
- Hoe gebruikers verwachten met het systeem te interacteren
- Welke informatie ze nodig hebben
- Hoe ze reageren op onzekerheid of fouten
- Of de automation level passend aanvoelt
1
2
3
4
5
6
7
8
9
10
11
12
13 | Voorbeeld: Chatbot paper prototype
[Scherm 1: Welkomstbericht]
"Hoi! Ik ben de AI-assistent. Waarmee kan ik je helpen?"
[Post-its met suggesties]
"Bestelstatus" "Retourneren" "Productinfo"
[Scherm 2a: Succesvolle herkenning]
"Je wilt weten waar je bestelling is. Wat is je ordernummer?"
[Scherm 2b: Onzekere herkenning]
"Ik ben niet zeker of ik je begrijp. Bedoel je...?"
|
!!! note "Van paper naar digitaal"
Paper prototypes zijn een startpunt. Zodra de flow en concepten gevalideerd zijn, kun je overgaan naar digitale wireframes en hogere fidelity prototypes.
