Stapsgewijze gids om een website te plannen, schrijven en ontwerpen die AI-mogelijkheden duidelijk uitlegt aan niet-experts, met voorbeelden, UX-tips en vertrouwenwekkende signalen.
Voordat je een pagina schrijft, bepaal precies wie “niet-experts” zijn voor je site. Een “algemeen publiek” is zelden een echte doelgroep—en AI is gemakkelijk mis te vatten als bezoekers met verschillende verwachtingen binnenkomen.
Kies één primaire groep en (optioneel) één secundaire groep. Bijvoorbeeld:
Geef elke groep een kort profiel: wat ze al weten, waar ze zich zorgen over maken, en welke beslissing ze proberen te nemen. Dit helpt je het juiste detailniveau te kiezen—en de juiste voorbeelden.
Niet-experts scannen meestal eerst op praktische antwoorden. Begin je contentplan met de vragen die terugkomen in salesgesprekken, supporttickets, trainingssessies en reacties:
Als je deze niet helder kunt beantwoorden, zal je site aanvoelen als marketing—hoe gepolijst die er ook uitziet.
Kies een klein aantal uitkomsten die er echt toe doen. Veelvoorkomende doelen zijn:
Je doelen moeten bepalen wat je benadrukt: duidelijkheid, geruststelling, besluitvorming of praktische begeleiding.
Koppel metrics aan doelen zodat je de site in de loop van de tijd kunt verbeteren. Voorbeelden:
Stel een review-cadans in (maandelijks of per kwartaal) en pas content aan op basis van wat mensen nog verkeerd begrijpen.
Mensen begrijpen AI sneller als je het groepeert in een paar "taken" die het kan uitvoeren, in plaats van een lange lijst met tools. Streef naar 3–6 bakken die vertrouwd aanvoelen en het grootste deel van je content dekken.
Kies categorieën die bezoekers herkennen uit hun dagelijkse werk. Veelvoorkomende opties zijn:
Noem elke bak met een eenvoudig zelfstandig naamwoord (“Text”, “Images”) of een duidelijke werkwoord-zin (“Vind antwoorden in documenten”). Vermijd slimme labels die uitleg nodig hebben.
Consistentie vermindert verwarring. Schrijf voor elke capability-bak vier korte onderdelen:
Deze structuur helpt lezers snel te vergelijken en stelt verwachtingen zonder te overweldigen.
Niet-experts hebben meestal geen behoefte aan modelnamen, benchmarks, parameteraantallen of leaderboards. Vervang ze door gebruiksgerichte aanwijzingen:
Als je technische termen moet noemen, maak ze optioneel (een korte noot of tooltip) zodat de hoofdpagina toegankelijk blijft.
Een goede AI-explainer site voelt voorspelbaar: bezoekers weten altijd waar ze zijn, wat ze daarna moeten lezen en hoe diep ze willen gaan. Het doel is niet om alles tegelijk te tonen—maar om mensen te begeleiden van “Ik ben nieuwsgierig” naar “Ik begrijp genoeg om te beslissen.”
Houd je topnavigatie klein en betekenisvol. Een praktisch baseline-sitemap ziet er zo uit:
Deze structuur geeft nieuwe bezoekers gemakkelijke instappunten en ondersteunt terugkerende bezoekers die een specifiek antwoord zoeken.
Als je snel werkt, helpt het om deze structuur als een werkende site te prototypen in plaats van een statisch document. Teams gebruiken bijvoorbeeld Koder.ai (een vibe‑coding platform) om vanuit een chatbrief een React‑based explainer site te genereren en vervolgens te itereren met “planning mode”, snapshots en rollback terwijl content en navigatie zich ontwikkelen.
Veel niet-experts weten niet wat “capabilities” of “models” betekenen. Voeg een zichtbaar “Begin hier” pad toe (vanuit de homepage en hoofdmenu) dat door 3–5 korte stappen leidt, bijvoorbeeld:
Design elke pagina in lagen: een korte overzicht eerst, vervolgens optionele details. Een capability‑pagina kan beginnen met een korte alinea, daarna secties zoals “Typische inputs”, “Typische outputs”, “Beste voor” en “Let op”. Bezoekers die de basis willen, kunnen vroeg stoppen zonder zich verloren te voelen.
In plaats van lange, overweldigende pagina's, verbind gerelateerde concepten. Als iemand leest over “hallucinaties”, moet diegene worden doorverwezen naar de woordenlijstdefinitie en een relevante FAQ‑vraag. Dit verandert je site in een begeleide leerervaring in plaats van een stapel pagina's.
Eenvoudige taal is geen "vervlakking". Het verwijdert onnodige frictie zodat lezers kunnen begrijpen wat een AI-systeem doet, wat het niet doet en wat ze daarna moeten doen.
Streef naar korte zinnen, actieve werkwoorden en één idee per alinea. Dat maakt complexe onderwerpen behapbaar zonder belangrijke details weg te laten.
Als je merkt dat de nauwkeurigheid verloren gaat, voeg dan één extra zin context toe in plaats van over te gaan op jargon. Bijvoorbeeld, in plaats van “het model generaliseert”, zeg: “Het leert patronen uit eerdere voorbeelden en gebruikt die patronen om nieuwe schattingen te maken.”
De meeste AI-jargon heeft een eenvoudigere vertaling. Gebruik de alledaagse versie als standaard en introduceer technische termen alleen als ze echt nodig zijn.
Voorbeelden:
Als je een technisch woord moet gebruiken (omdat gebruikers het elders tegenkomen), definieer het meteen in één zin. Gebruik daarna diezelfde term consequent.
Consistentie vermindert verwarring meer dan extra uitleg. Kies één label voor elk kernconcept en houd je er overal aan.
Bijvoorbeeld: beslis of je “AI-systeem”, “AI-model” of “algoritme” gebruikt. Kies er één als hoofdterm (bijv. “AI-systeem”), en noem de anderen hooguit één keer als alternatieve namen die lezers kunnen tegenkomen.
Houd ook werkwoorden consistent: als je de output een “suggestie” noemt, noem het later niet opeens een “antwoord” tenzij je expliciet de verwachting verandert.
Begin elke pagina met een korte “wat je hier krijgt” samenvatting in 3–5 bullets. Dit helpt niet-experts snel te oriënteren en verkleint het risico op misinterpretatie.
Een goede samenvatting bevat meestal:
Deze aanpak houdt de hoofdtekst leesbaar, terwijl de precisie behouden blijft die mensen nodig hebben om AI veilig en vol vertrouwen te gebruiken.
Mensen begrijpen AI sneller als je het laat zien als een eenvoudig systeem: wat erin gaat, wat er gebeurt, wat eruit komt en wat de persoon daarna moet doen. Een klein diagram voorkomt lange uitleg en vermindert “magische doos”-denken.
Wees expliciet over wat een bezoeker moet aanleveren. Veelvoorkomende inputtypen zijn:
Een handig patroon is: “Als je X geeft, kan het Y doen; als je dat niet geeft, raadt het.”
Noem de output in eenvoudige termen en laat zien hoe het eruitziet:
Noem ook wat de output niet is: geen garantie, geen eindbeslissing en geen perfecte bron van waarheid.
Een eenvoudig diagram kan op één scherm passen:
Input Processing Output
(prompt / files / data) (AI finds patterns + predicts) (draft / label / suggestion)
│ │ │
└─────────────────────────┴───────────────────────────┘
Review
(human checks, edits, verifies)
Houd het “Processing”-vak op hoog niveau. Je hoeft geen interne modeldetails te geven; het doel is duidelijkheid, niet engineering.
Direct naast het diagram, zet een korte “voordat je dit gebruikt” noot:
Dit maakt het diagram tot een praktische workflow die bezoekers direct kunnen volgen.
Voorbeelden maken AI tastbaar. Streef naar 5–10 realistische voorbeelden per capability (één pagina of paneel per capability), geschreven als korte, herkenbare scenario's.
Houd elk voorbeeld consistent zodat lezers kunnen scannen:
Gebruik deze als modellen en maak vergelijkbare sets voor samenvatten, brainstormen, datahulp, klantenserviceconcepten, enzovoort.
Before: “I need this by end of day. If you can’t do it, tell me now.”
After (AI‑assisted): “Could you share an update by 5pm today? If that timing won’t work, let me know and we’ll adjust.”
Wat je moet controleren: past de toon bij je relatie; geen toezeggingen toegevoegd; verwijder gevoelige details.
Before: “Talked about launch. Some risks. Sam mentioned vendors.”
After (AI‑assisted): “Actions: (1) Sam to confirm vendor lead times by Wed. (2) Priya to draft launch checklist by Fri. Risks: vendor delays; unclear approval owner.”
Wat je moet controleren: namen/eigenaren correct; data kloppen; beslissingen die ontbreken door jou invullen, niet door het systeem laten raden.
Before: “Looking for a rockstar who can handle anything under pressure.”
After (AI‑assisted): “Seeking a coordinator who can manage deadlines, communicate clearly, and prioritize tasks across teams.”
Wat je moet controleren: bevooroordeelde taal verwijderd; vereisten realistisch; toegankelijkheid en inclusiviteit.
Before: “Not our fault. You used it wrong.”
After (AI‑assisted): “I’m sorry this was frustrating. Let’s figure out what happened—can you share the steps you took and the error message?”
Wat je moet controleren: lijn met beleid; geen schuldbekentenis; privacy (vraag geen onnodige gegevens).
Before: “Your request is pending due to insufficient documentation.”
After (AI‑assisted): “We can’t finish your request yet because we’re missing a document. Please send: proof of address (dated within 90 days).”
Wat je moet controleren: juistheid van vereisten; duidelijk voor niet-native lezers; geen extra persoonlijke gegevens verzamelen.
Downloadbare prompts kunnen handig zijn, maar publiceer ze alleen als je ze actueel kunt houden. Label ze met een laatst bijgewerkt datum, vermeld met welk model/tool ze getest zijn en geef een eenvoudige manier om te melden wanneer ze niet meer werken.
Mensen hoeven geen wiskundeles om onzekerheid te begrijpen—zeg het gewoon duidelijk en consistent. Een nuttige framing is: een AI-systeem voorspelt waarschijnlijke outputs op basis van patronen in data; het “weet” geen feiten zoals een mens dat doet. Dat ene idee voorkomt veel verwarring, vooral als het systeem zelfverzekerd klinkt.
Wees specifiek over hoe AI kan falen, in alledaagse taal:
Een goede website verbergt deze issues niet in kleine lettertjes. Zet ze bij de feature die ze beïnvloeden (bijv. noem hallucinaties op elke pagina over “samenvatten” of “vragen beantwoorden”).
Gebruik bewoording zoals: “Het systeem kiest de meest waarschijnlijke volgende woorden op basis van patronen die het leerde.” Voeg dan toe wat dat betekent: “Dat betekent dat het zelfverzekerd fout kan zijn.” Als je confidence‑scores of labels als “kan onjuist zijn” toont, leg uit wat gebruikers daarna moeten doen (dubbelchecken, bronnen opvragen, vergelijken met vertrouwde referenties).
Als je AI promoot voor beslissingen, zet dan een duidelijke waarschuwing voor medische, juridische en financiële toepassingen: AI-output is geen professioneel advies, kan kritieke details weglaten en moet door een gekwalificeerde expert worden beoordeeld. Vermijd vage waarschuwingen—noem de risico's (foute diagnose, compliance-problemen, onjuiste fiscale adviezen).
| Best for | Not for |
|---|---|
| Eerste versies van e-mails, samenvattingen en outlines maken | Medische diagnoses of behandelwijzigingen |
| Brainstormen en opties verkennen | Juridische interpretaties, contractgoedkeuring of compliance‑signoff |
| Concepten op beginnersniveau uitleggen | Definitieve financiële beslissingen of investeringsadvies |
| Notities organiseren en checklists genereren | Taken die gegarandeerde juistheid vereisen zonder verificatie |
Mensen hoeven niet elk technisch detail te begrijpen om vertrouwen te hebben. Ze willen duidelijke, concrete antwoorden op “Wat gebeurt er met mijn data?” en “Wat houdt dit veilig?” Maak vertrouwen een eerste‑rangs onderdeel van je site—geen voetnoot.
Maak een pagina die uitlegt wat je verzamelt, wat je niet verzamelt en waarom. Houd het leesbaar en concreet, met voorbeelden van veelvoorkomende inputs.
Neem zaken op zoals:
Niet-experts nemen vaak aan dat AI-output “geverifieerd” is. Wees voorzichtig met bewoording. Beschrijf je beschermingen op hoog niveau—zonder te suggereren dat ze perfecte bescherming bieden.
Voorbeelden van veiligheidsnotities om op te nemen:
Geef gebruikers een korte “Gebruik dit goed” sectie die geschikte scenario's en waarschuwingssignalen uitlegt. Koppel dit aan een duidelijk escalatiepad:
Vertrouwen groeit als mensen kunnen zien wie achter het product zit en hoe het onderhouden wordt. Voeg toe:
Als transparantie consequent en specifiek is, voelen je AI‑uitleggen minder als marketing en meer als bruikbare begeleiding.
Een glossary en FAQ fungeren als "stabilisatoren" voor lezers die de terminologie nog niet kennen. Ze helpen ook experts om op één lijn te blijven in definities, zodat je site niet hetzelfde woord op verschillende manieren laat gebruiken.
Houd entries kort, concreet en geschreven voor iemand zonder informatica-achtergrond. Begin met termen die lezers het vaakst tegenkomen:
Voeg onder elke entry een klein regeltje toe: “Je hoort ook wel…” en noem veelvoorkomende synoniemen om verwarring te voorkomen, bijvoorbeeld:
Op capability-pagina's voeg je subtiele tooltips toe bij glossary‑termen zodra ze voor het eerst voorkomen. Houd ze tot één zin en vermijd jargon in de definitie. Tooltips werken het beste als ze:
Je FAQ moet beantwoorden wat mensen al vragen (of waar ze zich zorgen over maken). Goede vragen om op te nemen:
Als woordenlijst + FAQ makkelijk te vinden en consistent zijn, besteden lezers minder tijd aan het ontcijferen van termen en meer tijd aan begrijpen wat de AI daadwerkelijk kan.
Een site die AI goed uitlegt, moet prettig leesbaar zijn. Bij het leren van onbekende concepten moet het ontwerp de belasting verminderen, niet verhogen.
Begin met typografie en witruimte die begrip ondersteunen:
Breek dichte ideeën op in korte alinea's en gebruik duidelijke koppen om te signaleren waar elk deel over gaat. Als je een term introduceert, overweeg dan een korte calloutbox die het in één zin definieert voordat je verdergaat.
Niet-experts scannen vaak eerst en besluiten dan wat ze lezen.
Gebruik consistente paginapatronen: een duidelijke kop, een één‑alinea “wat je leert”, en gestructureerde secties met beschrijvende subkoppen. Maak navigatie voorspelbaar (topmenu + broodkruimels of een zichtbare “Terug naar overzicht”) en verberg geen belangrijke pagina's achter slimme labels.
Callouts helpen, maar gebruik ze doelgericht—voor “Kernpunt”, “Veelvoorkomende misvatting” of “Probeer dit prompt”, niet om hetzelfde punt te herhalen.
Toegankelijkheidsverbeteringen helpen iedereen, inclusief mensen op mobiel en in lawaaierige omgevingen.
Zorg voor:
AI-uitleggen gebruiken vaak stromen en vergelijkingen—die kunnen stuklopen op kleine schermen.
Gebruik gestapelde kaarten voor stapsgewijze pipelines, accordions voor definities en FAQ's, en zij-aan-zij vergelijkingen die in verticale “Before” dan “After” veranderen. Houd tap‑doelen groot en vermijd interacties die precisie vereisen (zoals kleine hover‑alleen tooltips).
Een goede AI-explainer eindigt niet bij “nu weet je het.” Hij helpt mensen te beslissen wat ze daarna doen—zonder iedereen naar dezelfde actie te duwen.
Bied een kleine set duidelijke calls to action (CTA's), elk afgestemd op een ander doel:
Houd de tekst concreet: wat krijgen ze, hoe lang duurt het en wat moeten ze aanleveren.
Als je een hands‑on pad aanbiedt, overweeg een “Bouw een sample app” CTA voor lezers die leren door te doen. Platforms zoals Koder.ai kunnen een korte chatbrief omzetten in een werkende webervaring (React frontend met een Go/PostgreSQL backend), wat handig is om je IA, demo's en contentflows snel te valideren—en de broncode te exporteren wanneer je klaar bent om te operationaliseren.
Dwing experts niet door beginnerscontent heen—of beginners in technische details. Gebruik lichte “paden”, zoals:
Dit kan zo simpel zijn als twee knoppen bovenaan belangrijke pagina's (“Ik leer” vs “Ik evalueer”).
Als je een formulier gebruikt, zeg wat je nodig hebt (voorbeeldbestanden, branche, doel, beperkingen) en wat er daarna gebeurt. Geef, indien mogelijk:
AI‑informatie veroudert snel. Wijs een eigenaar aan, stel een review‑cadans in (maandelijks of per kwartaal) en voeg eenvoudige versienotities toe (bv. “Laatst gecontroleerd: Maand YYYY” en “Wat is er veranderd”) zodat lezers erop kunnen vertrouwen dat de content actueel blijft.
Als je explainer gekoppeld is aan een interactieve demo of tool, behandel updates zoals softwarereleases: volg wijzigingen, houd een rollback‑optie en documenteer wat er veranderde. (Tooling‑functies zoals snapshots en rollback—beschikbaar in platforms zoals Koder.ai—kunnen risico's verminderen als je snel iteraties maakt.)
Begin met het kiezen van één primaire niet-expertgroep (en eventueel een secundaire). Schrijf voor elke groep een kort profiel:
Dit houdt je uitleg op het juiste niveau en voorkomt vaagheden zoals “algemeen publiek”.
Haal vragen uit echte bronnen: salesgesprekken, supporttickets, onboarding-sessies en opmerkingen. Prioriteer vragen die vertrouwen en beslissingen beïnvloeden, zoals:
Als je deze niet helder kunt beantwoorden, zal de site overkomen als marketing.
Kies 1–3 doelen die gekoppeld zijn aan echte uitkomsten. Veelvoorkomende voorbeelden:
Zorg dat elke hoofdpagina aan ten minste één doel bijdraagt zodat de site gefocust blijft.
Koppel metrics aan je doelen en bekijk ze op regelmatige momenten (maandelijks of per kwartaal). Handige metrics zijn:
Gebruik de resultaten om content aan te passen waar mensen nog vastlopen.
Groepeer features in 3–6 herkenbare “taken” (bijv. Text, Images, Audio, Search & Q&A, Spreadsheets). Dit helpt bezoekers sneller dan een lange lijst met tools.
Gebruik eenvoudige, letterlijke namen voor de groepen en vermijd slimme labels die uitleg nodig hebben.
Gebruik voor elke capability dezelfde mini-template:
Consistentie maakt vergelijken gemakkelijk zonder diep te lezen.
Meestal kun je modelnamen, benchmarks, parameteraantallen en leaderboards overslaan. Vervang ze door gebruiksgerichte richtlijnen zoals:
Moet je toch technische termen noemen, maak ze optioneel (tooltips of korte notities).
Houd de topnavigatie klein en voorspelbaar. Een praktisch basismenu is:
Voeg een opvallend -pad toe dat beginners door een korte reeks leidt: wat het is, waar het goed voor is, waar het faalt, herkenbare voorbeelden en volgende stappen.
Schrijf korte zinnen, gebruik actieve vorm en één idee per alinea. Vervang jargon door alledaagse woorden (en definieer onvermijdelijke termen direct).
Kies ook één consistente term per concept (bijv. altijd “AI-systeem” gebruiken) en houd daar overal aan vast—dat voorkomt verwarring meer dan extra toelichting.
Zet beperkingen naast de functies die ze beïnvloeden (niet weggestopt in kleine lettertjes). Leg onzekerheid eenvoudig uit:
Voeg duidelijke waarschuwingen toe voor medische, juridische en financiële toepassingen en vertel gebruikers wat ze vervolgens moeten doen: reviewen, bewerken, verifiëren en opschalen indien nodig.