Van Figma naar productie zonder kwaliteitsverlies

Elke ontwerper kent het moment. Je levert een ontwerp op waar je trots op bent, en wat een paar weken later terugkomt lijkt er bijna op. De ruimte tussen twee vakken is vier pixels breder, het lettertype heeft een ander gewicht, het laadscherm dat je had bedacht is er niet. Niemand deed iets fout. Het ontwerp is alleen nagebouwd door iemand die er niet bij was toen het gemaakt werd.

Dat gat heeft minder met tooling te maken dan met de aanname dat design ophoudt waar bouwen begint. In de praktijk worden de meeste ontwerpbeslissingen tijdens het bouwen genomen: wat er gebeurt als een lijst leeg is, als een naam te lang is, als het internet wegvalt, als iemand geen rechten heeft. Staat dat niet in het ontwerp, dan beslist de developer het. Vaak goed, soms niet, en jij hoort het pas als het live staat.

Wat we in het ontwerp zetten

Dus ontwerpen we die toestanden mee. Leeg, laden, fout, te veel, geen rechten. Het is het minst glamoureuze deel van het werk en het deel waar een overdracht in de praktijk op stukloopt. Daarnaast leggen we vast waarom iets is zoals het is, in een paar zinnen naast het scherm, zodat een latere wijziging de redenering niet per ongeluk ongedaan maakt.

En we sturen het niet op. We lopen het door, met de developers erbij, en daarna blijven we in de buurt. Bij een team dat we deze week inwerkten, schuiven we voortaan aan bij hun wekelijkse afstemming. Een vraag over een hover-kleur kost dan twee minuten in plaats van een mailwisseling van drie dagen.

Eén set afspraken voor kleur, ruimte en letter

Het grootste verschil maakt iets dat je in het eindproduct nooit ziet. Elke kleur, elke maat witruimte, elke lettergrootte en elke hoekafronding in het ontwerp heeft een naam. De kleur van gewone tekst heet "tekst, primair". De ruimte tussen twee velden heet "medium". Geen codes van zes tekens, geen losse pixelmaten. Gebruikt de code diezelfde namen, dan zijn het ontwerp en het product hetzelfde ding in twee vormen. Verander je de primaire tekstkleur, dan verandert hij in Figma en in het product tegelijk, en loopt niets uit de pas.

Dat betekent ook dat we developers vertellen wat ze níet moeten overnemen. Figma kan van elk scherm code uitspugen, en die code is niet bruikbaar: vaste breedtes in pixels die niet meeschalen, kleuren als losse getallen. We zeggen: lees er de maten en de namen uit af, en bouw het met de hand op de afspraken. Dat is langzamer op dag één en sneller op elke dag daarna.

Waarom we steeds vaker zelf bouwen

Lang voor er AI aan te pas kwam, zaten wij al naast de developer. Wat veranderd is, is dat we het bouwen nu vaak zelf doen. Met AI-codetools kunnen we een gevalideerd ontwerp helemaal tot werkende software brengen, met dezelfde afspraken voor kleur en ruimte als in het ontwerp, en met de toegankelijkheid er vanaf het begin in.

Het begint al eerder. Een prototype bouwen we nu in code, in plaats van in klikbare schermen. Knoppen werken, velden nemen echte invoer aan. Het voelt als het product omdat het in de kern het product is. De keuzes die vroeger pas tijdens de bouw bovenkwamen, zoals wat er gebeurt als het veld leeg blijft, maken we nu in de ontwerpfase, omdat we er tegenaan lopen. Wat de klant goedkeurt is wat live gaat.

We zijn er open over dat AI daarbij het zware werk op de code doet. Ons vak is design. Wij sturen en kiezen, en houden het resultaat trouw aan wat er ontworpen is. En heeft een project engineering nodig die dieper gaat dan wij reiken, dan zeggen we dat en halen we de juiste mensen erbij.