Asset Voorbereiding: De Volledige Checklist

Alles wat je moet doen voordat je assets naar developers stuurt. Van bestandsformaten tot naamgeving tot exportinstellingen.

10 min leestijd Beginner Maart 2026

Designer werkt aan asset voorbereiding op laptop met design system zichtbaar op tweede monitor

Waarom voorbereiding cruciaal is

Je assets zijn klaar. Het design ziet er goed uit. Nu naar de developers — en dan gaat het fout. Bestanden in het verkeerde formaat. Naamgeving die nergens op slaat. Exportinstellingen die niet kloppen. Ineens vertragen de developers en stellen vragen die je allang had moeten voorzien.

Dit hoeft niet. Met een goede voorbereiding scheelt je team uren werk en frustratie. Developers kunnen meteen aan de slag. Je design wordt precies zo gebouwd als je het bedoeld hebt. En iedereen weet precies wat verwacht wordt.

Georganiseerde mappenstructuur met assets op een computer scherm met kleurgecodeerde labels

De Voorbereiding Checklist

Doorloop deze stappen voordat je iets naar je developers stuurt. Dit zijn de dingen waar ze echt om vragen — en waar ze echt mee worstelen wanneer het niet klopt.

Bestandsformaten Controleren

Gebruik altijd SVG voor iconen en logouitvoering. PNG met transparantie voor graphics met effecten. JPG alleen voor foto’s. Web-formaten zijn .svg, .png, en .jpg — nooit PSD of AI-bestanden naar developers sturen.

Naamgeving Consistent Maken

Geef alles logische namen. Button-primary-default.svg, niet “knop_v3_FINAL.svg”. Gebruik altijd lowercase, koppeltekens (geen underscores). Zorg dat de mappenstructuur duidelijk is: /buttons, /icons, /backgrounds, /illustrations.

Maten en Afstanden Vastleggen

Zorg dat alle maten in je design kloppen met je design system. Buttons zijn 44px hoog (minimum voor mobiel). Padding en margins volgen je spacing scale (8px, 16px, 24px, 32px). Dit scheelt developers uren debugging.

Kleurcodes Documenteren

Export je color palette met hex-codes. Zorg dat je color naming logisch is: primary, secondary, success, warning, error. Gebruik geen namen als “donkerblauwtje” — gebruik semantische namen die developers direct kunnen begrijpen.

Typografie Specificeren

Documenteer font families, font sizes, font weights, en line heights. H1 is 32px / 40px line-height. Body text is 16px / 24px. Zorg dat je alleen web-safe fonts gebruikt of dat je duidelijk maakt welke web fonts nodig zijn.

States en Variaties Meesturen

Een button is niet alleen de default state. Je moet ook hover, active, en disabled states tonen. Formulieren hebben focus states nodig. Geef developers alle states zodat ze weten hoe iets eruit ziet in verschillende situaties.

Bestandsformaten: De Juiste Keuze

Niet alle formaten zijn geschikt voor web. SVG is perfect voor iconen omdat het schaalbaar is en klein blijft in bestandsgrootte. PNG is het go-to format voor graphics met transparantie en effecten. JPG gebruik je voor foto’s waar je compressie nodig hebt.

Zorg dat je SVG-bestanden proper geëxporteerd zijn. Verwijder onnodige metadata. Zorg dat paden geoptimaliseerd zijn. Dit kan het bestand met 50% kleiner maken. Voor PNG’s: test je compression. Een 2MB PNG kan vaak 200KB worden zonder kwaliteitsverlies.

Vier verschillende bestandsformaten (SVG, PNG, JPG, WEBP) weergegeven met hun eigenschappen en bestandsgroottes

Mappenstructuur met logische ordening van design assets getoond in bestandsbrowser

Mappenstructuur Die Werkt

De manier waarop je je assets organiseert bepaalt hoe snel developers kunnen werken. Een chaotische mappenstructuur is frustratie in mapvorm. Gebruik altijd dezelfde ordening.

Begin met de grote categorieën: /components, /icons, /illustrations, /backgrounds. Daaronder verder splitsen. /components bevat /buttons, /forms, /cards. Zorg dat iedereen dit snapt — het hoeft niet ingewikkeld te zijn, het hoeft alleen logisch te zijn.

Versieringering is cruciaal. Als je een update maakt, noem het dan niet “button-v3-FINAL-REALLY-FINAL.svg”. Noem het button-primary-default.svg en verwijder de oude versie. Geen verwarring, geen ruzie over welke versie nu echt gebruikt moet worden.

Documentatie: Het Verschil Maken

Een README-bestand lijkt saai. Maar het scheelt developers echt veel werk. Maak een duidelijk bestand waarin je uitlegt wat wat is.

Bestand Structure

Leg uit hoe de mappenstructuur werkt. Welke mappen voor wat bedoeld zijn. Waar developers hun assets kunnen vinden.

Naamgeving Regels

Documenteer je naamgeving conventies. Component-state-variant.svg. Zorg dat het consistent is zodat developers weten wat ze zoeken.

Design System Reference

Voeg een link toe naar je design system. Of documenteer direct: colors, typography, spacing scale, component guidelines.

Speciale Instructies

Als er iets bijzonders is (webfonts die geladen moeten worden, iconen die als font nodig zijn), zeg het nu. Niet later.

Praktische Tips Voor Het Handoff

Je hebt je assets voorbereid. Goed gedaan. Nu volgen een paar dingen die echt verschil maken:

Zorg dat je assets in meerdere resoluties beschikbaar zijn. 1x, 2x, en 3x voor het geval developers dat nodig hebben.
Test je SVG-bestanden in een browser. Zorg dat ze correct renderen. Soms gaan kleuren verloren of shapes worden verkeerd weergegeven.
Maak screenshots van hoe states eruit zien. Een screenshot van de hover state is sneller dan de designer opnieuw om uitleg vragen.
Zorg dat iedereen hetzelfde design system gebruikt. Als je designer het ene design system hebt en developers een ander, gaat het mis.
Communiceer van tevoren. Wat verwachten developers? Welke formaten gebruiken zij liever? Maak het af voordat je assets gaat exporteren.

Designer en developer in videocall, beide met laptops, design handoff wordt besproken

Klaar Voor Het Handoff

Goede voorbereiding is de geheime saus voor een soepel handoff. Developers kunnen meteen aan de slag. Je design wordt gebouwd zoals je het bedoeld hebt. Er zijn geen verrassingen halverwege omdat iets niet duidelijk was.

Dit checklist is niet ingewikkeld. Het is eigenlijk heel logisch — je organiseert je assets, je documenteert wat er staat, en je zorgt dat alles klopt. Dat is het. En dat scheelt iedereen enorm veel werk.

Het belangrijkste? Communicatie. Zorg dat je developer en designer op dezelfde pagina zitten. Wat verwacht de developer? Wat is logisch voor de developer? Pas je voorbereiding daarop aan. Dan gaat alles veel soepeler.

Over Dit Artikel

Dit artikel is een educatief gids gebaseerd op best practices in design handoff en developer-designer samenwerking. De richtlijnen zijn gebaseerd op ervaringen uit de praktijk en standaardindustrie. Jouw specifieke workflow kan verschillen afhankelijk van je team, tools, en project scope. Zorg altijd dat je met je team communiceert over wat werkt voor jullie situatie.