ResNet — Design System enterprise

Provocarea

ResNet AI crescuse rapid. Echipe multiple de produs, termene agresive și nicio autoritate centralizată de design produseseră un peisaj de componente care, sincer, scăpase de sub control.

Cifrele spuneau o poveste dură:

• 1.300+ variante de componente împrăștiate în zeci de fișiere Figma
• 180 stiluri de butoane, multe diferind doar prin padding sau rază de colț
• 58 pattern-uri de navigare pentru ceea ce ar fi trebuit să fie o suită unificată de produse
• Zero documentație care să explice când să folosești ce

Designerii petreceau mai mult timp căutând componenta “potrivită” decât proiectând. Dezvoltatorii primeau predări care contraziceau implementările anterioare. Echipele de quality assurance nu aveau nicio bază de referință pentru testare. Fiecare sprint introducea noi inconsistențe, iar datoria se acumula cu fiecare release.

Clienții enterprise pe care ResNet îi servea așteptau finisaj, predictibilitate și profesionalism. Starea curentă nu livra nimic din toate acestea.

Metodologie în patru faze

Faza 1 — Audit

Am realizat un inventar cuprinzător al fiecărei componente, variante și pattern din ecosistemul existent. Fiecare element a fost catalogat cu fișierul sursă, frecvența de utilizare, proprietățile vizuale și specificațiile comportamentale.

Auditul a relevat că majoritatea celor 1.300 de variante erau duplicate sau aproape-duplicate, componente recreate de designeri diferiți la momente diferite cu interpretări ușor diferite. Numărul real de componente funcționale unice era mai aproape de 200.

Am mapat fiecare componentă la contextul său de utilizare și am identificat clustere de funcționalitate suprapusă. Aceste clustere au devenit țintele de consolidare în faza următoare.

Faza 2 — token-uri de fundație

Înainte de a atinge vreo componentă, am stabilit token-urile de design care vor guverna întregul sistem. Token-urile sunt valorile atomice (culori, spațiere, tipografie, elevație, rază de colț, mișcare) pe care componentele le moștenesc.

Deciziile cheie de fundație au inclus:

• IBM Plex Sans ca font principal, ales pentru claritatea sa la dimensiuni mici, gama extinsă de greutăți și licența open-source care elimina fricțiunile de achiziție pentru clienții enterprise
• Grid de bază 8px oferind un ritm spațial consistent în toate layout-urile
• Sistem de layout pe 12 coloane cu breakpoint-uri responsive la 320px, 768px, 1024px și 1440px
• Token-uri funcționale de culoare organizate după scop în loc de paletă: color-action-primary, color-feedback-error, color-surface-elevated în loc de blue-500 sau red-400

Convenția funcțională de denumire a fost critică. Când o culoare e denumită după rolul său și nu după aspectul său, sistemul poate fi re-tematizat fără redenumirea token-urilor, iar designerii aleg culorile pe baza semnificației, nu a esteticii.

Faza 3 — arhitectura sistemului

Cu token-urile stabilite, am reconstruit biblioteca de componente de la zero. Arhitectura a urmat principii stricte:

• Componente cu responsabilitate unică: fiecare componentă face un singur lucru bine
• Compozabilitate peste variante: în loc de 180 stiluri de buton, o singură componentă de buton cu proprietăți compozabile (dimensiune, variantă, poziție iconiță, stare de încărcare)
• Flexibilitate bazată pe sloturi: componentele acceptă conținut prin sloturi definite în loc de template-uri rigide
• Completitudinea stărilor: fiecare componentă acoperă stările implicit, hover, activ, focus, dezactivat, încărcare, eroare și gol

Biblioteca reconstruită conținea 200+ componente (o reducere de 60% față de numărul original) cu 70% mai puține variante. Noua bibliotecă acoperea mai multe cazuri de utilizare decât cea veche, deoarece compozabilitatea expanda multiplicativ posibilitățile.

Faza 4 — documentație

Fiecare componentă a primit o pagină de documentație care acoperă:

• Scop: pentru ce e componenta și când să o folosești
• Anatomie: o diagramă etichetată a părților componentei
• Proprietăți: fiecare opțiune configurabilă cu valori implicite
• Stări: exemple vizuale ale fiecărei stări
• Recomandări și contraindicații: ghidaj concret cu exemple vizuale
• Accesibilitate: atribute ARIA necesare, comportament la tastatură și așteptări pentru screen reader
• Cod: fragmente de implementare pentru echipa de dezvoltare

Documentația a fost scrisă în limbaj simplu, evitând jargonul. Un designer junior care se alătură echipei ar trebui să poată înțelege și utiliza corect orice componentă în câteva minute.

Fundații de design în detaliu

Scara tipografică

Scara tipografică folosește un raport de 1,25, producând dimensiuni care creează o ierarhie clară fără salturi dramatice. Textul de corp e setat la 16px pentru citire confortabilă, cu o înălțime a liniei de 1,5 pentru blocuri de text și 1,25 pentru etichete de UI.

Sistemul de spațiere

Toată spațierea derivă din grid-ul de 8px: 4px (compact), 8px (strâns), 16px (implicit), 24px (confortabil), 32px (spațios), 48px (secțiune) și 64px (pagină). Designerii selectează din această scală în loc să inventeze valori, asigurând un ritm consistent pe fiecare ecran.

Sistemul de culori

Sistemul funcțional de token-uri de culoare include 48 de token-uri organizate în categorii: acțiune, feedback, suprafață, bordură, text și overlay. Fiecare token se mapează la valori specifice pentru tema luminoasă și întunecată, permițând comutarea temei fără modificări ale componentelor.

Rezultatul

Noul sistem a transformat nu doar consistența vizuală a produsului, ci și viteza și încrederea echipei. Timpul de predare de la design la dezvoltare a scăzut cu 40% deoarece dezvoltatorii puteau consulta o singură sursă de adevăr în loc să interpreteze mockup-uri inconsistente. Testarea QA a devenit predictibilă pentru că fiecare componentă se comporta conform specificațiilor documentate.

Cel mai important, clienții enterprise ai ResNet au început să experimenteze finisajul și profesionalismul pe care capabilitățile platformei le meritaseră întotdeauna. Sistemul de design a curățat interfața și a ridicat nivelul întregului produs.