Figma aanlevercriteria voor externe designers¶

Deze checklist gebruiken we als toetsingskader wanneer een externe designer of designbureau een Figma-ontwerp aanlevert bij Flooris. Het doel is dat een ontwerp niet alleen visueel klopt, maar ook 1-op-1 vertaalbaar is naar code — met name naar TailwindCSS.

Voor wie is dit document?

Developers gebruiken dit als review-checklist vóórdat een ontwerp wordt vrijgegeven voor bouw.
UX/UI-designers (intern en extern) gebruiken dit als kwaliteitsnorm tijdens het ontwerpproces.
Stuur dit document proactief naar externe designers/bureaus bij de start van een project, niet pas bij oplevering.

Hoe te gebruiken¶

Deel dit document met de externe designer bij de kick-off, niet achteraf.
Loop de checklist door bij elke opgeleverde Figma-versie, niet alleen bij de "finale" versie.
Vind je een punt dat niet voldoet? Koppel dit terug met een concrete verwijzing naar het component/frame in Figma, niet alleen "klopt niet".
Een ontwerp is pas development-ready als alle secties hieronder zijn afgevinkt.

1. Buttons¶

Inconsistent buttongebruik is een van de meest voorkomende problemen bij aangeleverde ontwerpen en leidt direct tot extra componenten en twijfel in de code.

Er is een vastgesteld, beperkt aantal buttontypen (bijv. Primary, Secondary, Tertiary/Ghost, Destructive) — niet meer dan noodzakelijk
Er is precies één duidelijk herkenbare primaire button-stijl per context/pagina
Elk buttontype is als Figma-component (met varianten) aangeleverd, niet als losse, telkens net iets andere shapes
Button-groottes zijn consistent (bijv. Small/Medium/Large) en niet ad-hoc per scherm anders

Veelvoorkomend probleem

Meerdere "primaire" buttons met net iets andere kleur, radius of padding op verschillende schermen. Dit levert in code onnodige varianten op en een inconsistente uitstraling.

Onderstaand voorbeeld toont hoe dit er in de praktijk uitziet: dezelfde arrow-buttons voor een carousel komen op de site zowel boven als onder de sectie voor, en daarnaast bestaat er nog een derde, visueel afwijkende variant. Voor developers is dit niet als één herbruikbaar component te bouwen — elk voorkomen wordt een losse uitzondering.

Button states¶

2. Typografie & font-sizes¶

Er is een vast, beperkt aantal font-sizes gebruikt binnen de complete set van componenten (geen willekeurige tussenmaten zoals 15px, 17px, 23px)
Font-sizes zijn direct herleidbaar naar een Tailwind-schaal (zie tabel hieronder) of naar een expliciet gedefinieerde custom schaal
Line-height per font-size is consistent toegepast (niet per instantie handmatig aangepast)
Font-weights zijn beperkt tot een vaste set (bijv. Regular/Medium/Semibold/Bold) en consistent per gebruik (koppen altijd zelfde weight, body altijd zelfde weight)

Overzicht font-sizes → TailwindCSS¶

Vraag de designer om een expliciet overzicht (type-scale) aan te leveren. Vertaal dit naar de standaard Tailwind-schaal, of leg vast welke custom schaal in tailwind.config wordt gebruikt.

Tailwind class	rem	px (bij 16px root)	Gangbaar gebruik
`text-xs`	0.75rem	12px	Labels, meta-informatie
`text-sm`	0.875rem	14px	Hulptekst, formulierlabels
`text-base`	1rem	16px	Standaard body-tekst
`text-lg`	1.125rem	18px	Uitgelichte body-tekst
`text-xl`	1.25rem	20px	Subkoppen
`text-2xl`	1.5rem	24px	Kop niveau 3
`text-3xl`	1.875rem	30px	Kop niveau 2
`text-4xl`	2.25rem	36px	Kop niveau 1
`text-5xl`	3rem	48px	Hero-koppen

Custom type-scale

Wijkt het ontwerp bewust af van de standaard Tailwind-schaal (bijv. een merk-specifiek type-systeem)? Leg dit dan expliciet vast in tailwind.config onder theme.fontSize, zodat er nog steeds één bron van waarheid is — voorkom dat afwijkende maten los in componenten worden geschreven.

Kleurgebruik in tekst¶

Tekstkleuren zijn consistent per functie (bijv. altijd dezelfde grijstint voor hulptekst, altijd dezelfde kleur voor links)
Het aantal gebruikte tekstkleuren is beperkt en herleidbaar naar de kleurenpalet-tokens (zie sectie 5)
Contrast tussen tekst en achtergrond voldoet aan WCAG AA (minimaal 4.5:1 voor body-tekst)

3. Naamgeving van componenten¶

Componenten zijn benoemd in het Engels (consistent met codebase-conventies)
Naamgeving is consistent qua structuur, bijv. Category/Variant of Category / Variant / State (bijv. Button/Primary, Input/Text/Error)
Naamgeving van componenten in Figma sluit logisch aan bij naamgeving die developers in code zullen gebruiken (Button, Input, Badge, Card, Modal, Dropdown, e.d.) — geen Nederlandse of merk-specifieke namen zoals "Knop groot rood"
Lagen/groepen binnen een component hebben ook logische, Engelse namen (niet "Group 47", "Rectangle 12")

Goed vs. slecht

Goed: Button/Primary/Default, Input/Text/Focus, Card/Product/Default

Slecht: Knop 1, Group 23, Rectangle 45 copy 2

4. States (algemeen)¶

Naast buttons (zie sectie 1) moeten ook onderstaande componenten hun volledige set states bevatten in het ontwerp:

5. Input field styling¶

Tekstvelden hebben één consistente stijl (radius, border, padding, hoogte) over het hele ontwerp
Checkboxen hebben één consistente stijl, inclusief checked/unchecked/indeterminate/disabled
Radiobuttons hebben één consistente stijl, inclusief selected/unselected/disabled
Dropdowns/selects hebben dezelfde basisstijl als tekstvelden (tenzij bewust anders, dan gedocumenteerd waarom)
Labels en hulptekst zijn consistent gepositioneerd (bijv. altijd boven het veld, altijd zelfde afstand)
Verplichte-veld-indicatie (bijv. *) is consistent toegepast

6. Kleuren¶

Er is een vastgesteld kleurenpalet aangeleverd (geen losse, ad-hoc gekozen hex-waarden per scherm)
Kleuren zijn herleidbaar naar Tailwind-kleurtokens — als custom palet, dan vastgelegd in tailwind.config onder theme.colors/theme.extend.colors met benoemde tokens (bijv. primary-500, neutral-100) in plaats van losse hex-codes in components
Per kleur is de schaal (bijv. 50–900) consistent qua gebruik: donkerdere tint altijd voor tekst/hover, lichtere tint altijd voor achtergronden, e.d.
Semantische kleuren zijn expliciet gedefinieerd: success, warning, error, info

7. Spacing, grid & containers¶

Afstanden (padding, margin, gap) zijn consistent gebaseerd op een vaste schaal, herleidbaar naar de Tailwind-spacing-eenheden (p-1, p-2, p-4, gap-6, etc.) — geen losse waarden zoals 13px of 22px
Grid-kolommen en gutter-breedtes zijn consistent door het hele ontwerp
Containers (max-width van content) zijn consistent toegepast per pagina-type (bijv. altijd dezelfde max-breedte voor content-pagina's)
Responsive-gedrag van containers en grids is gespecificeerd voor minimaal mobile/tablet/desktop breakpoints

Tailwind spacing-schaal (referentie)¶

Tailwind class	rem	px
`1`	0.25rem	4px
`2`	0.5rem	8px
`3`	0.75rem	12px
`4`	1rem	16px
`6`	1.5rem	24px
`8`	2rem	32px
`12`	3rem	48px
`16`	4rem	64px

8. Iconen¶

Iconen zijn aangeleverd als SVG, niet als PNG/rasterafbeelding of alleen als Figma-vector zonder export
Iconen zijn opgebouwd uit één consistente set/stijl (niet een mix van iconensets met verschillende strokewidths of hoeken)
Varianten zijn consistent: als er zowel solid als outline versies zijn, is dit voor de hele set doorgevoerd, niet per icoon ad-hoc
Consistent gebruik van iconen met/zonder achtergrond-vorm (bijv. altijd in een cirkel, of nooit) — geen willekeurige mix binnen dezelfde context
Icoon-groottes zijn consistent (bijv. 16px/20px/24px) en niet vrij geschaald per instantie
Strokewidth is consistent binnen de hele iconenset

9. Edge cases & contentvariatie¶

Ontwerpen die alleen "ideale" content tonen (korte titels, altijd een productfoto) leveren tijdens de bouw altijd extra vragen op. Vraag expliciet om onderstaande scenario's.

Lange producttitels: hoe gedraagt een titel zich die niet past (bijv. Professionele RVS Keukenmachine met 12 Snelheden en 3 Accessoires XL-Editie)? Wraps de tekst, of wordt deze afgekapt (truncate/line-clamp)?
Lange artikelnummers/kenmerken: is er een maximale breedte/gedrag gedefinieerd voor artikelnummers of specificatie-labels die niet passen?
Ontbrekende productafbeelding: welke placeholder/fallback-afbeelding of -state wordt getoond wanneer een product geen foto heeft?
Empty states: is er voor elke lijst/overzicht (bijv. lege winkelwagen, geen zoekresultaten, geen bestellingen) een expliciet ontworpen empty state, inclusief eventuele call-to-action?
Extreem lange/korte lijsten: is getoond hoe een overzicht met 1 item eruitziet, en hoe met veel items (paginering/scroll)?
Foutpagina's: is er een 404 (pagina niet gevonden) en een HTTP 500 (serverfout) pagina uitgewerkt, inclusief eventuele call-to-action (bijv. terug naar home)?

Vraag dit concreet na bij de designer

"Kun je van het productoverzicht en de productdetailpagina een variant aanleveren met: (1) de langst realistische titel, (2) een product zonder afbeelding, en (3) een leeg zoekresultaat?"

10. Technische aanlevering in Figma¶

Componenten maken gebruik van Figma auto-layout, zodat padding/gap direct afleesbaar en overdraagbaar zijn naar code
Tekst-, kleur- en spacing-styles zijn vastgelegd als Figma variables/styles, niet als losse waarden per laag
Bestand is opgeschoond: geen ongebruikte/verweesde componenten, geen losse test-frames tussen de definitieve schermen
Dev Mode (of gelijkwaardig) is toegankelijk voor developers, met correcte laagnamen zoals hierboven beschreven

Samenvatting¶

Een Figma-ontwerp is pas development-ready wanneer: