Asset Voorbereiding: De Volledige Checklist
Alles wat je moet doen voordat je assets naar developers stuurt. Van bestandsformaten tot naming conventions.
Lees verderSpecification Documenten Schrijven Die Werken
Ontdek hoe je duidelijke, bruikbare design specifications schrijft. Met voorbeelden van component-beschrijvingen, kleurwaarden en typografie-richtlijnen.
Waarom Specifications Belangrijk Zijn
Een goed geschreven design specification is het verschil tussen een soepele handoff en weken van heen-en-weer communicatie. We’re niet aan het praten over 50 pagina’s vol jargon — eerder een heldere, gestructureerde gids die developers alles vertelt wat ze nodig hebben.
Thing is, veel designers stoppen na het design. Ze dumpen bestanden en hopen het beste. Developers zitten dan vast met vragen: Welke kleur precies? Hoe groot is deze spacing? Hoeveel pixels van links? In plaats van samen te werken, start het politieke spel.
De Structuur Die Werkt
Een goede specification volgt een logische opbouw. Start met de basis — kleurpalette, typografie, spacing system — dan bouw je op naar specifieke components. Niet omgekeerd.
Hier’s wat we zien werken bij teams die het goed doen:
- Design System Basis: Kleuren (hex-codes), typefaces, font sizes (in rem units), line heights
- Spacing & Layout: Margin/padding scale (8px, 16px, 24px), grid columns, breakpoints
- Components: Button states, form inputs, cards, headers — met alle varianten
- Accessibility: Contrast ratios, focus states, alt text guidelines
Kleuren Exact Documenteren
Dit is waar veel specs falen. Je plaatst een kleur in Figma en denkt dat het klaar is. Nope. Developers moeten hex-codes hebben, RGB-waarden, en het contrast-ratio voor accessibility.
Geef niet alleen “#3B82F6” — zeg ook:
Voorbeeld:
Primary Blue: #3B82F6 | RGB(59, 130, 246) | Contrast ratio with white: 4.5:1 (WCAG AA compliant)
Voeg ook toe welke kleuren samen gebruikt worden. “Primary Blue op White achtergrond: goed. Primary Blue op Light Gray: niet genoeg contrast — gebruik Secondary Blue in plaats daarvan.”
Typografie: Meer dan Lettertypen
Designers geven een typeface op, developers zeggen “oké, Helvetica” en klaar. Maar daar’s het niet mee. Je moet de hele scale documenteren.
Wij gebruiken een 1.5 scale voor typografie — elk level is 1.5x groter dan het vorige. Hier’s wat dat betekent in praktijk:
H1:
2.5rem (40px) weight: 700 line-height: 1.2
H2:
1.875rem (30px) weight: 600 line-height: 1.3
Body:
1rem (16px) weight: 400 line-height: 1.5
Small:
0.875rem (14px) weight: 400 line-height: 1.4
Voeg ook letter-spacing toe als het niet standaard is. “Headings hebben +0.02em spacing” — dit soort details voorkomen dat developers gissen.
Components in Detail Beschrijven
Dit is waar je specification echt waarde geeft. Neem een button. Het’s niet gewoon een button — het heeft states, varianten, en gedrag.
Button Component
Wij hebben twee button-types: Primary (call-to-action) en Secondary (less important actions).
Primary Button States:
Default: #3B82F6 background, white text, 16px padding vertical/horizontal
Hover: #2563EB (darker), 2px shadow, cursor pointer
Active: #1D4ED8, 4px shadow
Disabled: #D1D5DB background, #9CA3AF text, no cursor change
Min-width: 120px. Border-radius: 8px. Transition: 0.2s ease all.
Form Input
Input velden moeten consistent voelen. Hier’s hoe we ze bouwen:
Border: 1px solid #E5E7EB | Focus: 2px solid #3B82F6 | Height: 44px (touch-friendly)
Padding: 12px 16px | Font: 1rem | Error text: #EF4444, 0.875rem
Always include label positioning (above input), placeholder text behavior, en error message styling. Don’t assume developers know the details.
Tools Die Het Proces Vereenvoudigen
Je kunt specifications schrijven in een Google Doc, maar moderne teams gebruiken betere tools. Hier zijn onze favoriten:
Figma + Specs Plugin
Figma’s built-in specs panel laat je direct waarden zien — padding, size, color. Developers kunnen het live in Figma checken. No switching between apps.
Zeroheight
Maakt design systems makkelijk. Je kunt componenten documenteren, varianten tonen, en code snippets includeren. Developers krijgen precies wat ze nodig hebben.
Storybook
Voor teams die in React/Vue bouwen. Component library met live examples. Designers en developers kijken naar dezelfde source of truth.
Notion / Markdown Docs
Low-tech but effective. Structured documentation, versioned, searchable. Sommige teams verkiezen dit simpelheid.
Best Practices Uit Het Veld
We’ve worked met 30+ teams die dit goed doen. Hier’s wat ze gemeen hebben:
1. Versioneer Je Specs
Specs veranderen. Developers moeten weten welke versie ze implementeren. Markeer het duidelijk: “v1.2 — Updated March 2026.” Voeg een changelog toe met wat veranderd is.
2. Include Examples, Not Just Rules
“Use consistent spacing” is waardeloos. “Use 16px margin between sections, 8px between elements within a section” is bruikbaar. Laat screenshots zien.
3. Document Edge Cases
What happens when a button’s text is really long? When a name has 40 characters? Developers gaan hierover gissen. Zeg het hun.
4. Make It Interactive
Static PDFs zijn voorbij. Use Figma, Zeroheight, or even an interactive HTML page. Developers willen de specs *zien*, niet lezen.
Het Resultaat: Sneller Bouwen, Minder Wrijving
Good specifications aren’t busywork. Ze sparen tijd. Een developer die alles weet van de eerste dag bouwt sneller, vraagt minder vragen, en maakt minder aannames.
Start klein. Document je kleurpalette. Voeg typografie toe. Beschrijf je drie meest gebruikte components. Zie hoe het werkt. Expand van daaruit.
En vergeet niet — specs zijn voor developers, niet voor designers. Schrijf ze als je ze naar iemand stuurt die het design niet gemaakt heeft. Ze moeten alles snappen zonder je vragen.
Een goed geschreven specification is een investering die zich uitbetaalt in elke toekomstige feature.
Gerelateerde Artikelen
Disclaimer
Dit artikel biedt algemene richtlijnen voor het schrijven van design specifications. De best practices en aanbevelingen zijn gebaseerd op ervaringen van ontwerpers en developers in professionele omgevingen. Elk team heeft zijn eigen behoeften en werkwijzen — pas deze richtlijnen aan wat werkt voor jouw situatie. Technologieën en tools veranderen voortdurend. Zorg ervoor dat je informatie up-to-date houdt en tools evalueert die voor jouw workflow het beste passen.