De handoff-spec die elke ontwikkelaar mag verwachten

De meest voorkomende reden dat een design langer duurt om te bouwen dan geschat, is niet de technische complexiteit. Het is ontbrekende context voor de ontwikkelaar in het designbestand. Een mockup die er goed uitziet in Figma maar niet vastlegt hoe hij zich gedraagt op 320px, wat zijn error-state is, of welke interactie via het toetsenbord werkt, is een halve spec, geen handoff.

Wat we bij elk scherm opleveren

• Drie breakpoints, niet één. De mobiele (320–640) en het lastige tussengebied (641–1023) horen bij de spec, het is geen bijzaak die de ontwikkelaars er zelf maar even bij verzinnen.
• Elke interactieve state: default, hover, focus-visible, active, disabled, loading, error. Elke state opgeleverd als frame, niet als zinnetje ernaast.
• Empty states voor elke lijst, elke zoekactie en elke tabel. De tekst voor die empty state staat in het design, niet in een los document.
• Tokens, geen pixels. De spec verwijst bij naam naar de bestaande kleur-, spacing- en type-tokens uit het design system. Nieuwe waarden worden gemarkeerd voor review nog voor de build begint.
• Motion-specs in woorden: 250ms ease-out-quart op hover, gedeelde transities tussen routes via layoutId. Ontwikkelaars gokken niet naar duration of easing curves.

Wat we schrappen

Van notities voorziene PDF's van de spec, screenshot-decks voor de stakeholder-review, maatregels op elke padding-waarde. Dit zijn bezigheidsartefacten die alleen bestaan omdat de oorspronkelijke handoff niet goed genoeg was. Maak de handoff goed, en die rituelen verdwijnen vanzelf.

Het designbestand ís de spec. Heeft de spec een Loom-filmpje nodig om uit te leggen, dan heeft de spec geen Loom nodig maar een herziening.