Als developers hebben we het afgelopen jaar een enorme versnelling gezien in de adoptie van AI. Andere gebieden binnen IT zijn echter nog niet meegegaan. Vooral in de planning- en designfase wordt AI nog op een beperkte en willekeurige manier ingezet.
Toch zit juist in dit soort rommelige fases vaak het meeste creatieve potentieel. Fases waarin rollen verschuiven, waarin UX engineers als developers gaan denken, en andersom.
In dit artikel zet ik de verschillende stappen van projectdesign uiteen en deel ik vanuit het perspectief van een developer wat ik heb zien werken en wat juist niet.
AI prototyping: ideeën valideren vóór development
Code schrijven is goedkoop geworden, dus waarom zou je geen interactieve prototypes gebruiken om het ruwe idee te valideren, voordat je overgaat naar de uiteindelijke development? Dat klinkt logisch, omdat een klant zo in korte tijd een ogenschijnlijk realistische versie van de uiteindelijke interface kan testen. Toch kan dit niet het startpunt van development zijn.
Vibe-coding platforms produceren steeds nettere code, maar zonder solide fundament. Als je een solide en schaalbare applicatie wilt bouwen, moet het prototype worden weggegooid en opnieuw worden geschreven vanuit de softwarearchitectuur. Daarbij kun je op dit moment nog niet om menselijke beoordeling heen.
Een prototype kan in een heel vroeg stadium van het designproces een uitstekende brainstorming tool zijn met de klant. Aan het einde kan het ook worden gebruikt om snel een ruw idee op de markt te valideren. Maar het moet duidelijk zijn dat er ook in de designfase, en niet alleen tijdens development, bepaalde stappen worden overgeslagen. De belangrijkste zijn de wireframe en het Design System. En hoewel je het Design System altijd later kunt maken, moet de wireframe er eerst komen.
Wireframing: waar menselijke input nog steeds telt
Er wordt vaak gezegd dat de beste wireframes met pen en papier worden gemaakt, en dat klopt absoluut. Dit is de meest menselijke fase van projectplanning. Veel designers met wie ik heb gesproken, denken dat dit de fase is waarin AI de minste voordelen biedt.
Eerst moeten we onderscheid maken tussen het vanaf nul opzetten van een project en het doorontwikkelen van een bestaand project, bijvoorbeeld via een redesign of replatforming. In het eerste geval gebruiken sommige designers AI om ideeën te verzamelen, gebruikersdata te analyseren of requirements te verzamelen. Het daadwerkelijke wireframen gebeurt meestal met de hand of met standaardtools.
Een AI wireframing tool doet in essentie niet veel meer dan zwarte vierkanten op een witte achtergrond plaatsen. Met de hand werken is sneller en kost geen tokens.
Bij bestaande projecten ligt dat anders. Tools zoals Claude Design kunnen verbinding maken met een Design System of een codebase, waardoor je in het designproces rekening kunt houden met bestaande assets. Toch is het niet verstandig om AI hier te veel vrijheid te geven.
Houd er rekening mee dat de meer technische aspecten van het werk, waaronder UI design en interactions, later grotendeels door AI kunnen worden uitgevoerd. Op dit moment is het doel om de basis te leggen en wil je volledig de controle houden. Voor alle volgende stappen kunnen we met meer vertrouwen op AI leunen.
Design Systems: de basis voor AI coding
Dit is de fase van het designproces waarbij AI de grootste voordelen biedt. Het doel is om een duidelijk Design System te creëren dat AI coding tools daadwerkelijk kan gebruiken.
Veel designers staan voor een dilemma: hun workflow volledig omgooien door over te stappen op generative design tools, zoals Claude Design, of vasthouden aan bestaande tools, meestal Figma, die steeds meer AI in hun interfaces integreren.
Er is geen one-size-fits-all antwoord, en we leven in een tijd waarin het antwoord van vandaag morgen waarschijnlijk alweer anders is. Wat we nu wel kunnen zeggen, is dat hoe meer je aan AI delegeert, hoe minder je handmatig kunt doen. Dat geldt ook voor code: hoe meer generated code een project bevat, hoe moeilijker het voor een developer wordt om zonder AI wijzigingen aan te brengen.
Als je dus al een complex project in Figma hebt met een robuust Design System en volledige controle wilt behouden, zou ik bij Figma blijven. Je kunt de beschikbare AI tools gebruiken en tegelijkertijd toegang houden tot de native design features die uniek zijn voor Figma. AI add-ons maken het eenvoudig om componenten uit te breiden en opnieuw te organiseren, statussen toe te voegen, inconsistenties te identificeren en modellen te genereren.
Aan de andere kant kun je Claude Design gebruiken als je vanaf nul begint en een volledig Design System moet opbouwen. Je kunt een eerste versie genereren door Claude Design met een codebase te verbinden en bestaande componenten als startpunt voor verdere iteratie te gebruiken. Je kunt ook bestaande ontwerpen importeren en die als basis gebruiken.
Zelfs een kant-en-klaar Design System kan worden geïmporteerd en toegepast op een bestaande set componenten. Zoals ik eerder aangaf, is die aanpak echter niet echt de moeite waard, omdat je de mogelijkheid verliest om componenten rechtstreeks in Figma te bewerken. Je kunt Claude Code nog steeds gebruiken om een visual style op de code toe te passen. Maar dat is een development task, en een taak die UX engineers ook kunnen oppakken door de component library (componentenbibliotheek) zelf te bouwen.
Design-to-code: componenten en code met elkaar verbinden
De grootste uitdaging hier is het koppelen van componenten uit het Design System aan de corresponderende code-componenten. Dat is vooral lastig wanneer je niet vanaf nul begint of met een complex framework werkt. Denk bijvoorbeeld aan het koppelen van Design System componenten aan Magento templates.
Zelfs onder ideale omstandigheden, zoals software die volledig vanaf nul is gebouwd zonder lay-outbeperkingen, is het mappen van code-componenten aan het Design System allesbehalve eenvoudig.
De eenvoudigste en meest gebruikelijke aanpak is om de gewenste componenten rechtstreeks in de prompt te specificeren. Dit werkt goed voor developers die in korte en duidelijk afgebakende sessies werken. Voor mensen die complete kenmerken of zelfs een volledige applicatie delegeren, kan deze methode echter leiden tot fouten en willekeurige koppelingen.
De tweede optie is het gebruik van Context Files, oftewel Markdown-instructies voor AI agents. Daarmee kunnen we Design System componenten mappen, zodat Claude Code weet welke componenten het moet gebruiken en wanneer.
Als we Figma gebruiken, werkt die mapping door de codebase rechtstreeks via Figma's remote MCP server met het design te verbinden. Bij Claude Design is de synchronisatie echter native en bidirectioneel: Claude Code leest Claude Design en andersom. Het nadeel is dat Claude Design components geen unieke ID's hebben, in tegenstelling tot Figma nodes. Daardoor is de mapping minder strikt.
De laatste optie is relevant wanneer we ook component states willen mappen, of wanneer we met een complexere applicatie werken waarin niet voor iedere component één template bestaat. Denk bijvoorbeeld aan Magento of Shopware.
Met Claude Design moeten we alles uitschrijven in de prompt of vertrouwen op trial and error via progressieve verfijningen. Met Figma hebben we daarentegen een extra tool: Figma Code Connect. Daarmee maak je een expliciete mapping tussen een knooppunt, inclusief al zijn statussen, en een daadwerkelijke component of code-voorbeeld.
Wanneer de codebase geen enkele corresponderende component bevat, kunnen we zelfs tekstuele opmerkingen toevoegen om duidelijk te maken hoe de component moet worden gebruikt. Zo voorkom je dat je verstrikt raakt in implementatiedetails, die de verantwoordelijkheid blijven van de Context Files.
Elke AI coding tool kan inmiddels componenten genereren op basis van het gemapte Design System. Met elk van de bovenstaande opties, met uitzondering van misschien de eerste waarbij development vrijwel volledig handmatig blijft, kan een designer dus zelfstandig een eigen component library bouwen. Bij complexe of legacy applicaties kan dat eventueel met een beetje hulp van een developer.
Hoe AI de rollen van developers en designers verandert
Developers zouden zich op hun beurt kunnen richten op software architecture en simpelweg componenten 'consumeren' die volledig door UX/UI-specialisten zijn gebouwd.
Deze verschuiving in rollen kan de kwaliteit van het uiteindelijke product echt verbeteren, op voorwaarde dat designers en developers nauwer samenwerken dan ze nu doen. Dat begint bij wireframing en componentontwikkeling en loopt door tot de cruciale stap van het opstellen van Context Files.
