Legenda instrumentelor

Există, în comunitatea de design, o tentație constantă de a face din instrumente subiecte de admirație individuală. "Folosesc cutare tool, e magic." "Cu Midjourney v7 am ajuns la nivelul ăsta." Conversațiile despre meserie alunecă, fără să-și dea seama participanții, în conversații despre brand-uri.

Atlasul ăsta refuză categoric abordarea aceea. Nu pentru că instrumentele nu contează — contează enorm. Ci pentru că ele nu sunt magice. Sunt utile sau inutile în funcție de rolul pe care îl ocupă într-un sistem mai mare. Iar rolul, nu instrumentul, e ce trebuie cartografiat.

Există un test simplu pentru a verifica dacă vorbim despre un instrument sau despre o modă: poți descrie rolul pe care îl ocupă în sistemul tău fără să folosești numele lui? Dacă da, e un instrument. Dacă nu, e o modă deghizată în instrument. Modele se schimbă; rolurile rămân. O legendă bună descrie rolurile.

De aceea, în acest capitol, fiecare instrument primește mai întâi o funcție — Cartograful, Atelierul, Drumul, Memoria, Subsolul, Schela — și abia apoi un nume comercial. Numele comerciale se vor schimba, în următorii cinci ani; unele vor dispărea. Funcțiile vor rămâne. Iar dacă citești atlasul ăsta în 2030 și două dintre numele comerciale nu mai există, înlocuiește-le cu echivalentul lor — funcția va fi încă valabilă.

Criteriile selecției

Cum am ajuns la cele șase, și nu la zece sau la trei? Nu prin întâmplare. Prin trei criterii pe care le aplicăm cu o disciplină aproape obositoare.

Primul criteriu: fiecare instrument trebuie să aibă un rol distinct, neînlocuibil. Dacă două instrumente fac același lucru, unul dintre ele trebuie să plece. Redundanța e o formă de zgomot, și zgomotul costă atenție. Un studio care folosește simultan Figma și Sketch, sau simultan Notion și Obsidian, plătește un impozit cognitiv ascuns: trebuie să-și amintească, de fiecare dată, în care dintre cele două aplicații a pus acel lucru.

Al doilea criteriu: fiecare instrument trebuie să fie ales pentru funcție, nu pentru modă. Acest criteriu pare evident, dar e cel mai des încălcat. În industria de design, există valuri de hype care ridică un instrument timp de șase luni, după care dispare. A construi un sistem pe vârful valului e o modalitate sigură de a-l reconstrui peste un an.

Al treilea criteriu: numărul total trebuie să rămână mic. Nu pentru că "less is more" — ci pentru că fiecare instrument adăugat aduce un cost de menținere, de actualizare, de integrare. Iar costurile astea cresc exponențial, nu liniar. Cinci instrumente care vorbesc bine între ele bat zece instrumente care nu vorbesc deloc.

Cartograful, în profunzime

Claude — sau orice asistent AI de calitate echivalentă — e instrumentul cel mai discutat și cel mai prost înțeles din această legendă. E discutat pentru că e nou. E prost înțeles pentru că oamenii încearcă să-l folosească fie ca enciclopedie, fie ca generator de conținut. Niciuna dintre cele două nu e rolul lui adevărat.

Rolul lui adevărat e partener de conversație. Cineva — sau ceva — cu care poți gândi cu voce tare, fără ca interlocutorul să se plictisească, să se simtă jignit sau să-și piardă răbdarea. La o oră dimineața, când ai un brief vag și nu vrei să trezești pe nimeni, conversația cu un Cartograf e diferența între a începe ziua confuz și a o începe cu o structură.

Iată cum îl folosim concret la RT Design Studio. Pentru structurarea unui brief: îi dăm textul brut al clientului și îi cerem să identifice ipotezele neexprimate, întrebările deschise, contradicțiile interne. În douăzeci de minute avem o hartă a problemei pe care, înainte, am fi construit-o în două ore de discuții.

Pentru copy bilingv: Moldova trăiește între română și engleză, iar uneori și rusă. Conversația cu un asistent care vorbește toate trei elimină frustrarea traducerilor stângace. Dar — și aici e disciplina — întotdeauna recitim, întotdeauna ajustăm, întotdeauna păstrăm vocea noastră. Asistentul propune. Designerul decide.

Pentru debug de cod: când un designer ajunge să atingă HTML/CSS/JavaScript, un asistent care îți explică de ce o eroare apare, în loc să te lase să cauți pe Stack Overflow două ore, e diferența între un proiect care avansează și unul care moare în confuzie tehnică.

Acum, ce nu poate face. Nu are gust. Îți va propune cinci variante, toate plauzibile, dar nu îți va spune care dintre ele e cea bună pentru contextul tău cultural specific, pentru clientul tău specific, pentru momentul ăsta. Ultimele cinci procente din orice livrabil — alegerea finală, ajustarea de nuanță, decizia despre ton — rămân umane. Și e bine să fie așa, pentru că aici se vede valoarea ta.

Nu poate să cunoască contextul real. Știe ce i-ai spus, plus ce a învățat în antrenament. Nu cunoaște cultura din Chișinău, nu știe că un anume client e sensibil pe un anume subiect, nu a auzit conversația de săptămâna trecută cu echipa. Lacuna asta e permanentă. Iar dacă ignori lacuna, vei produce muncă generică, recunoscibilă instant ca AI.

Atelierul, în profunzime

Figma e singurul instrument din această legendă pe care l-am avea și fără revoluția AI. E aici de mai bine de zece ani și a câștigat locul prin rezistență la modă — nu prin entuziasm. Pe parcursul deceniului, au apărut și au dispărut zece concurenți. Figma a rămas, pentru că a făcut un singur lucru bine: spațiul vizual partajat în care deciziile devin tangibile.

De ce nu l-a înlocuit niciun instrument generativ? Pentru că generarea de imagini și deciderea asupra unui design sunt activități fundamental diferite. Generarea propune. Decizia alege. Iar decizia cere un spațiu unde să poți pune două variante una lângă alta, să le ajustezi, să le combini, să te răzgândești. Ăsta e Figma. Niciun prompt nu înlocuiește acea suprafață.

Cum îl folosim la maxim. Auto-layout cu disciplină: orice element care ar putea repeta se construiește din capul locului cu auto-layout. Costul e cinci minute la început; câștigul e ore la fiecare modificare ulterioară. Designerii care încă desenează manual fiecare margine plătesc, fără să-și dea seama, un impozit zilnic.

Biblioteci de componente, dar cu zgârcenie: tentația e să faci componentă din tot. Greșeala. O componentă e bună doar dacă se va folosi în mai mult de trei locuri. Sub trei, costul de a o crea, întreține și documenta e mai mare decât câștigul. Studiourile care au sute de componente și nu le folosesc decât pe douăzeci au creat datorie tehnică, nu sistem.

Plugin-uri cu suspiciune: magazinul Figma e plin de plugin-uri care promit minuni. Cele mai multe sunt zgomot. Patru sau cinci bune — pentru export de assets, pentru iconițe, pentru placeholder data — sunt suficiente. Fiecare plugin nou trebuie justificat, nu adoptat din curiozitate.

Limita Figmei. Nu e bună pentru text lung. Nu e bună pentru documentație. Nu e bună ca singură sursă de adevăr a unui proiect. E un atelier, nu o casă. Ce se face aici trebuie, la final, să se mute altundeva — în cod, în print, în produs. Studiourile care încearcă să trăiască exclusiv în Figma se trezesc cu fișiere de zece mii de straturi, imposibil de menținut.

Drumul, în profunzime

Drumul e instrumentul de care ai nevoie ca să transformi un prototip într-un produs accesibil online. Funcția lui e mai importantă decât marca: e drumul de la prototip la produs vizibil în browser-ul clientului.

Înainte, asta funcționa așa: terminai mock-up-ul în Figma, îl exportai ca PDF, îl trimiteai dezvoltatorului, așteptai o săptămână, primeai înapoi un site care semăna 70% cu ce ai desenat, faceai revizii, mai aștepta o săptămână, livrai. Trei săptămâni între prototip și produs vizibil. Trei săptămâni în care clientul, pe drum, putea să-și piardă entuziasmul, să se răzgândească, să primească alt brief de la șeful lui.

Acum funcționează așa: termini prototipul în cod (cu Next.js, cu ajutorul Cartografului), faci push în GitHub, deploy automat în două minute, trimiți clientului un link. Clientul vede produsul în browser-ul lui, pe telefonul lui, în condiții reale. Diferența e profundă, nu doar tehnică.

Pentru un designer care nu e și developer, drumul ăsta părea inaccesibil. SSH, subdomenii, certificate SSL — un teritoriu cu vocabular intimidant. Platformele moderne de deploy (Vercel, Netlify, Railway, Cloudflare Pages și echivalentele lor) au făcut acel teritoriu navigabil. Nu trebuie să devii sysadmin. Trebuie doar să apeși un buton.

Limita: drumul nu trebuie să devină destinația. Faptul că poți deploy-a un site în două minute nu înseamnă că trebuie să o faci la fiecare schimbare. Disciplina rămâne — etape clare, versiuni numerotate, momente în care te oprești și revizuiești. Viteza e un cadou; folosit prost, e un drog.

Memoria, în profunzime

Git și GitHub sunt cele mai vechi instrumente din această legendă, și cele mai rar discutate de designeri. Dezvoltatorii știu ce sunt; designerii adesea le ignoră, considerându-le "chestii tehnice." Asta e o greșeală. Git nu e un instrument tehnic. E un instrument moral.

Ce face Git, în esență, e să-ți forțeze să justifici fiecare schimbare. Când faci commit, scrii un mesaj. Acel mesaj rămâne pentru totdeauna în istoria proiectului. Cinci ani mai târziu, cineva — poate tu — va citi acel mesaj și va înțelege de ce ai făcut acea schimbare. Sau nu va înțelege, dacă mesajul a fost "update" sau "fix."

Iar din această forțare a articulării vine o disciplină. Designerii care au învățat să scrie commit-uri serioase observă, după câteva luni, că gândesc altfel chiar înainte de commit. Își planifică schimbările în unități coerente. Își refuză singuri intervenții pripite, pentru că știu că, peste cinci minute, va trebui să le justifice. Git e, fără să spună asta, un coach de claritate mentală.

Pentru colaborare, e instrumentul care face posibilă lucrul în echipă fără ca cineva să suprascrie munca celuilalt. Branch-uri, pull request-uri, code review — vocabularul tehnic ascunde un mecanism social: nimic nu intră în proiect fără ca altcineva să se uite peste el. Această practică, importată de designeri din lumea developerilor, ridică standardul intern al studioului mai mult decât orice manifest de calitate.

Subsolul, în profunzime

Supabase e instrumentul care le permite designerilor să intre în lumea produsului fără să devină ingineri. E un compromis remarcabil: îți oferă un back-end real — bază de date, autentificare, fișiere — printr-o interfață suficient de prietenoasă încât să nu trebuiască să scrii SQL la trei dimineața.

Funcția lui în sistem: fundația. Tot ce e produs adevărat — ce trebuie să țină minte ceva între sesiuni, ce trebuie să recunoască utilizatori, ce trebuie să stocheze date — trece prin aici. Fără el, tot ce poți face e mock-up. Cu el, poți face produs.

De ce Supabase și nu Firebase, sau un back-end custom? Pentru că Supabase e construit pe PostgreSQL, o tehnologie matură, deschisă, care nu te închide într-un ecosistem proprietar. Dacă, peste cinci ani, vrei să muți totul altundeva, datele tale sunt portabile. Asta nu pare important acum. Va părea important atunci.

Limita: Supabase rămâne, în ciuda interfeței prietenoase, un instrument tehnic. Există un prag de complexitate dincolo de care un designer singur nu mai poate menține o aplicație. Acel prag vine repede — la primul moment în care ai nevoie de logică serioasă pe server, ai nevoie de un developer adevărat. Iar atunci, faptul că ai construit pe Supabase facilitează colaborarea cu el; nu o înlocuiește.

Schela, în profunzime

Next.js e cel mai discutabil instrument din lista asta. Nu pentru că e prost — e excelent. Ci pentru că nu orice proiect cere un framework de această complexitate. Iar regula noastră e: dacă proiectul tău nu cere Next.js, nu-l folosi pentru Next.js.

Când îl folosim. Pentru orice proiect care are mai mult de zece pagini, autentificare, conținut dinamic, sau intenția clară de a crește. Pentru aceste cazuri, Next.js elimină decizii triviale: cum să routez paginile, cum să randez serverside, cum să încarc imaginile, cum să gestionez stările de loading. Toate astea sunt rezolvate. Tu te ocupi de design și de logica reală.

Când nu îl folosim. Pentru o pagină de prezentare cu cinci secțiuni. Pentru un mock-up exploratoriu. Pentru un microsite de campanie cu o singură pagină. În aceste cazuri, HTML și CSS curat — eventual cu un strop de JavaScript — sunt mai onești. Next.js ar fi overkill, și overkill-ul are un cost: dependințe care îmbătrânesc, build-uri care durează, configurații care se învechesc.

Această disciplină — de a alege uneori să nu folosești instrumentul puternic — e una dintre cele mai grele. Pentru că ai investit în el, te simți obligat să-l folosești tot timpul. Capcana e clasică: cu un ciocan în mână, totul pare cui. Maturitatea profesională se vede în capacitatea de a lăsa ciocanul în trusă atunci când avem nevoie de o șurubelniță.

Cum vorbesc între ele

Un sistem nu e suma componentelor. E felul în care componentele se leagă. Iar legăturile dintre cele șase instrumente sunt, în multe privințe, mai importante decât instrumentele înseși.

Fluxul tipic la un proiect de o săptămână, ca să fie concret. Primim brief-ul de la client. Conversație cu Claude — structurăm brief-ul, identificăm întrebările deschise, scriem o propunere preliminară. Trimitem clientului. Dacă acceptă, trecem mai departe.

Deschidem Figma — schițăm trei direcții vizuale. Folosim biblioteca de componente RT, deja construită. În paralel, dacă brieful are nevoie de copy, ne întoarcem la Claude pentru variante de text. Variantele se importă în Figma, se aleg, se ajustează.

Aprobată direcția, începem să o construim în cod. Next.js ca schelă, conectat la Supabase dacă e nevoie de date dinamice. Git tot timpul, cu commit-uri serioase la fiecare etapă logică. Push pe GitHub.

De pe GitHub, deploy automat pe platforma de deploy. Clientul primește un link, vede prototipul live, dă feedback. Iterăm — dar acum iterația e: schimbare în Figma, schimbare în cod, commit, push, deploy. Trei minute între o decizie și clientul care o vede pe ecranul lui.

Ce e remarcabil aici nu e niciun instrument individual. E felul în care toate șase converg într-un flux fără frecare. Iar fluxul fără frecare e ce face diferența între un studio care livrează prototipuri și un studio care livrează produse.

Pentru cititorul care vrea exemple concrete, nu doar descrieri: pe cardots.net, una dintre platformele construite în studio, AI-ul extrage automat în jur de douăzeci și cinci de keywords per imagine în pipeline-ul de upload — un caz manual de etichetare care altădată cerea minute, devine o operațiune invizibilă în câteva sute de milisecunde. Pe abonament.design, fluxul editorial folosește AI pentru a genera variante de copy bilingv (română și engleză) pe care designerul le evaluează și le rafinează, nu le scrie de la zero. În niciunul dintre cazuri AI-ul nu „livrează singur" — dar în ambele scoate din ecuație partea repetitivă, lăsând loc pentru ce contează: judecata, gustul, decizia finală.

Acestea nu sunt anecdote. Sunt produse live, vizibile public, pe care le-am construit cap-coadă cu aceleași șase instrumente. Atlasul descrie metoda; produsele dovedesc că funcționează.

Anti-pattern-uri și tentația celui de-al șaptelea

Cel mai mare risc, pentru un studio care a învățat să folosească aceste șase instrumente, e tentația permanentă de a adăuga un al șaptelea. Apare un tool nou pe ProductHunt. O agenție din San Francisco scrie un post despre cum a transformat fluxul ei. Un freelancer pe care-l urmărim postează un video entuziast. Și brusc avem senzația că ratăm ceva.

De cele mai multe ori, nu ratăm nimic. Tool-ul nou face fie ce face deja unul dintre cele șase, fie ce nu cere proiectul nostru. Dar adăugarea lui ar însemna: încă o aplicație de actualizat, încă un cont de gestionat, încă o integrare de menținut, încă o curbă de învățare pentru fiecare coleg nou.

Ce funcționează ca filtru. Înainte de a adopta un instrument nou, întrebăm trei lucruri. Ce face acesta că nu fac instrumentele actuale? Dacă răspunsul e "e mai frumos" sau "e mai nou" sau "toți îl folosesc" — răspuns negativ. Ce vom înceta să folosim, ca să-l adoptăm pe acesta? Dacă răspunsul e "nimic", răspuns negativ. Cine se va ocupa de menținerea lui? Dacă răspunsul e "toți, deci nimeni" — răspuns negativ.

Anti-pattern-uri specifice de evitat. Dublarea Cartografului: a folosi simultan Claude, ChatGPT, Gemini, sperând că diversitatea aduce calitate. Aduce, în realitate, fragmentare. Alege unul, învață-l adânc.

Înlocuirea Atelierului cu un generator: a încerca să faci design direct prin prompt-uri, fără Figma. Funcționează pentru prototipuri rapide; eșuează la decizia matură. Generatorul îți dă ce a văzut deja. Atelierul te lasă să faci ce n-a văzut nimeni.

Înlocuirea Memoriei cu un Drive: a păstra versiunile proiectului în Google Drive sau Dropbox, în folder-e numerotate "v1", "v2_final", "v3_finalfinal". Funcționează pentru un proiect de două săptămâni. Cade pentru un proiect de doi ani. Git nu e opțional pentru cine vrea să fie serios.

Adăugarea unui al șaptelea fără să întrebi de ce: a adopta Notion, sau Linear, sau Airtable, pentru că "e standardul industriei". Standardele industriei sunt mediile. Ce face un studio bun nu e media — e ceea ce are sens pentru contextul lui.

Disciplina de a opri

La capătul acestui capitol, dacă a rămas o singură idee care merită să rămână, e aceasta: literația în instrumente nu e despre a alege bine. E despre a opri la timp.

Oricine poate adăuga un instrument nou. E ușor. E plăcut. E recompensat de algoritmii rețelelor sociale, care iubesc oamenii care încearcă lucruri noi. A nu adăuga e mai greu, pentru că e invizibil. Nu primești like-uri pentru ce nu ai instalat.

Studiourile mature pe care le admir au o caracteristică comună: pot să-și descrie sistemul de instrumente într-un paragraf scurt. Nu fac liste de cincisprezece SaaS-uri. Au șase, șapte, opt — și pot explica de ce fiecare e acolo. Iar atunci când apare ceva nou, primul lor reflex nu e "adăugăm", ci "de ce ne-ar folosi?"

Această reținere nu e conservatorism. E formă superioară de literație. E rezultatul unor ani de experimentare după care ai învățat care e costul real al complexității. Ai învățat că, peste un anumit prag, fiecare nou instrument adăugat scade productivitatea, în loc să o crească. Și ai învățat să-ți imaginezi nu doar cum vei folosi tool-ul în luna întâi, ci și cum vei trăi cu el în anul al cincilea.

Cele șase instrumente din această legendă vor fi parțial diferite în 2030. Unele dintre numele comerciale vor dispărea. Altele vor fi înlocuite cu echivalente mai bune. Funcțiile însă — Cartograful, Atelierul, Drumul, Memoria, Subsolul, Schela — vor rămâne. Pentru că ele nu sunt despre tehnologie. Sunt despre cum funcționează un sistem de lucru sănătos.

Iar când vei reciti acest atlas peste cinci ani, înlocuiește în minte numele care nu mai există cu echivalentele momentului. Funcțiile se țin. Restul e schimbător.