← Toate resursele

Mai ai nevoie de design în Figma înainte de development?

Uneltele de design exportă cod, AI generează ecrane din o propoziție, iar clienții întreabă tot mai des de ce plătesc pentru poze cu un site. Întrebare corectă.

Faza de design era de neatacat: nu puteai construi un site fără să decizi mai întâi cum arată, iar decizia pe canvas era mai ieftină decât decizia în cod. Ambele jumătăți sunt acum sub presiune — uneltele generează interfețe funcționale direct, iar Figma însuși dizolvă granița dintre fișier de design și cod. Iată unde mockup-ul își merită încă banii, și unde e o linie de buget pe care o poți tăia onest.

La ce servește de fapt fișierul de design

Un fișier Figma nu e o poză cu site-ul. E un document de decizie — locul unde layout-ul, ierarhia, spațierea, stările, comportamentul responsive și cazurile marginale se stabilesc cât timp schimbarea de părere e încă aproape gratuită. Output-ul vizual e un efect secundar al acelui proces, motiv pentru care „îl vedem după ce e construit” tinde să coste mai mult decât economisește.

Economia e simplă și se confirmă în practică: mutarea unei secțiuni pe canvas ia minute, mutarea ei în cod construit ia ore și poate invalida testarea. Faza de design există ca să concentreze modificările scumpe în partea ieftină a proiectului.

Ce s-a schimbat cu adevărat în 2026

La Config 2026, în iunie, Figma a lansat Motion cu export de animație în Dev Mode, a extins agentul de design de pe canvas cu conectori MCP, și a prezentat layere de cod care trăiesc chiar în fișierul de design. Combinat cu serverul MCP din Dev Mode, care trimite contextul de design direct în tooling-ul AI al developerului în loc de un screenshot, handoff-ul e măsurabil mai puțin lacunar decât acum doi ani.

Efectul practic e că fișierul încetează să fie un livrabil unidirecțional și devine o referință comună care rămâne exactă. Specificațiile de animație nu se mai pierd într-un thread de Slack; o schimbare de token în design system nu mai cere o ședință de traducere. Face faza de design mai ieftină — nu inutilă.

Când poți cu adevărat sări peste mockup-uri

Scop mic și bine înțeles, cu un pattern consacrat: o singură landing page după un layout care s-a dovedit deja, o pagină construită dintr-un design system existent, o construcție pe template unde deciziile de design s-au luat când s-a ales template-ul. În toate acestea, designul întâi dublează muncă pe care altcineva a făcut-o deja.

De asemenea: unelte interne, prototipuri și orice intenționezi să arunci. Dacă publicul e trei colegi și durata de viață e un trimestru, construiește și iterează. Să plătești pentru un design finisat al unui lucru de unică folosință e risipa reală.

Când săritul costă mai mult decât economisește

Mai multe pagini care trebuie să pară un singur site. Orice cu un lanț de aprobare — doi decidenți cu opinii diferite le vor găsi eventual, iar găsirea lor pe canvas e mult mai ieftină decât găsirea lor în staging. Interfețe custom fără un precedent evident: configuratoare, dashboard-uri, fluxuri cu mai mulți pași, orice unde stările de interacțiune depășesc numărul de ecrane.

Și orice proiect unde site-ul e principalul canal comercial. Dacă layout-ul determină venitul, merită o rundă de gândire deliberată înainte să devină o construcție — la asta servesc un audit UX gratuit sau un design de landing page delimitat.

Calea de mijloc pe care o recomandăm de obicei

Proiectează corect cele două-trei ecrane cele mai grele, definește sistemul de dedesubt — scară tipografică, spațiere, culoare, stări de componentă, breakpoint-uri — și construiește restul direct din acel sistem. Ai beneficiul designului decis fără să plătești desenarea fiecărei pagini, iar developerul nu ghicește niciodată cum ar trebui să arate un hover sau un mesaj de eroare.

Asta face și construcția asistată de AI să funcționeze cu adevărat. Cu tokeni reali și două ecrane de referință, output-ul generat e coerent; cu un prompt și niciun sistem, produce ecrane plauzibile care nu aparțin aceluiași site. Design system-ul e constrângerea care face viteza sigură.

Ce să întrebi agenția

Întreabă ce se întâmplă cu fișierul de design după lansare — dacă e abandonat, ai plătit pentru un livrabil, nu pentru un sistem. Întreabă dacă designul definește stări și breakpoint-uri sau doar ecrane de desktop, pentru că tot ce lipsește devine ghicitura unui developer. Și întreabă ce poți tăia: o echipă competentă ar trebui să-ți poată spune de care părți ale fazei de design proiectul tău nu are nevoie.

Surse

Schimbările de tooling menționate mai sus, verificate în iulie 2026.

Întrebări frecvente

Vrei să știi de care părți din faza de design are nevoie proiectul tău?

Trimite-ne scopul și îți spunem ce să proiectăm, ce să construim direct, și ce să sărim.