Un sistem de design păstrează site-ul sau aplicația coerentă

Ai nevoie de un sistem de design atunci când aceeași întrebare primește răspunsuri diferite în același produs. Butonul principal este albastru pe site, verde în formular și negru în cont. „Salvează” păstrează o schiță într-un ecran, publică în altul și închide fereastra în al treilea. Pe mobil, fiecare pagină pare construită de altă echipă.

Problema nu este doar estetică. Utilizatorul încetinește, dezvoltatorii repetă munca, iar fiecare modificare poate strica o variantă uitată. Sistemul de design păstrează deciziile bune și le face reutilizabile.

Nu este nevoie de o corporație sau de o bibliotecă cu o sută de componente. Un site de prezentare poate avea un sistem mic: culori, tipografie, spațiere, butoane, formulare, carduri, reguli pentru imagini și câteva principii de conținut. Important este ca regulile să existe în design și în cod, nu doar într-un PDF.

Începe cu un inventar, nu cu o pagină nouă în Figma

Alege cinci până la zece ecrane reprezentative și notează toate variațiile pentru:

• culori de text și fundal;
• dimensiuni și greutăți de titlu;
• spațiere între secțiuni;
• raze de colț și umbre;
• butoane și linkuri;
• câmpuri, etichete și erori;
• carduri și tabele;
• iconuri;
• stări de încărcare și lipsă de conținut;
• texte pentru acțiuni și confirmări;
• comportamentul pe mobil.

Nu corecta încă. Fotografiază realitatea. Dacă găsești șapte nuanțe aproape identice de gri, trei butoane „principale” și patru tipuri de formular, ai deja lista de priorități.

Pentru fiecare variație întreabă:

1. Rezolvă o nevoie diferită?
2. Este folosită suficient de des?
3. Are un comportament diferit sau doar alt aspect?
4. Poate fi înlocuită fără să pierdem informație?

Un sistem bun nu păstrează orice excepție. Nici nu uniformizează lucruri care au roluri diferite.

Definește principiile înaintea componentelor

Principiile ajută atunci când sistemul nu are încă o regulă exactă. Pentru un produs destinat afacerilor locale, ele pot fi:

• claritatea are prioritate față de efectul vizual;
• acțiunea principală trebuie să fie evidentă;
• informația importantă nu depinde numai de culoare;
• versiunea mobilă este proiectată, nu doar micșorată;
• componentele accesibile sunt varianta implicită;
• mișcarea explică schimbarea, nu decorează permanent;
• conținutul real este testat în română și engleză.

Când apare o cerere pentru un carusel automat cu șase mesaje, principiile oferă un răspuns. Nu pentru că un carusel este interzis, ci pentru că trebuie demonstrat că păstrează claritatea și accesul la informație.

Construiește fundația în valori cu sens

Culorile și spațierile devin mai ușor de folosit când numele lor descriu rolul, nu valoarea brută.

În loc de blue-500, produsul poate folosi action-primary. În loc de gray-400, poate exista text-muted. În loc de „24 pixeli”, poate exista space-card. Aceste denumiri sunt numite frecvent tokeni.

Un set minim acoperă:

• fundalul paginii și suprafețele ridicate;
• text principal, secundar și dezactivat;
• acțiune principală și stările ei;
• succes, avertizare și eroare;
• contururi și indicatorul de focalizare;
• scara tipografică;
• scara de spațiere;
• colțuri, umbre și lățimi maxime;
• durate și curbe de animație.

Tokenii nu sunt un scop. Ei permit schimbarea coerentă. Dacă nuanța acțiunii trebuie ajustată pentru contrast, modificarea se propagă în toate componentele care folosesc rolul respectiv.

Alege primele componente după frecvență și risc

Nu începe cu selectorul de date rar folosit sau cu un grafic spectaculos. Începe cu elementele care apar peste tot și produc cele mai multe erori:

1. buton și link;
2. câmp, etichetă, ajutor și eroare;
3. titluri și text;
4. card și secțiune;
5. dialog și panou mobil;
6. notificare;
7. tabel sau listă, dacă produsul le folosește des.

Pentru fiecare componentă documentează:

• scopul;
• când se folosește și când nu;
• variantele necesare;
• stările: normală, la trecerea cursorului, la focalizare, activă, dezactivată, în curs de încărcare și cu eroare;
• comportamentul cu tastatura;
• lungimile de text testate;
• comportamentul pe ecrane mici;
• exemple corecte și greșite.

O captură frumoasă nu este documentație suficientă. Componenta trebuie să răspundă și în situațiile neplăcute: titlu lung, conexiune lentă, listă goală, traducere mai mare sau eroare de server.

Include limba în sistem

Coerența nu se oprește la pixeli. Oamenii învață interfața și din cuvinte.

Stabilește reguli pentru:

• denumirea acțiunilor;
• persoana și tonul folosite;
• majuscule;
• date, ore, numere și monede;
• mesaje de eroare;
• confirmări;
• stări fără conținut;
• texte de ajutor;
• română și engleză.

Un buton trebuie să spună ce se întâmplă: „Salvează modificările”, „Trimite cererea” sau „Descarcă factura”. „Continuă” este potrivit doar dacă pasul următor este evident.

Mesajul de eroare trebuie să ajute: „Introdu o adresă de e-mail în formatul nume@domeniu.ro” este mai util decât „Valoare invalidă”. Confirmarea trebuie să folosească același verb: butonul „Publică” produce mesajul „Articol publicat”.

Pentru localizare, nu proiecta pe exemple englezești scurte. „Settings” devine „Setări”, dar „Your billing and subscription settings” poate ocupa mult mai mult în română. Testează titluri, butoane și meniuri cu text real.

Accesibilitatea trebuie inclusă în piesa reutilizabilă

Dacă butonul comun are contrast corect, indicator de focalizare și zonă suficientă de apăsare, toate paginile pornesc de la o bază mai bună. Dacă dialogul comun gestionează tastatura și întoarce focalizarea la elementul care l-a deschis, echipa nu trebuie să rezolve problema în fiecare ecran.

Lista minimă pentru o componentă interactivă:

• poate fi folosită din tastatură;
• are un nume accesibil;
• focalizarea este vizibilă;
• starea nu este comunicată doar prin culoare;
• textul rămâne lizibil la zoom;
• ordinea este logică;
• animația respectă preferința pentru mișcare redusă;
• ținta este suficient de mare pe telefon.

Sistemul nu garantează automat accesibilitatea întregii pagini. Un titlu ales greșit și un text neclar rămân probleme. Dar mută verificările repetitive într-un loc comun.

Leagă designul de cod

O bibliotecă din Figma și una din aplicație pot evolua separat până nu mai seamănă. Pentru fiecare componentă importantă trebuie să existe o relație clară între design, implementare și documentație.

Stabilește:

• aceeași denumire în design și cod;
• cine aprobă o variantă nouă;
• cum se vede componenta în toate stările;
• cum sunt anunțate schimbările;
• cum sunt eliminate variantele vechi;
• cine corectează diferențele dintre fișier și produs.

Nu crea o componentă comună pentru orice asemănare vizuală. Două carduri pot arăta la fel, dar unul navighează, iar altul selectează. Comportamentul diferit poate justifica două componente care împart doar fundația.

Folosește un proces simplu de contribuție

Un sistem fără responsabil devine o arhivă. Nu ai nevoie de un comitet mare, dar ai nevoie de răspunsuri:

• Cine poate propune o schimbare?
• Cine verifică designul, codul și conținutul?
• Ce teste trebuie să treacă?
• Cum este publicată versiunea nouă?
• Cine ajută echipele să migreze?
• Când este retrasă versiunea veche?

Pentru o echipă mică, procesul poate fi o pagină și o discuție scurtă. Important este ca excepția să nu intre direct în produs și să devină, prin copiere, o regulă accidentală.

Un plan de 30 de zile pentru un sistem mic

Săptămâna 1, inventar: alege ecranele, fotografiază variațiile și grupează dublurile. Notează problemele care afectează utilizatorii sau încetinesc livrarea.

Săptămâna 2, fundație: stabilește principiile, culorile cu rol semantic, tipografia, spațierea, colțurile și focalizarea. Verifică modurile luminos și întunecat, dacă există.

Săptămâna 3, componente: construiește butonul, câmpul, linkul și cardul. Include stările, accesibilitatea, conținutul lung și mobilul.

Săptămâna 4, adoptare: înlocuiește dublurile într-o acțiune reală, documentează folosirea și cere observații de la designeri, dezvoltatori și colegii care publică text.

Nu încerca să „termini sistemul”. Scopul primei luni este să demonstrezi că o cale comună reduce munca și erorile.

Cum măsori dacă ajută

Numărul de componente nu este un indicator de succes. Urmărește:

• câte ecrane folosesc componentele comune;
• câte variante duplicate au fost eliminate;
• timpul necesar pentru un ecran obișnuit;
• defectele vizuale și de accesibilitate repetate;
• diferențele dintre design și implementare;
• numărul excepțiilor;
• cât de ușor găsește echipa răspunsul corect.

Dacă oamenii ocolesc sistemul, întreabă de ce. Poate componenta nu acoperă cazul real, documentația este greu de găsit sau contribuția durează prea mult. Adoptarea nu se obține prin obligație, ci făcând varianta corectă și cea mai ușoară.

Coerența nu înseamnă ca fiecare pagină să arate identic. O pagină de campanie poate fi aerisită, iar un panou de administrare dens. Sistemul păstrează ceea ce utilizatorul trebuie să recunoască: limbajul, acțiunile, stările și regulile de bază. Libertatea rămâne acolo unde servește o problemă reală.