Van Figma naar code: de complete workflow van ontwerp tot ontwikkeling
Van Figma naar code is meer dan een ontwerp naar een website kopiëren. Leer de complete workflow om UI-ontwerpen in Figma om te zetten in responsieve, functionele en schaalbare digitale producten.
Van Figma naar code: wat gebeurt er echt nadat het ontwerp is goedgekeurd?
Je kent dat moment wel, als de designer eindelijk zegt:
"Het Figma-bestand is klaar."
De klant zegt:
"Goedgekeurd!"
Iedereen is blij
Tot de developer naar het scherm kijkt en zegt:
"Oké… en nu moet dit allemaal in code."
En dan begint het echte werk.
Want een Figma-ontwerp omzetten in een werkende website is niet zo simpel als nabouwen wat je ziet.
Er gebeurt eigenlijk heel veel tussen een prachtig Figma-scherm en een live website.
Wat gebeurt er dan achter de schermen?
We leggen het uit, zonder ingewikkeld technisch jargon.
Eerst: wat is Figma naar code?
Zie het zo.
Figma is de bouwtekening.
Code is het echte gebouw.
Figma vertelt je:
"Zo moet de website eruitzien."
De code moet uitzoeken:
"Hoe zorgen we dat het echt werkt?"
Figma toont bijvoorbeeld een mooie inlogpagina.
Je ziet:
- Een e-mailveld
- Een wachtwoordveld
- Een inlogknop
- Wachtwoord vergeten
- Inloggen met Google
Ziet er simpel uit, toch?
Maar de developer moet nog steeds zorgen dat:
De knop echt werkt.
Het formulier fouten opvangt.
Het wachtwoord veilig wordt verwerkt.
De gebruiker ook echt wordt ingelogd.
Dat is het verschil tussen eruitzien als een website en een website zijn.
Wat gebeurt er nadat het Figma-ontwerp is goedgekeurd?
Dit is de route:
Figma → Planning → Code → Testen → Live website
Maar binnen die pijlen gebeurt heel veel.
We gaan het stap voor stap bekijken.
Stap 1: nog niet coderen. Begrijp eerst het ontwerp.
Hier gaan veel projecten de mist in.
De developer krijgt het Figma-bestand en begint meteen te coderen.
Maar wacht even.
Voordat je code schrijft, moet je begrijpen waar je naar kijkt.
Je moet nagaan:
- Hoe is de pagina opgebouwd?
- Welke elementen komen vaker terug?
- Welke lettertypen worden gebruikt?
- Wat zijn de kleuren?
- Hoeveel witruimte is er?
- Wat gebeurt er op mobiel?
- Welke elementen zijn interactief?
Want soms is wat in Figma op 10 verschillende dingen lijkt, eigenlijk één herbruikbaar component.
En als je dat vroeg herkent, bespaar je later uren.
Stap 2: zoek de herbruikbare onderdelen
Stel dat je een website bouwt.
Je ziet dat dezelfde knop terugkomt:
Homepage → 6 keer
Prijspagina → 4 keer
Contactpagina → 2 keer
Ga je die knop 12 keer coderen?
Hopelijk niet.
In plaats daarvan maak je één herbruikbaar knopcomponent.
Als de klant dan zegt:
"Kan de knop iets groter?"
Pas je het één keer aan.
En het wordt overal bijgewerkt.
Daarom kijken developers niet alleen naar het ontwerp.
Ze zoeken naar het systeem achter het ontwerp.
Stap 3: breng het designsysteem in kaart
Nu gaan we de details in.
Welk lettertype wordt gebruikt?
Wat is de merkkleur?
Hoe rond zijn de knoppen?
Hoeveel ruimte zit er tussen secties?
Hoe ziet een kop eruit?
Hoe ziet een kaart eruit?
Dit alles wordt onderdeel van het designsysteem van de website.
Zie het als het reglement van de website.
In plaats van willekeurig te kiezen:
"Misschien hier 18px?"
hebben developers een consistent systeem om te volgen.
En consistentie wordt extreem belangrijk als een website groeit van 5 naar 50 pagina's.
Stap 4: en al die afbeeldingen in Figma dan?
Nu wordt het interessant.
Niet alles wat je in Figma ziet, moet als afbeelding worden geëxporteerd.
Een beginner denkt misschien:
"Dit ziet eruit als een knop. Die exporteer ik."
Maar zo werkt goede ontwikkeling niet.
Een knop moet als echte knop worden gebouwd.
Tekst moet tekst blijven.
Kaarten moeten met code worden gebouwd.
Foto's en illustraties die echt afbeeldingen moeten zijn, kun je apart exporteren.
Waarom?
Omdat echte website-elementen:
Responsief zijn.
Klikbaar zijn.
Toegankelijk zijn.
Aanpasbaar zijn.
En veel makkelijker te onderhouden.
Stap 5: kies nu de technologie
Hier stelt de developer de vraag:
"Wat gaan we bouwen?"
Een eenvoudige bedrijfswebsite?
Dan zijn HTML, CSS en JavaScript misschien genoeg.
Een moderne webapplicatie?
Dan zijn React of Next.js wellicht logischer.
Een mobiele app?
Misschien Flutter of React Native.
Een groot SaaS-product?
Dan denk je aan veel meer:
- Frontend
- Backend
- Database
- API's
- Authenticatie
- Beveiliging
- Schaalbaarheid
Het Figma-ontwerp bepaalt dus niet alles.
De producteisen bepalen dat.
Stap 6: zet het ontwerp om in componenten
Nu wordt het pas echt interessant.
In plaats van te denken:
"Ik moet deze pagina bouwen."
gaat de developer denken:
"Waaruit bestaat deze pagina?"
Misschien uit:
Elk van deze onderdelen kan een herbruikbare bouwsteen worden.
Het lijkt een beetje op LEGO.
Je maakt niet elke keer elk LEGO-steentje opnieuw.
Je gebruikt bestaande steentjes om iets groters te bouwen.
Dat is in de kern wat componentgebaseerde ontwikkeling doet.
Stap 7: bouw eerst de structuur
Nu gaan we eindelijk coderen.
Maar ook hier beginnen developers meestal niet met het perfectioneren van elk klein detail.
Eerst:
Bouw de structuur.
Dan:
Voeg de styling toe.
Dan:
Voeg interacties toe.
Dan:
Test alles.
Vergelijk het met een huis bouwen.
Je kiest niet eerst de kleur van de gordijnen voordat de muren staan.
Hier geldt hetzelfde.
Eerst de structuur. Daarna de details.
Stap 8: laat het eruitzien zoals in Figma
Nu gaan we het ontwerp nabootsen.
Lettergroottes.
Kleuren.
Witruimte.
Knoppen.
Kaarten.
Afbeeldingen.
Randen.
Schaduwen.
Alles begint samen te komen.
Maar er is één belangrijke regel:
Kopieer niet alleen pixels. Begrijp ze.
Waarom?
Omdat Figma misschien een desktopscherm van 1440px toont.
Je gebruiker heeft misschien een:
laptop van 1366px
tablet van 1024px
telefoon van 390px
De website moet op al deze schermen werken.
Stap 9: en dan komt mobiel…
Hier wordt het interessant.
Je prachtige desktopontwerp heeft:
3 kaarten op één rij.
Maar wat gebeurt er op een telefoon?
Daar heb je waarschijnlijk nodig:
1 kaart per rij.
Je desktopnavigatie heeft:
Home | Over ons | Diensten | Contact
Op mobiel?
Misschien wordt het een hamburgermenu.
Je enorme hero-afbeelding?
Die moet misschien kleiner worden of verschuiven.
Dit heet responsive design.
En het is een van de belangrijkste redenen waarom van Figma naar code niet simpelweg "kopiëren en plakken" is.
De developer moet beslissen:
"Hoe moet dit ontwerp zich gedragen als het scherm verandert?"
Stap 10: zorg dat alles echt werkt
Nu begint de website een echt product te worden.
Op een knop in Figma staat misschien:
Inloggen
De code moet iemand ook echt inloggen.
Een zoekbalk moet echt zoeken.
Een formulier moet echt verstuurd worden.
Een dropdown moet echt openklappen.
Een betaalknop moet echt verbinding maken met een betaalsysteem.
Een dashboard moet echt data tonen.
Hier wordt het verschil tussen UI-design en softwareontwikkeling duidelijk.
Figma laat de ervaring zien.
Code creëert de ervaring.
Stap 11: koppel de backend
Laten we een eenvoudig voorbeeld nemen.
Stel je een app voor om online eten te bestellen.
Figma toont:
Restaurant → Gerecht → Winkelwagen → Afrekenen → Betaling
Ziet er eenvoudig uit.
Maar achter die schermen?
Daar gebeurt heel veel.
De applicatie moet weten:
- Wie is de gebruiker?
- Wat heeft hij besteld?
- Wat zit er in de winkelwagen?
- Wat is het totaalbedrag?
- Waar moet de bestelling naartoe?
- Is de betaling gelukt?
- Wat is de status van de bestelling?
Daar komen API's, databases en backendsystemen om de hoek kijken.
De gebruiker ziet de interface.
De technologie erachter laat alles gebeuren.
Stap 12: Figma versus de werkelijkheid
Nu komt ieders favoriete onderdeel.
Open het Figma-ontwerp.
Open de website.
Zet ze naast elkaar.
En opeens…
"Wacht. Waarom ziet dit er anders uit?"
Misschien:
Kop in Figma → 48px
Kop op de website → 42px
Witruimte in Figma → 24px
Witruimte op de website → 16px
Misschien is de knop net iets te groot.
Misschien staat de afbeelding anders.
Misschien voelt de mobiele lay-out te vol.
Deze kleine details doen ertoe.
Daarom vergelijken developers het eindproduct met het oorspronkelijke ontwerp en voeren ze aanpassingen door.
Dit heet design-QA.
Stap 13: test op echte apparaten
Een website kan er op jouw laptop perfect uitzien en op de telefoon van een ander volledig stukgaan.
Test het dus.
Controleer:
Mobiel
Tablet
Laptop
Desktop
En vergeet de verschillende browsers niet.
Let op:
- Kapotte lay-outs
- Tekst die buiten zijn vak loopt
- Knoppen die te klein worden
- Afbeeldingen die er vreemd uitzien
- Menu's die niet openen
- Formulieren die niet werken
Want:
"Op mijn laptop werkt het" is geen teststrategie.
Stap 14: maak het snel
Oké, de website ziet er goed uit.
Hij werkt.
Maar is hij ook snel?
Een prachtige website die eindeloos laadt, is niet bepaald een geweldige ervaring.
Daarom optimaliseren developers onder meer:
- Afbeeldingen
- Lettertypen
- Code
- Scripts
- Componenten
- Laadgedrag
Het doel is simpel:
Zorg dat de website snel aanvoelt.
Want het maakt gebruikers niet uit hoe mooi je Figma-bestand was.
Ze willen dat de website snel voor ze werkt.
Stap 15: vergeet toegankelijkheid niet
Dit wordt ook gemakkelijk over het hoofd gezien.
Een website moet bruikbaar zijn voor zoveel mogelijk mensen.
Dat betekent nadenken over:
- Kleurcontrast
- Navigatie met het toetsenbord
- Leesbare tekst
- Toegankelijke formulieren
- Beschrijvingen bij afbeeldingen
- Focusstatussen
Een ontwerp kan er perfect uitzien en toch voor sommige gebruikers lastig te navigeren zijn.
Goede ontwikkeling draait niet alleen om dingen er goed uit laten zien.
Het draait erom dat ze voor iedereen goed werken.
En AI dan?
Nu komt het interessante deel.
AI kan developers helpen om ontwerpen veel sneller om te zetten in code.
Het kan onder meer genereren:
- HTML
- CSS
- React-componenten
- Tailwind-code
- UI-structuren
Klinkt geweldig.
En dat is het ook.
Maar er zit een addertje onder het gras.
Gegenereerde code is niet automatisch goede code.
Iemand moet nog steeds controleren:
Werkt het op mobiel?
Is het toegankelijk?
Is het veilig?
Is de code onderhoudbaar?
Werkt het nog steeds als het product groeit?
AI kan ontwikkeling versnellen.
Maar goede engineering vraagt nog altijd om menselijk denkwerk.
De grootste fout bij Figma naar code
Denken:
Figma → Kopiëren → Plakken → Klaar
Zo werkt professionele ontwikkeling niet.
Het echte proces ziet er eerder zo uit:
Figma
↓
Begrijpen
↓
Plannen
↓
Componenten bouwen
↓
Code schrijven
↓
Responsief maken
↓
Backend koppelen
↓
Testen
↓
Vergelijken met het ontwerp
↓
Optimaliseren
↓
Lanceren
En opeens lijkt dat simpele verzoek "van Figma naar website" helemaal niet meer zo simpel.
Hoe designers het developers makkelijker kunnen maken
Designers hoeven geen developers te worden.
Maar met een paar dingen verloopt de overdracht een stuk soepeler.
Gebruik:
- Auto Layout
- Componenten
- Consistente witruimte
- Duidelijke laagnamen
- Heldere typografie
- Responsieve ontwerpen
- Georganiseerde assets
En het allerbelangrijkste:
Leg uit wat niet vanzelfsprekend is.
Verandert een knop als iemand eroverheen beweegt? Laat het zien.
Gedraagt een menu zich anders op mobiel? Vermeld het.
Klapt een kaart uit als erop wordt geklikt? Documenteer het.
Goede communicatie kan uren aan onnodige revisies besparen.
Hoe developers het proces kunnen verbeteren
Ook developers hebben een rol.
Vraag niet alleen:
"Waar is de CSS?"
Vraag:
"Waarom is dit component zo ontworpen?"
Begrijp het product.
Zoek naar herbruikbare patronen.
Denk vroeg aan mobiel.
Praat met de designer.
Test tegen het oorspronkelijke Figma-ontwerp.
En wacht niet tot het einde om te ontdekken dat iets niet werkt.
Waar het bij Figma naar code echt om draait
Bij Figma naar code gaat het eigenlijk niet om het omzetten van een ontwerp.
Het gaat erom een idee om te zetten in iets wat mensen echt kunnen gebruiken.
In het Figma-bestand wordt het idee visueel.
In de code wordt het idee functioneel.
En alles tussen die twee punten maakt van een ontwerp een echt digitaal product.
Dus de volgende keer dat iemand zegt:
"Zet die Figma even om naar een website."
weet je dat er achter die woorden veel meer schuilgaat.
Want geweldige digitale producten worden niet alleen ontworpen.
Ze worden met zorg gebouwd.
Mis geen enkel bericht
Abonneer je op onze RSS-feed en elk nieuw artikel komt automatisch in je reader binnen — geen e-mail, geen algoritme.
Werkt met Feedly, Inoreader, NetNewsWire en elke andere reader. Bekijk ruwe feed