Iedere designer kent dat moment: je legt de laatste hand aan je design in Figma en een week later zie je online dat de spacing, knoppen en hover-states toch nét anders zijn dan dat jij had bedacht. De hand-off van design naar development blijft een spanningsveld. Niet omdat het moeilijk is, maar omdat er vaak iets verloren gaat in de vertaling.
In dit artikel laten we zien hoe die vertaalslag soepeler kan, met praktische tips die zowel designers als developers tijd (en frustratie) besparen.
Waarom overdracht vaak stroef loopt
Laten we eerlijk zijn: Figma is fantastisch, maar het is geen eindstation. Een mooi design zegt nog niets over de bouwbaarheid ervan. Veel designers denken onbewust vanuit visuele logica, terwijl developers juist zoeken naar structuur, consistentie en herbruikbaarheid.
Dat betekent dat één fout in de naamgeving, een ontbrekend component of een inconsistente spacing-regel ineens uren extra werk kan opleveren. En dat is zonde, want het kost tijd, energie en vaak ook kwaliteit.
De grootste oorzaken van een onduidelijke hand-off?
- Lagen en componenten die niet logisch zijn benoemd.
- Verschillende stijlen voor knoppen, titels of marges.
- Onvoldoende states (hover, active, disabled) uitgewerkt.
- Geen duidelijke documentatie van beslissingen of variabelen.
- Teveel verschillende soorten titels
- Inconsistentie in marges
Het zijn details die afzonderlijk klein lijken, maar bij elkaar het verschil maken tussen een gestroomlijnde bouw of een frustrerende puzzel.
Denk als een developer (ook als je designer bent)
De beste tip die we mee kunnen geven: ‘’Ontwerp niet alleen wat je ziet, maar ook wat er straks onder de motorkap gebeurt.’’ Dat betekent niet dat je CSS moet kunnen dromen, maar wel dat je begrijpt hoe een design wordt vertaald naar code. In de praktijk helpt het om al tijdens het ontwerpen te denken in herbruikbare blokken: componenten met vaste spacing, duidelijke hiërarchie en logische naamgeving. Door die structuur al in Figma te gebruiken, snappen developers meteen wat de bedoeling is.
Een paar simpele gewoontes die veel opleveren:
- Gebruik auto-layout: developers herkennen direct de logica achter marges en uitlijning.
- Werk met variabelen: voor kleuren, fonts en spacing zodat wijzigingen consistent blijven. Dit dwingt tot een consistent design system zonder wildgroei aan variaties, wat de developer aanzienlijk veel tijd en dubbel werk bespaart.
- Noem dingen zoals ze zijn: “button-primary-large” zegt meer dan “button-new-copy-copy-def(2)”.
- Documenteer beslissingen: noteer waarom iets zo is ontworpen of hoe het geanimeerd moet worden, dat voorkomt giswerk.
- Figma-annotaties: Maak functionele details inzichtelijk, zoals interactieve states (hovers) en de positionering van elementen (sticky blocks).
- Maak prototypes voor complexe animaties: Door bijzondere interacties vooraf tastbaar te maken, voorkom je miscommunicatie en bespaar je aanzienlijke ontwikkeltijd tijdens de realisatie.
De designer vertaalt de merkstijlen (zoals kleur en typografie) naar een logisch opgebouwd design system, wat zorgt voor een consistente en schaalbare visuele basis.
De developers maken gebruik van Figma’s Dev Mode om het ontwerp direct te vertalen naar code. In plaats van handmatig te meten, lezen zij waarden voor kleur, padding, marges en typografie 1-op-1 uit. Dit garandeert dat de website exact overeenkomt met het ontwerp en voorkomt interpretatieverschillen.
Bovendien zijn alle herbruikbare onderdelen (zoals knoppen en formulieren) gedefinieerd als hoofdcomponenten. Hierdoor kunnen developers in één oogopslag de verschillende statussen en technische eigenschappen inzien. En mocht er toch een detail onduidelijk zijn? Dan is de lijn kort: via gerichte comments in Figma of een snelle check bij elkaar is het zo opgelost.
Die manier van denken en samenwerken zorgt ervoor dat design en development elkaar beter begrijpen. Je merkt het direct in de bouwsnelheid, maar vooral in de sfeer. Minder “Waarom ziet dit er anders uit?” en meer “Fijn, dit sluit precies aan.”
Van chaos naar duidelijkheid: de KCI-case
Een goed voorbeeld is het project voor KCI, een technische engineeringorganisatie met een complexe dienstverlening. Hun oude website liet niet zien wat ze écht deden. Het nieuwe design moest rust, duidelijkheid en professionaliteit uitstralen en tegelijk technisch logisch zijn opgebouwd.
We begonnen niet met de stijlbepaling, maar met structuur: wireframes waarin we de navigatie, hiërarchie en interactie alvast logisch neerzetten. Vanuit daar bouwden we componenten op die zowel visueel als technisch klopten.
In Figma werkten we met één duidelijke bibliotheek:
- alle knoppen, headings en forms als herbruikbare componenten;
- consistente spacing via auto-layout;
- states uitgewerkt per interactie.
Voor de developers betekende dat: geen interpretatie, geen extra correctierondes gewoon bouwen. Zelfs subtiele elementen, zoals het gebruik van de logo-cut-out als dropdown-icoon, waren direct duidelijk dankzij die structuur.
Het resultaat: een website die niet alleen mooier is, maar vooral duidelijker communiceert wat KCI doet. En vooral een proces waarin design en development écht op één lijn zaten.
Samenwerken in de praktijk
Goede overdracht draait niet alleen om techniek, maar ook om communicatie. Een paar principes waar we niet meer van afwijken:
- Plan checkmomenten vóór de bouw. Even samen door het design lopen voorkomt dat developers later moeten raden. Een kwartier afstemmen bespaart uren correctie.
- Houd feedback momenten kort. We werken in korte rondes waarin design en development elkaar soms even raken. Dat houdt de vaart erin en voorkomt verrassingen achteraf.
- Wees eerlijk over wat beter kan. Niet elk ontwerpidee werkt even goed in code. Soms is het slimmer om iets simpeler te houden. Die openheid maakt het proces soepeler en het eindresultaat sterker.
- Maak het schaalbaar. Gebruik vaste namen en herbruikbare blokken. Zo staat er een sterke basis waarmee je later heel makkelijk nieuwe functies of updates kunt toevoegen zonder alles opnieuw te hoeven doen.
Checklist: klaar voor overdracht?
Een korte reality-check die ik standaard doorloop voordat een project richting development gaat:
- Alle componenten hebben logische namen
- Variabelen voor kleur, typografie en spacing zijn ingesteld
- States (hover, focus, active) zijn uitgewerkt
- Grid- en layoutregels zijn consequent toegepast
- Assets zijn netjes gestructureerd (geen ‘final_final_v2’)
- Belangrijke keuzes zijn gedocumenteerd
- Developers weten waar ze vragen kunnen stellen
- Alle verborgen assets en infographics zijn geëxporteerd, zodat de developer direct alles bij de hand heeft
- Bijzondere interacties zijn uitgewerkt in een prototype als technisch voorbeeld
- Specifieke lettertypen zijn gedeeld met de developers (geen zoekwerk achteraf)
- Onduidelijkheden zijn toegelicht met een Loom-video of een korte call
- Annotaties zijn toegevoegd om interacties zoals scroll-gedrag en hovers te verduidelijken.
Het zijn twaalf checkpoints, maar ze besparen zóveel tijd. En het mooiste is dat als je dit een paar keer doet, het vanzelf een gewoonte wordt.
Tot slot
Een soepele overdracht tussen design en development is geen luxe, maar een voorwaarde voor kwaliteit. Het voorkomt frustratie, versnelt projecten en tilt het eindresultaat omhoog. Design is pas écht af als het klopt in code. En dat begint bij hoe je samenwerkt: met structuur, duidelijkheid en wederzijds begrip.
