Arhitectura informației, fluxurile prin care trece un om și sistemul de componente pe care se construiește tot restul. Se face înaintea codului, pentru că acolo greșelile costă ore, nu săptămâni.
Când un produs digital nu merge, feedback-ul primit rareori sună a critică de design. Sună a „nu am găsit unde se face”, „nu am înțeles ce trebuie completat acolo”, „am crezut că am trimis și nu se trimisese”. Toate acestea sunt probleme de design, doar că nu de felul care se discută în ședințe.
Discuția din ședințe este despre culoare, despre cât de modern arată, despre dacă logo-ul e destul de mare. Sunt întrebări legitime, dar sunt ultimele, nu primele. Primele sunt: ce încearcă omul să facă, în câți pași reușește și ce îl oprește.
De aceea lucrăm în ordinea asta: întâi structura informației, apoi fluxurile, apoi componentele, abia la final rafinamentul vizual. Fiecare etapă se poate arăta și corecta înainte să existe o singură linie de cod.
Ce conținut există, cum se grupează, cum se numește fiecare lucru și cum se ajunge la el. Este stratul cel mai puțin spectaculos și cel care decide cel mai mult dacă oamenii găsesc ce caută.
Concret: inventarul complet a ce ai, gruparea testată pe oameni reali în loc de presupusă, denumiri luate din vocabularul clienților tăi și nu din cel intern al firmei, plus structura de navigare care rezultă din toate.
Drumul complet al unei acțiuni, de la intenție până la confirmare. Fiecare pas, fiecare decizie, fiecare loc unde se poate greși sau renunța.
Aici tratăm și ce se întâmplă când merge prost, partea pe care majoritatea proiectelor o descoperă în producție: câmp completat greșit, conexiune pierdută la jumătate, produs epuizat între două ecrane, revenire cu butonul înapoi al browserului.
Componentele din care se construiește tot, cu regulile de folosire. Butoane cu toate stările lor, câmpuri cu erorile lor, carduri, tabele, scara de spațiere, paleta cu contrastele verificate, tipografia cu scara ei.
Fără sistem, fiecare pagină nouă se inventează din nou. Cu sistem, o pagină nouă se asamblează în ore și arată din prima ca restul produsului, chiar dacă o face altcineva peste un an.
Stratul vizual, aplicat peste o structură deja validată. Ierarhie clară, spațiere consecventă, contrast verificat pe cifre și nu pe impresie, comportament definit pentru fiecare dimensiune de ecran.
Se lucrează cu conținut real, nu cu text de umplutură. Un aranjament care arată impecabil pe titluri de trei cuvinte se destramă la primul titlu de zece, iar titlurile reale sunt aproape întotdeauna mai lungi.
Un design se poate testa în stadiul de schiță, iar acolo o greșeală costă o după-amiază. Aceeași greșeală descoperită după lansare costă săptămâni și încrederea utilizatorilor.
| Metodă | La ce răspunde | Când o folosim |
|---|---|---|
| Discuții cu utilizatori | Ce încearcă să facă și ce îi stă în cale astăzi | La început, înainte de orice schiță |
| Sortare de carduri | Cum grupează ei informația, față de cum o grupăm noi | Când structura de navigare nu este evidentă |
| Test pe prototip | Duc la capăt sarcina principală fără ajutor? | Pe schițe interactive, înainte de cod |
| Verificare de accesibilitate | Contrast, navigare de la tastatură, cititor de ecran | La fiecare componentă, nu la final ca listă de bifat |
| Testare pe conținut real | Rezistă aranjamentul la titluri lungi și texte reale? | Înainte de predarea către implementare |
| Măsurare după lansare | Câți reușesc, în cât timp, unde renunță | Continuu, ca să știm ce mai are nevoie de lucru |
Testarea pe utilizatori sperie prin costul imaginat, dar în practică cinci persoane care încearcă să ducă la capăt o sarcină scot la iveală majoritatea problemelor mari. Al șaselea repetă ce au spus ceilalți. Nu este cercetare academică și nu pretinde să fie. Este cea mai ieftină metodă de a afla că lucrul evident pentru voi nu este evident pentru nimeni altcineva.
Cele mai multe probleme de accesibilitate se nasc în design, nu în cod: contrast insuficient ales pentru că arăta elegant pe ecranul designerului, informație transmisă doar prin culoare, zone de atins prea mici, formulare unde eticheta dispare când începi să scrii, indicatorul de focalizare scos pentru că strica estetica.
Toate acestea sunt gratuite dacă se decid în etapa de design și devin refacere dacă se descoperă după. Verificăm contrastul pe cifre pentru fiecare pereche de culori, definim starea de focalizare ca parte din sistem, ne asigurăm că nimic important nu se comunică exclusiv prin culoare și că fiecare flux poate fi parcurs fără mouse.
Rezultatul este un produs pe care îl pot folosi și oamenii cu vedere slabă, cu daltonism sau care navighează de la tastatură, ceea ce înseamnă în jur de unul din cinci vizitatori. Este și obligație legală în extindere, dar chiar și fără ea cifra aia ar fi suficientă.
Același sistem de design stă și în spatele unui site de prezentare, și al unui magazin online, și al unei aplicații, și al unui instrument intern pentru o companie. Se face o dată și se folosește peste tot, ceea ce este chiar motivul pentru care merită făcut ca sistem, nu ca serie de ecrane separate.
UX este cum funcționează: ce pași face omul, în ce ordine, ce înțelege la fiecare, unde se blochează. UI este cum arată: culori, tipografie, spațiere, componente. Un UI frumos peste un UX prost dă un produs care arată bine și frustrează, iar asta se vede în cifre înainte să se vadă în comentarii.
Se poate, și se face tot timpul. Rezultatul este că presupunerile echipei ajung direct în produs, iar dacă sunt greșite afli abia după lansare, când corectarea costă de zece ori mai mult. Cercetarea nu înseamnă neapărat luni de studiu. Cinci discuții cu utilizatori reali scot la iveală, în practică, majoritatea problemelor mari.
Este setul de componente și reguli din care se construiește tot: butoane, câmpuri, carduri, spațieri, culori, tipografie, plus când se folosește fiecare. Fără el, fiecare pagină nouă se inventează de la zero, apar șapte nuanțe de albastru și cinci feluri de buton, iar peste un an produsul arată a mai multe produse lipite.
Amândouă, și de obicei e mai bine așa. Un design predat ca imagine, fără cineva care să îl ducă în cod, se pierde la traducere: spațieri aproximate, stări nedefinite, comportament pe ecran mic inventat pe loc. Când construim și noi, sistemul de design ajunge în cod ca set de componente reale, nu ca fișier de referință.
Prin ce se măsoară: câți duc la capăt acțiunea principală, în cât timp, câți greșesc pe drum, câți renunță și unde. Frumusețea este o părere, iar părerile într-o ședință se decid după cine vorbește mai tare. Cifrele nu.
Ne uităm pe produsul sau site-ul existent și îți spunem concret unde se pierd oamenii și ce merită reparat primul.