Cum predai macheta dezvoltatorului, ca să fie acceptată din prima

28 august 2026 · 10 minute · Tomsa Daria

Dezvoltatorul pune aceleași opt întrebări la orice machetă. Vedem cum le răspunzi din timp — prin structura fișierului, tokenuri, stări și text lângă ecrane.

Ce întreabă, de fapt, dezvoltatorul

Macheta arată cum se vede interfața într-o singură stare concretă, cu date concrete. Tot restul dezvoltatorul ori va întreba, ori va inventa singur. Întrebările costă timp, iar ce este inventat costă refaceri. Iată lista care se repetă de la un proiect la altul:

Răspunsurile la aceste opt întrebări formează specificația. Ea nu trebuie să fie neapărat un document: este de ajuns un bloc de text lângă fiecare ecran, în care este scris pe puncte ce se întâmplă și ce nu se întâmplă. Mai departe în articol — cum pregătești fișierul în sine, ca la specificație să nu mai trebuiască adăugată și explicația despre unde se află fiecare lucru.

• Ce se întâmplă la apăsare? O tranziție, o fereastră modală, o schimbare pe loc. Și unde duce butonul «înapoi».
• De unde vin datele și ce se întâmplă dacă lipsesc? Catalog gol, produs fără fotografie, preț vechi inexistent.
• Ce se întâmplă cu datele lungi și cu cele scurte? Un titlu de 120 de semne, un preț din șase cifre, un nume de utilizator dintr-o literă.
• Regulile de validare a formularului. Când se afișează eroarea — la scriere, la pierderea focusului sau la trimitere. Și textele exacte ale erorilor, nu cuvântul «eroare».
• Ce se întâmplă în timpul așteptării? Butonul se blochează, se afișează un skeleton, ecranul nu sare.
• Ce se vede când lucrezi de la tastatură? Ordinea de parcurgere cu Tab, unde este chenarul de focus, ce închide Escape.
• Cum se comportă blocurile la îngustare? Nu «fă-l responsive», ci comportamentul fiecărui bloc.
• Ce nu intră în sarcină. O listă explicită: nu facem favorite, nu există autentificare prin rețele sociale. O graniță neînchisă a sarcinii este o sursă de conflict la recepție.

Ordine în fișier: pagini, denumiri, ce ștergi înainte de predare

Fișierul pe care îl deschide dezvoltatorul nu este construit ca fișierul în care lucrează designerul. Designerului îi este comodă o pânză cu ciorne și variante, dezvoltatorul are nevoie de un singur răspuns la întrebarea «ce am de făcut». Ordinea în fișier este o cale de a da acest răspuns, nu un obicei estetic.

Adu lista de pagini la această formă: → Gata pentru dezvoltare, 01 Ecrane — desktop, 02 Ecrane — mobil, 03 Componente, 04 Stiluri și variabile, 05 Arhivă. Săgeata din numele primei pagini o ridică sus și spune imediat unde trebuie mers. Pe pagina «Gata pentru dezvoltare» se pun nu copii, ci chiar ecranele actuale: duplicatele se depărtează în decurs de o săptămână și devin o sursă de erori.

În interiorul paginii, grupează ecranele în Sections (tasta Shift + S) după scenarii: «Catalog», «Produs», «Coș», «Stări de serviciu». Secțiunea are un comutator Ready for dev — activează-l la secțiunile finalizate și ele vor fi marcate în modul pentru dezvoltatori.

Ce ștergi și cureți înainte de predare: layerele ascunse cu ochiul — ele rămân în fișier și ajung în export; instanțele desprinse — un layer cu numele componentei, dar fără romb; stilurile duplicate, de tipul Body / M și Body/M 2, care apar la copierea din alte fișiere. Adu denumirile la un singur sistem: ecranele — după scenariu și stare («Catalog», «Catalog / Gol», «Catalog / 375»), componentele — după tip («Buton / Principal»), layerele din componentă — după rol («Etichetă», «Pictogramă»), nu «Text 4».

Nu șterge ciornele — mută-le pe pagina «Arhivă». Peste o lună, clientul va întreba de ce ați renunțat la o variantă, iar varianta trebuie să poată fi găsită. Și creează o versiune cu nume: File → Show version history, un punct cu un nume de tipul «Predare în dezvoltare». Este singura cale de a reveni la starea care a fost aprobată.

Un obicei periculos, de care merită să te lași imediat: mai multe copii ale aceluiași ecran, cu nume ca «Catalog final», «Catalog final 2», «Catalog final gata». Dezvoltatorul îl va lua pe cel greșit, iar vinovat nu va fi el. Regula este simplă: o sarcină — un ecran.

În cursul «Interfețe în Figma», predării către dezvoltare îi este dedicat un modul final întreg, iar în materiale se află un șablon de predare: structura fișierului și checklistul după care macheta este acceptată fără o sută de întrebări suplimentare.

Tokenuri și stiluri în locul «simplelor culori»: de ce economisesc corecturi

În modul pentru dezvoltatori, la selectarea unui layer, panoul din dreapta arată dimensiuni, spațieri, culori și tipografie. Diferența dintre o machetă bună și una proastă se vede exact aici: numele action/primary din panou este util, în timp ce un simplu #2F5D3A îl obligă pe dezvoltator să creeze încă o constantă fără nume. Peste o lună, în cod vor fi opt nuanțe de verde și nimeni nu va putea spune care dintre ele sunt aceeași culoare.

Minimul care merită construit chiar și într-un proiect mic: stiluri de text (titluri, corp, legende), variabile de culoare cu roluri, variabile numerice pentru spațieri. Rolul contează mai mult decât nuanța: text/secondary va supraviețui unei schimbări de paletă, în timp ce gray-500, în tema întunecată, încetează să fie gri și începe să mintă.

Un nume bun se construiește după gramatica «categorie — rol — stare»: bg/surface, text/primary, border/default, action/primary-hover, status/error. Verificarea este una singură: citește numele și încearcă să schimbi valoarea. Dacă numele încetează să fie adevărat, înseamnă că a fost dat după aspect, nu după rol.

Economia se numără aici în corecturi. Clientul cere ca accentul de culoare să fie mai închis — într-un fișier pe variabile este o singură valoare, într-un fișier cu layere colorate manual sunt o oră și jumătate și trei butoane omise. La fel și în cod: o culoare cu nume se schimbă într-un singur loc, una fără nume — prin căutare în opt fișiere, cu riscul de a atinge altceva.

Și spațierile merită ținute în variabile, mai ales dacă proiectul are versiune de mobil: variabile numerice, precum space/section și space/page, cu modurile Desktop și Mobile, comută densitatea întregii machete printr-o singură acțiune, nu prin corectarea fiecărui container.

Dacă ecranele sunt deja mai multe de cinci, iar culorile și dimensiunile din ele se depărtează, aceasta este o temă separată — design system: auditul machetelor existente, trei niveluri de tokenuri și regulile după care totul se întreține mai departe. Dar nu este nevoie să începi așa ceva pentru un singur landing — până la o anumită scară, un set îngrijit de stiluri este de ajuns.

Stări: hover, focus, apăsare, eroare, blocare, încărcare, gol

O machetă fără stări este o fotografie a interfeței în cel mai fericit moment: datele au sosit, erori nu există, utilizatorul nu a apăsat nimic. Acesta este principalul motiv pentru care machetele sunt trimise înapoi la refacere.

Setul obligatoriu arată astfel. Default — starea de repaus. Hover — cursorul este deasupra elementului; doar pentru mouse, pe telefon nu există. Pressed — momentul apăsării. Focus — elementul este selectat de la tastatură: un chenar de grosime 2 și un contrast de cel puțin 3:1, fără de care formularul nu poate fi folosit fără mouse. Disabled — acțiunea este indisponibilă, iar alături este nevoie de un text cu motivul. Loading — la buton, înlocuirea etichetei cu un indicator, păstrând lățimea; la listă, un skeleton în locul unui spinner în mijloc. Error — textul erorii lângă cauza ei, nu un banner general sus. Empty — coș gol, rezultat de căutare gol, catalog fără produse după filtru.

Nu fiecare element are nevoie de toate cele opt. Butonul — default, hover, pressed, focus, disabled, loading. Câmpul — default, focus, error, disabled. Ecranul — starea obișnuită, încărcare, gol, eroare de încărcare. Lista pare lungă exact până în momentul în care construiești stările ca variante ale componentei: atunci sunt șase celule într-un set, nu șase ecrane separate.

Este mai bine să arăți stările nu ca imagini separate, ci direct în setul de variante: atunci dezvoltatorul vede că este o singură componentă cu un comutator, nu șase elemente diferite. În interiorul setului, stările pot fi legate interactiv — o tranziție While hovering de la Default la Hover și While pressing la Pressed — și vor funcționa în toate instanțele de pe ecrane. Totodată este și o verificare pentru tine: dacă tranziția nu are unde să ducă, înseamnă că starea nu a fost desenată.

Două reguli care merită verificate înainte de predare. Prima: trecerea cursorului nu poate fi singurul mod de a afla ceva important — un buton de ștergere care apare doar la hover este complet indisponibil pe telefon. A doua: pe un ecran gol trebuie să existe o explicație și o acțiune, nu o inscripție singuratică «Nu s-a găsit nimic». Skeletonul, la rândul lui, trebuie să repete structura cardurilor, altfel ecranul va sări în momentul încărcării.

Responsivitate: breakpoint-uri și ce se întâmplă cu fiecare bloc între ele

Responsivitatea nu înseamnă trei machete separate, ci o singură machetă cu comportamentul descris. Dezvoltatorul scrie un singur cod, cu câteva media query-uri, iar cu cât felul tău de a gândi este mai apropiat de asta, cu atât îți va pune mai puține întrebări.

Breakpoint-urile sunt stabilite de conținut, nu de o listă de dispozitive populare: un punct este necesar acolo unde patru carduri pe rând încetează să încapă. Un set de lucru pentru un magazin este 1440, 1024, 768 și 375; pentru fiecare notează numărul de coloane, spațierile laterale și distanța: de exemplu, la 1440 o grilă de 12 coloane, spațieri de 120, distanță de 24, patru carduri pe rând; la 768 — 8 coloane, spațieri de 32, distanță de 16, două carduri.

Urmează partea cea mai valoroasă — tabelul comportamentelor. Rânduri: antetul, blocul promoțional, filtrele, grila catalogului, cardul de produs, subsolul. Coloane: breakpoint-urile. În celule — unul dintre cele patru tipuri de comportament: se întinde (ocupă toată lățimea disponibilă, cu o lățime minimă), trece pe rândul următor (un rând devine mai multe rânduri), se rotește (un rând orizontal devine coloană verticală), se ascunde sau se înlocuiește (meniul devine buton, filtrul lateral devine panou pop-up).

Trebuie desenat doar ultimul tip: blocurile înlocuite. Restul se descrie în cuvinte, iar asta este mai onest — trei machete desenate tot nu vor acoperi lățimile intermediare, în timp ce un tabel le acoperă.

Separat, pentru versiunea de mobil, fixează regulile pentru deget: zona minimă de apăsare de 44 pe 44 de pixeli (pictograma poate fi de 24, dar frame-ul din jurul ei trebuie să fie de 44), distanța dintre ținte alăturate de cel puțin 8, textul nu mai mic de 14. Aceste numere vor fi verificate de dezvoltator, iar tu îți vei economisi un tur de corecturi.

Pictograme, fonturi, imagini: formate și cum le predai

Pictogramele — în SVG. Înainte de export, unește contururile (Cmd/Ctrl + E) și transformă liniile în umpluturi, altfel dimensiunea pictogramei în cod va varia. Configurează exportul direct în fișier: secțiunea Export din panoul Design, formatul SVG.

Imaginile raster — în PNG sau WebP, în două densități. Plusul din secțiunea Export adaugă un al doilea preset: 1x și 2x, cu sufixul @2x.

Numele fișierelor — cu litere latine, fără spații: icon-cart.svg, hero-plants@2x.png. Caracterele nelatine din nume strică build-ul pe o parte dintre servere.

Logoul — separat și în două variante: color și monocrom, pentru fundal întunecat.

Fonturile. Numește familia, stilurile și greutățile lor numerice — nu «mediu» și «gros», ci 400, 500, 700. Dacă fontul este cu plată, spune asta imediat și atașează linkul către licență: cumpărarea unui font durează uneori mai mult decât tot codul. Pentru fonturile de sistem, indică variantele de rezervă.

Pentru fotografii, numește separat proporțiile și comportamentul: ce raport de aspect are cardul de catalog, ce se face cu o poză verticală, dacă este decupată din centru sau încadrată în întregime. Altfel, pe date reale, jumătate din catalog va ieși turtită.

Și o regulă generală: nu rescrie manual ceea ce Figma predă singură. Dimensiunile, spațierile, culorile cu numele variabilelor și tipografia le va lua dezvoltatorul din modul pentru dezvoltatori. Sarcina ta este ca aceste valori să fie corecte.

Ce nu poate rămâne «pe cuvânt»: animații, texte de eroare, cazuri-limită

Specificația este comod de ținut chiar pe pânză: un frame de text, lat de 400, în stânga fiecărui ecran. Un document separat, într-un alt serviciu, trăiește după regulile lui și, peste două săptămâni, contrazice macheta.

Textele. Toate mesajele de eroare, indiciile, legendele stărilor goale — cuvânt cu cuvânt. «Arată o eroare» nu este un text de eroare. Tot aici intră regulile de acord și formatele: «2 produse» și «5 produse», prețul «124 900 ₽» sau «€1 249», data în formă scurtă sau lungă.

Animațiile și tranzițiile. Ce anume se schimbă, în câte milisecunde și cu ce curbă. Peste 200 ms interfața pare vâscoasă, sub 80 ms tranziția nu se citește. Dacă animația nu este descrisă, ori nu va fi făcută, ori va fi făcută într-o jumătate de secundă.

Cazurile-limită. Un titlu pe trei rânduri, un preț din șase cifre, un produs fără fotografie, un filtru gol, căderea rețelei în mijlocul trimiterii formularului. Cel mai simplu este să le arăți direct în machetă, ca frame-uri separate lângă ecranul principal — asta este mai puternică decât orice text.

Comportamentul neevident — prin adnotări. Activează modul pentru dezvoltatori (Shift + D), ia instrumentul Annotate și notează butonul fixat, banda de filtre cu derulare, câmpul de căutare. O adnotare se leagă de layer și se mută împreună cu el, iar de ea pot fi prinse proprietăți concrete, ale căror valori se vor actualiza singure la modificarea machetei.

Și cea mai costisitoare greșeală de predare: să predai o machetă în care spațierile au fost stabilite prin coordonate. În modul pentru dezvoltatori, un astfel de bloc arată distanțele calculate din realitate — 23, 25, 24 — iar dezvoltatorul va repeta aceste trei numere în cod. Auto layout-ul predă padding-ul și gap-ul ca valori explicite; dacă blocurile din fișier se destramă, merită mai întâi reparat asta, iar cum se face am analizat în articolul auto layout-ul în Figma se destramă.

Predarea în direct: 20 de minute de apel în locul a trei zile de corespondență

Chiar și un fișier perfect câștigă dintr-o întâlnire scurtă. Douăzeci de minute pentru patru puncte: parcurgi scenariul în întregime, arăți stările de serviciu, numești granițele sarcinii («asta nu intră în sarcină»), stabiliți unde se trimit întrebările.

O verificare care înlocuiește orice autoevaluare: dă fișierul unei persoane care nu a participat la proiect și roag-o să povestească ce se va întâmpla la apăsarea pe un card și ce se va întâmpla dacă nu există produse. Dacă a răspuns fără să pună întrebări, fișierul este gata. Dacă a început să plimbe cursorul pe pânză — știi ce mai ai de scris.

Ține întrebările de după predare în comentariile la machetă (tasta C): comentariul este legat de un punct din fișier și, peste o săptămână, se înțelege despre ce este vorba, spre deosebire de o listă din messenger. Înțelegerile notează-le în scris tot acolo — o înțelegere nenotată reapare la următoarea întâlnire ca greșeala ta.

Și un checklist scurt, înainte de a trimite linkul: ecranele actuale sunt pe o singură pagină și marcate Ready for dev; în fișier nu există layere cu nume implicite, layere ascunse și instanțe desprinse; culorile și tipografia se afișează cu numele variabilelor; la toate pictogramele este configurat exportul; pentru fiecare ecran sunt scrise răspunsurile la cele opt întrebări din prima secțiune; există tabelul comportamentului blocurilor pe breakpoint-uri; textele erorilor sunt scrise cuvânt cu cuvânt; a fost creată o versiune cu nume.