Lange tijd was het schaarse ding in software een goed doordacht, mooi scherm. Dat kostte vakmanschap en tijd. Design leverde het. Klanten betaalden ervoor.
Dat ding is niet meer schaars. AI produceert in minuten een plausibel, netjes ogend, ongeveer werkend scherm. Niet altijd een correct scherm — maar een plausibel scherm, snel, in volume.
De waarde van design is niet verdwenen. Ze is verschoven — in twee richtingen tegelijk. Stroomafwaarts, naar het gedrag van het systeem onder het glas. Stroomopwaarts, naar de constraints die bepalen wat elk gegenereerd scherm überhaupt mag worden.
Dit is geen pamflet tegen AI. Het is een kaart van waar designwerk landt als generatie goedkoop is en oordeel niet.
Het gedrag van het systeem is het product.
Neem een tool die algoritmisch plant. Een prachtige interface bovenop een algoritme dat twaalf seconden nodig heeft, of een plan voorstelt dat niemand begrijpt, is slechte UX. Punt. En dat repareer je niet met knopposities.
De echte ontwerpvragen zien er zo uit:
- Latency — hoe snel moet een voorstel er zijn voordat mensen het wantrouwen?
- Confidence — wat tonen we als het systeem het niet zeker weet: één antwoord, of alternatieven?
- Uitlegbaarheid — ziet een gebruiker waarom iets zo gepland is? Zo niet: blind gehoorzamen of eindeloos overrulen. Allebei falen.
- Override — wat gebeurt er als een mens het oneens is? Wordt de correctie opgenomen, onthouden, geleerd — of stilletjes weggegooid?
- Conflict — wat doet het systeem als twee waarheden botsen?
Dit zijn ontwerpbeslissingen, een orde belangrijker dan waar de knop staat. En ze zijn van design — niet als decoratie nadat het model getraind is, maar als het brief voor wat het model in de wereld mag doen.
Een gebruiker die het algoritme corrigeert is de feedbacklus die werkt. Ontmoedig de correctie nooit — maar tel hem altijd.
Veel correcties? Dan is de interface niet het probleem: het algoritme weet iets niet. De vraag is niet “hoe maken we corrigeren soepeler” maar “wat vertelt deze correctie ons?”
Nul correcties? Óók een alarm: men vertrouwt blind, of men durft niet. Allebei gevaarlijk.
Zo ziet een KPI eruit als design hem bezit: niet “minder clicks”, maar “wat zegt dit gedrag over het systeem eronder?”
Niet “de gebruiker kan omboeken” — maar “zo min mogelijk omboekingen nodig.”
Niet “de planner kan een sleep toewijzen” — maar “geen conflicterende toewijzingen.”
Het doel gaat meestal tegen de taak in: de beste optimalisatie van een taak is hem overbodig maken. Geen enkele optimalisatielus vindt dat, want een lus neemt de takenlijst als gegeven. Alleen een mens vraagt of de taak überhaupt moet bestaan.
In the agentic era telt dat dubbel. Agents zijn uitstekend in taken die je ze geeft. Ze zijn slecht in het betwijfelen van de takenlijst. De taak van design is die vraag op tafel te houden — in het brief, in de acceptatiecriteria, in de metrics — voordat iemand een model vraagt om “gewoon het scherm ervoor te bouwen.”
Eén vraag sorteert bijna alles:
Maak ik iets dat AI ook had kunnen maken — of iets dat bepaalt wát AI maakt?
AI had het ook gekund: een mockup, een prototype, een Figma-bibliotheek, een zelf met AI gebouwd scherm, een pipeline die Figma naar Cursor draagt. Die laatste is de verleidelijkste: het voelt als vooruitgang, maar het is een snellere motor op de oude werkwijze — het maakt het transport efficiënter van precies het artefact waarvan de noodzaak ter discussie staat.
Dit bepaalt wat AI maakt: de vijf spacing-waardes die we toestaan (en de negen niet), de regel dat elke lijst een lege, laad- en foutstate heeft, de beslissing dat er één button-component is, de spec voor geen-rechten / 500 records / nul records, de acceptabele latency, de microcopy voor de fout waar niemand aan dacht, de tokens en regels die de AI van een engineer als context inleest.
Niets hiervan is een plaatje. Alles is een constraint — en constraints vormen niet één scherm, maar elk scherm dat hierna gegenereerd wordt.
Een mockup verbetert één feature. Een rules file verbetert elke feature die iemand daarna bouwt. Het stapelt.
En commercieel: als een engineer UI genereert met AI en design levert een mockup, dan was die mockup óf overbodig, óf hij wijkt af en iemand moet hem handmatig navertalen — trager dan niks. In beide gevallen is design een stap in het proces geworden in plaats van een vermenigvuldiger.
Stroomopwaarts keert dat om: de regels gaan de generatie in, en de output klopt de eerste keer — omdat design heeft gedefinieerd wat kloppen betekent.
| In plaats van | Leveren we |
|---|---|
| Figma-bestand | tokens.json in de repo |
| Componentbibliotheek in Figma | Componenten in code + een rules-document |
| Mockup per feature | Een spec in het ticket |
| Review van een design | Review van de draaiende build, tegen de regels |
| Handoff-automatisering | Niets — er is niets om over te dragen |
Een bruikbare spec heeft vier secties:
- Doel — wat we minder willen, niet alleen wat de gebruiker kan
- Flows — de stappen, per job to be done
- States — leeg, laden, fout, geen rechten, één item, vijfhonderd items
- Systeemgedrag — acceptabele latency; wat er gebeurt bij lage confidence; wat er getoond wordt bij conflict; hoe het zich uitlegt; wat het doet met een correctie
Sectie 4 is degene die altijd wordt overgeslagen — en degene die bepaalt of het product goed is.
Review verandert mee. Als een bevinding niet herleidbaar is tot een regel, is het smaak, en smaak schaalt niet. Elke handmatige vangst is een regel die nog niet geschreven is — de echte fix is de regel, niet het ticket.
Eigenaarschap krijgt een grens. Design bezit het systeem: tokens, componenten, patronen, states en de gedragsvragen hierboven. Engineering bezit de assemblage. Designers bouwen geen productieschermen; engineers verzinnen geen componenten en beslissen niet wat het systeem doet bij twijfel.
Terecht bezwaar: een spacing-schaal in een JSON-bestand zegt niks. Je moet zien wat 24px doet naast 32px. Natuurlijk.
Het verschil is niet óf we experimenteren, maar wat de bron van waarheid is. Oud: je schuift in Figma tot het goed voelt, en het plaatje is de waarheid. Nieuw: de tokenfile is de waarheid, en het scherm is er een weergave van. Zelfde oordeel, omgekeerde afhankelijkheid.
Praktisch: bouw een plek waar tokens live zichtbaar zijn. Eén route in de codebase — /system, of Storybook — met elk component in elke state. Pas een waarde aan in tokens.json en alles schuift tegelijk mee. Daar voel je het, en beter dan in Figma: je ziet wat een spacing-wijziging doet over veertig componenten, niet over de drie die je toevallig had uitgetekend.
Wegwerpschermen zijn een meetinstrument. Genereer een realistisch scherm met je tokens erin, kijk, gooi weg. Je test de constraint, je maakt geen ontwerp. De grens is scherp: bewaar je het scherm en geef je het aan iemand, dan zit je terug in de oude modus.
En we beginnen nooit blanco. De tokens zitten al in wat we gebouwd hebben, verspreid en inconsistent. Eruit trekken, terugsnoeien, het product ertegenaan houden. Dat kost een paar rondes. Prima.
De regel: het experiment is een instrument, geen deliverable.
Wélk model je tegenaan itereert, doet ertoe. Itereer tegen een zwak, gratis, lokaal model. Nooit tegen een sterk.
Herformuleer wat het zwakke model is en het valt op zijn plek: het is geen mindere ontwerper, het is een renderer. Het maakt geen keuzes — het maakt jouw keuzes zichtbaar. Waarde aanpassen, effect zien, oordelen. Zo vaak je wilt, gratis. Ziet het er fout uit, dan is het fout — en het is fout door jou. Dat is de feedback waar je voor kwam.
Een sterk model is daar ongeschikt voor, en niet omdat het duur is. Omdat het vriendelijk is. Het compenseert. Geef het een spacing-schaal die niet klopt en het maakt er stilletjes iets moois van — het repareert je fout, en je leert niets. Het oordeel dat jij wilde vellen is al geveld, door het model, namens jou. Dát is de delegatie die je wilt vermijden; de kosten waren er alleen een symptoom van.
Het zwakke model rendert. De mens voelt. Het sterke model bouwt — pas nadat het gevoel is gestold in tokens en regels.
Itereer oneindig. Tweaken is niet het denken ontwijken — tweaken is het denken. Maar doe het tegen iets dat dom genoeg is om je de waarheid te tonen.
Zelfde logica één niveau hoger: geef een spec niet meteen aan een sterk model om te bouwen, maar vraag eerst: “lijst elke beslissing op die je zou moeten nemen omdat de spec zwijgt, en markeer welke het gedrag van het product veranderen.” Anders neemt een capabel model die beslissingen voor je — goed, en onzichtbaar.
Er is geen limiet op itereren. De rem zit op de overgang: je gaat pas naar het sterke model als de beslissingen genomen zijn — als het gevoel is gestold in tokens, regels en een spec met alle vier de secties ingevuld.
Vroeg genereren om erachter te komen wat je vindt, is geen iteratie. Het is de beslissing uitbesteden en hopen dat er iets goeds uitvalt.
Dat onderscheid is het hele verschil tussen agents gebruiken als vermenigvuldiger en ze gebruiken als vervanging voor design.
Het oordeel. Zien dat iets er goed uitziet maar niet werkt. De state opmerken waar niemand aan dacht. Doorhebben dat een flow iets vraagt wat we al weten. Begrijpen dat een traag algoritme een ontwerpfout is, geen technische. Vragen waarom deze taak überhaupt bestaat.
AI heeft daar niets van. Dat oordeel is de hele reden dat design aan tafel zit. Het enige dat verandert: we besteden het niet meer aan losse schermen, maar coderen het in het systeem dat ze voortbrengt.
Drie zinnen, dan:
De interface is niet het product. Het gedrag van het systeem is het product.
De output van design is niet langer een scherm dat ergens naartoe moet — het is de context waarin het scherm ontstaat.
En het gevoel blijft bij ons. Itereer tegen iets dat dom genoeg is om je de waarheid te vertellen.