Prototypes als requirementstaal

Het probleem

Nieuwe functionaliteit staat in een ticket en, met wat geluk, in een visueel ontwerp - maar hoe het scherm zich gedráágt zodra iemand het gebruikt, staat nergens vast. Er is vaak niemand die naast het grafisch ontwerp ook het interactieontwerp maakt: wat gebeurt er bij een gedeeltelijke selectie, bij het wisselen van pagina, bij alleen het toetsenbord. Die beslissingen vallen dan alsnog tijdens de implementatie - ad hoc, zonder dat iemand ze vooraf heeft beoordeeld.

Waarom de voor de hand liggende oplossingen niet werkten

Er lag doorgaans een visuele richting: een ontwerp, of op zijn minst een bestaand scherm om op voort te bouwen. Zo'n ontwerp beschrijft hoe iets eruitziet op het moment dat er niets gebeurt; het beschrijft geen gedrag over tijd. Een tabel met een nieuwe selectiekolom oogt in een screenshot compleet, maar een screenshot laat niet zien wat er gebeurt als je van pagina wisselt terwijl er iets geselecteerd staat, of wat een schermlezer hoort bij het openen van een paneel. Tekstuele requirements ("voeg bulkselectie toe aan deze tabel") laten precies dat gedrag open, en het gevolg is voorspelbaar: de vraag "is dit wat we bedoelen" komt pas boven tijdens het bouwen - het duurste moment om hem te stellen. Dat is ook waarom "gewoon beter opschrijven" het niet oplost: gedrag dat zich over tijd afspeelt, laat zich niet goed vangen in proza, hoe gedetailleerd de tekst ook wordt.

De aanpak

Input: bestaande scherm- en tabelpatronen uit de applicatie (kolomopbouw, statuslabels, actieknoppen) als visuele basis, aangevuld met wat er aan ontwerp beschikbaar was.
Output: losse, op zichzelf staande HTML-schermen buiten de eigenlijke codebase - Alpine.js vanaf een CDN voor de interactiviteit, geen build-stap, geen backend, geen integratie met de echte applicatie, en gemockte data uit een los JSON-bestand.
Wat je vooraf vastlegde: welke elementen (koppen, acties, statuslabels) consistent moesten blijven met de rest van de applicatie, en welke voorbeelddata rijk genoeg was om echte interactievragen op te roepen - meerdere statussen, meerdere pagina's, een deels-geselecteerde toestand.
Prompt-aanpak: niet één losse prompt, maar een opzet in stappen - eerst de bestaande, alleen-lezen situatie nabouwen als nulmeting, dan de gevraagde functie erbovenop met snelle UX-polish, dan een formele toegankelijkheidsreview tegen WCAG 2.2 AA en de WAI-ARIA APG, dan een tweede versie die de bevindingen verwerkt.
Tooling: Claude Code en vergelijkbare AI-agents, voor zowel het genereren van de schermen als het uitvoeren van de gestructureerde review; periode rond september 2026.
Vaste eisen aan elk prototype, ook al is het wegwerpmateriaal: volledig met het toetsenbord te bedienen, zichtbare focusindicatie ook waar het ontwerp die niet expliciet noemt, semantische HTML als basis, en toestanden (geselecteerd, uitgeschakeld, actief) die ook als zodanig herkenbaar zijn - niet alleen visueel. Deze lijst is geen bijzaak, zie de volgende sectie.

De laag die geen ontwerp kan bevatten

Eerste argument - het medium. Een ontwerp toont een interface in ruste: hoe ziet het eruit als er niets gebeurt. Focusvolgorde, zichtbare focusindicatie, wat er wordt aangekondigd bij het openen van een paneel, hoe de ene toestand overgaat in de volgende - dat bestaat alleen over tijd. Ontwerpers vergeten dat niet; het medium kan het gewoon niet dragen. Het gevolg is dat die beslissingen standaard tijdens de implementatie vallen: door één ontwikkelaar, onder tijdsdruk, zonder dat iemand ze vooraf heeft gezien of beoordeeld.

Een interactief prototype is de enige plek waar gedrag, toestand en toegankelijkheid gezamenlijk beoordeeld kunnen worden - vóórdat er iets in productiecode vastligt.

Tweede argument - snelheid maakt herhaling betaalbaar. Omdat een AI-agent een compleet, functioneel scherm in de tijd van een korte sessie kan opbouwen, is het geen probleem om het twee keer te doen: eerst de functie zelf, dan - na een formele review - een tweede versie die de bevindingen verwerkt. Dat is een ander soort goedkoop dan "mag slordig zijn": deze schermen waren van meet af aan volwaardig genoeg om functioneel te beoordelen, alleen stond er nog niets aan productiecode, databasekoppelingen of tests aan vast. Niets van wat je weggooit kost dus meer dan de tijd om het te genereren.

Concreet voorbeeld, neem dit letterlijk. In de eerste versie van zo'n scherm opent een voorbeeldpaneel met een achtergrond die de pagina blokkeert en dat met Escape weer sluit - het gedráágt zich als een modal. Maar de focus verplaatst zich niet automatisch naar het paneel, en niets houdt hem daar vast: met Tab beweeg je gewoon door naar de pagina erachter, terwijl die pagina visueel wél is afgeschermd. Voor een muisgebruiker is dat onzichtbaar. Voor iemand die alleen het toetsenbord gebruikt, is het paneel een doodlopende weg. Geen enkele geautomatiseerde scanner had dit gevonden zonder het paneel daadwerkelijk te openen en te proberen te tabben - en geen ontwerp had het kunnen laten zien, want een ontwerp toont geen tabvolgorde.

Bijbehorend principe. Een role="dialog" of een aria-live-regio is een aanvulling op semantiek die op eigen kracht niet duidelijk genoeg is, geen vervanging van goede semantische HTML en al helemaal geen vervanging van daadwerkelijk focusbeheer. Een paneel de juiste rol geven is het makkelijke deel; focus er daadwerkelijk naartoe verplaatsen en bij sluiten weer terugzetten op het element dat het opende, is wat bepaalt of iemand met een schermlezer of alleen een toetsenbord verder komt.

Waarom dit het besluit vasthoudt. Wat eenmaal is beoordeeld en opgelost in een prototype, is later moeilijk te schrappen als "meer dan het minimale" - de vraag is al beantwoord vóórdat iemand hem uit tijdsdruk opnieuw ter discussie kan stellen. Toegankelijkheidskeuzes naar vóór de implementatie verplaatsen is daarmee niet alleen goedkoper, maar ook duurzamer.

Hoe het in het proces landde

Het voorbeeld dat bij dit artikel hoort (zie "Zelf uitproberen" hieronder) is een reconstructie, maar het proces erachter is hoe ik dit type werk in de praktijk aanpak: twee opeenvolgende beoordelingsrondes op hetzelfde artefact, niet één losse kick-off-vergadering. Eerst wordt de gevraagde functie zelf gebouwd en op basis van eigen inzicht snel functioneel en visueel afgerond. Pas daarna volgt een formele beoordeling tegen een vaste standaard - WCAG 2.2 AA, de WAI-ARIA APG.

In echt werk gebeurt die tweede ronde met het hele team: PO, testers, backend- en frontend-collega's kijken samen mee, juist omdat elke discipline iets anders opmerkt - een tester ziet een ontbrekende foutmelding, een backend-collega een impliciete aanname over de data, een PO een scope die groter blijkt dan het ticket suggereerde. Dat is ook de reden dat deze stap een aparte ronde is en geen momentopname tijdens het bouwen: het kost tijd om die mensen bij elkaar te krijgen, en die tijd is de investering waard omdat er dingen naar boven komen die ik als ontwikkelaar alleen niet had gezien. Voor déze reconstructie ontbreekt dat team - zie Grenzen.

De bevindingen uit de beoordeling verwerk ik in een volgende versie van hetzelfde prototype, niet in de productiecode - dat kost minuten tot uren, niet een sprint, omdat er nog geen tests, types of databasecontracten aan vastzitten.

Resultaat

Drie cijfers, uit verschillende bronnen, bewust niet vermengd.

Uit de reconstructie die bij dit artikel hoort: één formele review tegen WCAG 2.2 AA leverde 13 bevindingen op. Vier daarvan waren algemene UI/UX-problemen die al in de eerste bouwronde waren opgelost; de overige negen waren toegankelijkheidsbevindingen die pas zichtbaar werden doordat het scherm daadwerkelijk werkte - waaronder het focusprobleem hierboven. Een tweede versie van hetzelfde prototype loste alle negen op. Dat is na te lezen en na te bouwen, niet een schatting.

Uit echt werk: één functionaliteit die vooraf op ongeveer tien dagen was ingeschat, is uiteindelijk in vijf dagen opgeleverd - inclusief één dag prototypewerk, dus netto ongeveer tien naar zes. Dat cijfer komt niet uit deze reconstructie en ik trek geen rechte lijn tussen de twee; het is één waarneming, geen meting.

Een derde cijfer, ook uit echt werk maar breder dan die ene casus: in meerdere trajecten zorgde ongeveer 10% extra werk - het bouwen van een prototype en het verzamelen van feedback erop - voor naar schatting zo'n 50% minder ontwikkeltijd voor de GUI zelf. Dit is een patroon over meerdere gevallen, niet één waarneming zoals het cv-cijfer hierboven, maar wel uitdrukkelijk een schatting - ik heb er geen tijdregistratie naast liggen om het exact te onderbouwen, en dat zeg ik er ook zo bij als ik dit noem.

Grenzen

Het vervangt geen professionele interactieontwerper; er zit geen gebruikersonderzoek en geen bredere visuele systematiek in.
De review in het bijgevoegde voorbeeld is door mijzelf en een AI-agent gedaan, niet door het hele team zoals in echt werk (zie "Hoe het in het proces landde"). Voor déze reconstructie ontbreekt dus precies de cross-disciplinaire kruisverificatie die de methode in de praktijk sterker maakt.
Stakeholders zien een werkend scherm snel aan voor "bijna af", terwijl het functioneel misleidend simpel is (geen backend, geen echte data, geen foutafhandeling). Dat maak ik expliciet bij elke presentatie van een prototype.
Een prototype kan onbedoeld een architectuurkeuze voorsorteren: als de gekozen interactie een bepaalde datastructuur of API-vorm impliceert, is die keuze soms al gemaakt voordat iemand het besefte.
Het werkt alleen als er iemand is die de uitkomst kan beoordelen op meer dan smaak - tegen een vaste standaard (WCAG, een bestaand patroon), niet tegen persoonlijke voorkeur.

Wanneer wel, wanneer niet

Wel: onduidelijk interactiegedrag, een functie die meerdere bestaande patronen raakt, een beslissing die duur wordt als hij verkeerd valt. Niet: cosmetische wijzigingen, gedrag dat al vastligt in een bestaand, vergelijkbaar scherm, of een team zonder mandaat om de uitkomst ook echt te laten gelden.

Zelf uitproberen

De reconstructie die de voorbeelden in dit artikel onderbouwt - een fictief scherm ("FleetShare", geen bestaand bedrijf of product) met dezelfde soort tabel, selectie, filters en panelen, doorlopen in drie stappen: de uitgangssituatie zonder de nieuwe functie, de functie met de toegankelijkheidsreview nog open, en dezelfde functie met alle bevindingen opgelost - staat als losse, zelfstandige HTML-bestanden zonder build-stap of backend.

Bekijk de demo

Volg de bestanden in die volgorde en probeer bewust ook met alleen het toetsenbord te navigeren; het verschil tussen de tweede en de derde stap is dan het duidelijkst.