modul 00 / ce este UX & procesul de design
UX vs UI: ce înseamnă de fapt
UX design (user experience) înseamnă proiectarea experienței pe care o are cineva folosind un produs. Nu e despre culori și fonturi — e despre dacă omul reușește să facă ce a venit să facă, fără frustrare.
diferența, în trei propoziții
| UX (experiență) | UI (interfață) |
|---|
| Întrebarea | Funcționează? Are sens? | Arată bine? E clar vizual? |
| Se ocupă de | Structură, fluxuri, logică, cercetare | Culoare, tipografie, spațiere, componente |
| Livrează | Fluxuri, wireframes, hărți, teste | Machete finale, sistem de design |
Analogia clasică: la o casă, UX e planul — câte camere, unde e bucătăria, cum circuli între ele. UI e finisajul — culorile pereților, mânerele, iluminatul. O casă frumoasă cu baia accesibilă doar prin dormitor are UI bun și UX prost.
confuzia cea mai frecventă
„UX design = să faci interfața frumoasă." Nu. Cea mai mare parte a muncii UX se întâmplă înainte să desenezi ceva: înțelegi utilizatorii, definești problema corectă, structurezi informația. Un ecran frumos care rezolvă problema greșită e muncă irosită — indiferent cât de bine arată.
ce face un designer, concret
- Cercetează — vorbește cu utilizatori, observă cum lucrează azi.
- Definește — formulează problema reală, nu simptomul raportat.
- Structurează — organizează informația și fluxurile.
- Desenează — wireframes, apoi machete și prototipuri.
- Testează — pune produsul în fața oamenilor și observă unde se blochează.
- Colaborează — cu dezvoltatori, product, business.
de ce contează pentru business
Un produs greu de folosit pierde utilizatori indiferent cât de bună e tehnologia din spate. Un formular de comandă cu doi pași în loc de șapte crește vânzările real. Argumentul UX nu e „e mai frumos" — e „mai mulți oameni reușesc să termine ce au început".
de reținut
UX = experiența (funcționează? are sens?); UI = interfața (arată bine? e clar?). Sunt complementare, dar UX vine primul: structura înainte de finisaj. Cea mai mare parte a muncii UX se face înainte de a desena — cercetare, definirea problemei, structurarea informației. Argumentul de business nu e estetica, ci rata de reușită a utilizatorilor.
modul 00 / ce este UX & procesul de design
procesul: cele cinci etape
Designul nu e inspirație — e un proces repetabil. Modelul cel mai folosit (design thinking) are cinci etape. Nu sunt liniare: te întorci constant la etapele anterioare.
cele cinci etape
| Etapă | Întrebarea | Rezultate tipice |
|---|
| 1. Empatizează | Cine sunt utilizatorii și ce li se întâmplă? | Interviuri, observație, hartă de empatie |
| 2. Definește | Care e problema reală de rezolvat? | Persona, declarație de problemă, user stories |
| 3. Ideează | Ce soluții posibile există? | Schițe rapide, brainstorming, fluxuri |
| 4. Prototipează | Cum ar arăta și funcționa? | Wireframes, machete, prototip clicabil |
| 5. Testează | Funcționează pentru oameni reali? | Teste de utilizabilitate, constatări, iterații |
divergență și convergență
Procesul alternează două moduri de gândire:
- Divergent — deschizi: explorezi multe posibilități, nu judeci încă (cercetare, ideație).
- Convergent — închizi: alegi, prioritizezi, elimini (definire, decizie).
Greșeala tipică a începătorilor: convergi prea devreme — te atașezi de prima idee și o rafinezi ore în șir, în loc să explorezi zece variante rapide întâi. Prima idee e rareori cea mai bună; e doar cea mai evidentă.
iterația nu e eșec
Dacă un test arată că designul tău nu funcționează, nu ai eșuat — ai economisit bani. Un defect descoperit în prototip costă minute de refăcut. Același defect descoperit după lansare costă săptămâni de dezvoltare, plus utilizatori pierduți. Ideea centrală a procesului: eșuează ieftin, devreme, pe hârtie.
fidelitate crescătoare
Lucrezi de la grosier la fin, ca să nu investești efort în lucruri care se vor schimba:
schiță pe hârtie → wireframe (gri, fără stil) →
machetă (culori, tipografie) → prototip clicabil → implementare
Regula: nu adăuga fidelitate până nu ai validat nivelul curent. Nu alege paleta de culori până nu știi ce ecrane există și în ce ordine.
de reținut
Cinci etape: empatizează → definește → ideează → prototipează → testează — nu liniar, ci iterativ. Alternezi divergență (explorezi larg) cu convergență (alegi), iar greșeala clasică e să converi prea devreme pe prima idee. Crești fidelitatea treptat, validând la fiecare nivel. Un test care „pică" e o economie, nu un eșec: eșuează ieftin, pe hârtie, nu scump, în producție.
modul 01 / cercetarea utilizatorilor
tipuri de cercetare & cum întrebi corect
Cercetarea răspunde la o întrebare simplă: ce fac și de ce se blochează oamenii? Fără ea, proiectezi pe baza propriilor presupuneri — iar tu nu ești utilizatorul.
calitativ vs cantitativ
| Calitativ | Cantitativ |
|---|
| Răspunde la | De ce se întâmplă | Cât / câți |
| Metode | Interviuri, observație, teste de utilizabilitate | Chestionare, analitice, teste A/B |
| Eșantion | Mic (5–8 oameni) | Mare (sute+) |
| Îți dă | Înțelegere, motive, context | Dovezi, dimensiunea problemei |
Se completează: analiticele îți arată că 60% abandonează la pasul de plată; interviurile îți spun de ce. Ai nevoie de ambele — numerele fără context duc la concluzii greșite.
cum întrebi: regulile interviului
| ❌ Nu întreba | ✅ Întreabă |
|---|
| „Ți-ar plăcea o funcție de X?" | „Povestește-mi ultima dată când ai avut nevoie să faci X." |
| „Ți se pare simplu, nu?" | „Cum ți s-a părut pasul acesta?" |
| „Cât de des ai folosi asta?" | „De câte ori ai făcut asta luna trecută?" |
| „Ce ai vrea să adăugăm?" | „Care e cea mai enervantă parte a procesului actual?" |
regula de aur a cercetării
Întreabă despre trecut și comportament, nu despre viitor și opinii. Oamenii sunt prost prezicători ai propriului comportament — spun sincer „aș folosi asta zilnic" și apoi n-o deschid niciodată. Dar își amintesc corect ce au făcut și unde s-au enervat. Comportamentul trecut e date; opinia despre viitor e ficțiune politicoasă.
capcane frecvente
- Întrebări care sugerează răspunsul („Nu-i așa că e mai clar acum?") — obții confirmare, nu adevăr.
- Vorbești tu prea mult — regula: utilizatorul vorbește 80% din timp. Tăcerea ta produce informație.
- Îți aperi designul — dacă explici cum „ar trebui" folosit, ai pierdut testul. Observi, nu instruiești.
- Întrebi doar oameni ca tine — colegii și prietenii nu sunt un eșantion.
- Cauți confirmare — mergi cu o ipoteză și auzi doar ce o susține.
câți oameni ai nevoie
Pentru cercetare calitativă, 5–8 participanți per grup de utilizatori descoperă majoritatea problemelor majore. Nu ai nevoie de sute — după al cincilea interviu, începi să auzi aceleași lucruri. Mai valoros e să vorbești cu tipurile potrivite de utilizatori decât cu mulți din același tip.
de reținut
Cercetarea calitativă spune „de ce", cea cantitativă spune „cât" — ai nevoie de ambele. Regula centrală a interviurilor: întreabă despre comportament trecut, nu despre intenții viitoare, pentru că oamenii își prezic prost propriul comportament. Lasă-i să vorbească 80% din timp, nu-ți apăra designul și nu întreba doar oameni ca tine. 5–8 participanți per tip de utilizator descoperă majoritatea problemelor.
modul 01 / cercetarea utilizatorilor
persona, hărți de empatie & puncte de durere
După cercetare ai zeci de pagini de notițe. Instrumentele de sinteză le transformă în ceva utilizabil de întreaga echipă.
persona — utilizatorul tipic, concret
O persona e un personaj fictiv dar bazat pe date reale, care reprezintă un grup de utilizatori. Rolul ei: să facă discuțiile concrete. „Ar înțelege Maria acest buton?" e o întrebare mai bună decât „ar înțelege utilizatorul?".
MARIA, 34 ani, contabilă, Chișinău
Context: lucrează cu 40+ facturi pe zi, mereu sub presiune
Scopuri: să închidă luna fără erori; să piardă mai puțin timp
Frustrări: trebuie să reintroducă manual aceleași date;
nu găsește rapid o factură veche
Tehnologie: confortabilă cu Excel, evită aplicațiile „moderne"
care ascund opțiunile în meniuri
persona bună vs persona inutilă
O persona inutilă conține detalii decorative: „îi place să facă drumeții, bea cappuccino". O persona utilă conține doar ce influențează deciziile de design: scopuri, frustrări, context de utilizare, nivel de familiaritate cu tehnologia. Dacă un detaliu nu schimbă nicio decizie, scoate-l.
harta de empatie
Organizează observațiile despre o persoană în patru cadrane:
| Cadran | Conține |
|---|
| Spune | Citate directe din interviu |
| Gândește | Ce crede dar nu spune (deduci) |
| Face | Acțiuni observate |
| Simte | Emoții: frustrare, nesiguranță, grabă |
Cel mai valoros lucru pe care îl scoate la iveală: diferența dintre ce spun și ce fac oamenii. Cineva spune „e simplu", dar îl vezi ezitând 20 de secunde la fiecare pas. Acolo e problema reală.
punctele de durere
Un punct de durere e un obstacol concret. Categoriile clasice:
- De utilizare — nu găsește butonul, nu înțelege eticheta.
- De proces — prea mulți pași, repetare inutilă.
- Financiar — costuri neclare, surprize la final.
- De suport — se blochează și nu are unde cere ajutor.
Punctele de durere sunt materia primă a designului: fiecare devine o oportunitate concretă de îmbunătățire, prioritizabilă după frecvență și gravitate.
de reținut
Persona transformă „utilizatorul" abstract într-o persoană concretă cu scopuri și frustrări — dar conține doar detalii care schimbă decizii de design. Harta de empatie (spune/gândește/face/simte) scoate la iveală cel mai util lucru: diferența dintre ce declară și ce fac oamenii. Iar punctele de durere identificate devin lista ta de probleme de rezolvat, prioritizată după frecvență și gravitate.
modul 02 / definirea problemei
declarația de problemă & user stories
Etapa de definire e cea mai subestimată — și cea care decide dacă restul muncii are sens. O problemă prost formulată produce o soluție bună la întrebarea greșită.
declarația de problemă
Formulă simplă care ține echipa concentrată:
[Persona] are nevoie de [o modalitate de a face X]
pentru că [motiv],
ceea ce știm din [dovada din cercetare].
Maria, contabilă sub presiune, are nevoie de o modalitate
de a găsi rapid o factură veche, pentru că pierde
~15 minute pe zi căutând manual —
observat la 6 din 8 participanți la interviuri.
ce face o declarație bună
- Descrie problema, nu soluția. „Are nevoie de un buton de căutare" e o soluție deghizată; „are nevoie să găsească rapid o factură" e problema.
- E ancorată în dovezi, nu în presupuneri.
- E suficient de îngustă ca să poți lucra la ea, dar destul de largă ca să permită mai multe soluții.
capcana soluției deghizate
Când cineva spune „ne trebuie un chatbot", asta e o soluție, nu o problemă. Întreabă: ce problemă ar rezolva? Poate răspunsul e „oamenii nu găsesc informația în ajutor" — iar soluția potrivită e o pagină de ajutor mai bună, nu un chatbot. Formulează problema, apoi caută soluții; nu invers.
user stories
Descriu o nevoie din perspectiva utilizatorului, în format standard:
Ca [rol], vreau [să fac ceva],
pentru ca [beneficiu].
Ca și contabil, vreau să caut facturi după numele clientului,
pentru ca să nu mai deschid fiecare dosar pe rând.
Beneficiul („pentru ca") e partea cea mai importantă și cea mai des omisă — el explică de ce contează și permite echipei să găsească soluții alternative mai bune.
criterii de acceptare
Fiecare user story are nevoie de o definiție clară a lui „gata":
✔ Căutarea returnează rezultate în sub 1 secundă
✔ Se poate căuta după nume client, număr sau dată
✔ Dacă nu există rezultate, se afișează un mesaj clar
cu sugestii, nu o listă goală
de reținut
O declarație de problemă bună descrie problema (nu soluția), e ancorată în dovezi din cercetare și lasă loc mai multor soluții. Fii atent la soluțiile deghizate în cerințe („ne trebuie un chatbot") — întreabă mereu ce problemă ar rezolva. User stories exprimă nevoia din perspectiva utilizatorului, iar partea „pentru ca" (beneficiul) e cea mai valoroasă: ea deschide ușa soluțiilor mai bune.
modul 02 / definirea problemei
harta parcursului & prioritizarea
harta parcursului (journey map)
Un journey map arată pas cu pas ce face utilizatorul ca să-și atingă scopul — împreună cu ce simte la fiecare pas. Îi scoate la iveală momentele de frustrare.
Scop: Maria vrea să găsească factura clientului X din martie
Pas | Ce simte | Oportunitate
─────────────────┼──────────────┼──────────────────
Deschide aplicația| neutru |
Caută meniul | ușor confuz | etichete mai clare
Filtrează pe lună | frustrare 😖 | căutare după client
Deschide 8 dosare | oboseală | previzualizare în listă
Găsește factura | ușurare |
Valoarea hărții: face vizibil unde se pierde timpul și energia. Coloana „oportunitate" transformă fiecare frustrare într-o idee concretă de design.
tipuri de hărți utile
| Hartă | Arată |
|---|
| Journey map | Parcursul unui utilizator spre un scop, cu emoții |
| User flow | Pașii și deciziile într-un sistem (schemă logică) |
| Service blueprint | Ce se întâmplă și „în spatele scenei" (procese, oameni) |
prioritizarea: nu poți rezolva tot
Vei avea mai multe probleme decât timp. Prioritizezi după impact (câți utilizatori, cât de grav) și efort (cât costă de rezolvat):
| Efort mic | Efort mare |
|---|
| Impact mare | ✅ Fă imediat | Planifică serios |
| Impact mic | Când ai timp | ❌ Evită |
O altă unealtă utilă e MoSCoW: Must have (fără asta produsul nu funcționează), Should have (important dar nu blocant), Could have (bonus), Won't have (explicit exclus acum).
valoarea lui „Won't have"
Partea cea mai utilă a prioritizării e ce decizi să NU faci, scris explicit. Fără asta, orice idee bună rămâne suspendată „poate mai târziu", iar echipa lucrează la zece lucruri pe jumătate. O listă clară de excluderi e o decizie de design, nu un eșec.
de reținut
Journey map face vizibil unde se pierde timpul și energia utilizatorului, transformând fiecare frustrare într-o oportunitate concretă. Pentru că nu poți rezolva tot, prioritizezi după impact vs efort (sau MoSCoW) — iar cea mai valoroasă parte e lista explicită de lucruri pe care nu le faci acum. Fără ea, echipa lucrează la zece lucruri pe jumătate.
modul 03 / arhitectura informației & fluxuri
organizarea conținutului & etichetarea
Arhitectura informației înseamnă cum e organizat și denumit conținutul. E invizibilă când e bună și insuportabilă când e proastă — majoritatea frustrărilor de tip „nu găsesc nimic pe site-ul ăsta" vin de aici, nu din design vizual.
principii de organizare
| Structură | Potrivită pentru |
|---|
| Ierarhică | Majoritatea site-urilor: categorii → subcategorii |
| Secvențială | Procese pas cu pas (finalizare comandă, formulare lungi) |
| Matriceală | Conținut explorabil în mai multe feluri (filtre multiple) |
gruparea: după mintea utilizatorului, nu a ta
Cea mai frecventă greșeală: organizarea conținutului după structura internă a organizației. Un site care are meniul „Departamentul Comercial / Departamentul Tehnic / Relații Publice" e organizat pentru angajați, nu pentru vizitatori — care vor „Produse", „Suport", „Contact".
card sorting — cum afli gruparea corectă
Scrii fiecare element de conținut pe un card și ceri utilizatorilor să le grupeze cum au sens pentru ei și să denumească grupurile. Faci asta cu 8–10 oameni și vezi tiparele. E o metodă simplă, ieftină și surprinzător de eficientă — descoperi că oamenii grupează lucrurile complet altfel decât ai presupus.
etichetarea: cuvintele contează enorm
- Folosește limbajul utilizatorilor, nu jargonul intern. „Facturi" nu „Documente fiscale emise".
- Fii specific. „Resurse", „Soluții", „Diverse" nu spun nimic — sunt cele mai proaste etichete posibile.
- Fii consecvent. Dacă e „Coș" într-un loc, nu e „Cărucior" în altul.
- Verbe pentru acțiuni, substantive pentru locuri. Butonul zice „Trimite comanda", secțiunea se numește „Comenzi".
navigarea
| Tip | Rol |
|---|
| Globală | Meniul principal — prezent peste tot, maximum ~7 elemente |
| Locală | În interiorul unei secțiuni |
| Contextuală | Linkuri în conținut, „vezi și" |
| Firimituri (breadcrumbs) | Unde sunt și cum urc înapoi |
| Căutare | Pentru cei care știu exact ce vor |
Utilizatorul trebuie să poată răspunde oricând la trei întrebări: Unde sunt? Ce pot face aici? Unde pot merge mai departe? Dacă un ecran nu răspunde clar la ele, ai o problemă de arhitectură.
de reținut
Arhitectura informației decide dacă oamenii găsesc ce caută — și e cauza majorității frustrărilor de tip „nu găsesc nimic". Organizează după mintea utilizatorului, nu după structura organizației (verifică prin card sorting). Etichetele sunt critice: limbajul utilizatorului, specifice, consecvente. Testul oricărui ecran: răspunde clar la „unde sunt, ce pot face, unde pot merge"?
modul 03 / arhitectura informației & fluxuri
fluxuri de utilizare (user flows)
Un user flow e schema pașilor și deciziilor prin care trece cineva ca să-și atingă scopul. Îl desenezi înainte de a proiecta ecrane — altfel proiectezi ecrane frumoase care nu se leagă.
anatomia unui flux
Scop: utilizatorul cumpără un produs
[Pagina produs]
↓ apasă „Adaugă în coș"
[Coș]
↓ apasă „Finalizează"
◇ e autentificat?
├─ DA → [Livrare] → [Plată] → [Confirmare]
└─ NU → [Autentificare / Continuă ca invitat] → …
- Dreptunghi = ecran/pagină
- Romb = decizie (întrebare cu răspuns da/nu)
- Săgeată = acțiunea care duce mai departe
ce descoperi desenând fluxul
- Pași inutili — „chiar trebuie să se autentifice ca să vadă prețul?"
- Fundături — ecrane din care nu ai unde merge mai departe.
- Stări neacoperite — ce se întâmplă dacă plata eșuează? dacă produsul s-a epuizat între timp?
- Bucle — utilizatorul e trimis înapoi la un pas prin care deja a trecut.
stările uitate
Designerii începători proiectează doar „calea fericită" — totul merge bine. Dar produsele reale trăiesc în celelalte stări. Pentru fiecare ecran, întreabă-te:
- Gol — nu există încă date (prima utilizare). Ce vede omul? „Lista e goală" e o ocazie ratată: aici explici ce poate face.
- În încărcare — cât timp așteaptă și ce vede?
- Eroare — ce s-a întâmplat, de ce, și ce poate face în continuare.
- Parțial — date incomplete, unele câmpuri lipsă.
- Prea mult — 5000 de rezultate, nume foarte lungi, text care nu încape.
reducerea fricțiunii
- Elimină pași — fiecare pas în plus pierde utilizatori. Ai nevoie chiar de toate câmpurile alea?
- Amână ce poate fi amânat — lasă-l să cumpere ca invitat; ceri contul după.
- Completează automat ce știi deja (adresa din profil, orașul din cod poștal).
- Arată progresul în procese lungi — „pasul 2 din 3" reduce abandonul.
- Permite întoarcerea fără a pierde datele introduse.
de reținut
User flow-ul se desenează înainte de ecrane — altfel obții ecrane frumoase care nu se leagă. El scoate la iveală pașii inutili, fundăturile și buclele. Cel mai important: te obligă să acoperi stările reale, nu doar „calea fericită" — gol, în încărcare, eroare, parțial, prea mult. Iar regula de aur a fluxurilor: fiecare pas în plus pierde utilizatori, deci amână sau elimină tot ce poți.
modul 04 / wireframes & prototipare
wireframes: structura înaintea stilului
Un wireframe e schița structurii unui ecran: ce elemente există, cât de mari sunt, unde stau — fără culori, fonturi finale sau imagini reale. Intenționat urât, ca să te concentrezi pe ce contează.
de ce fără stil
motivul real al wireframe-urilor gri
Dacă arăți un ecran finisat, feedback-ul va fi despre culori și fonturi. Dacă arăți un wireframe gri, feedback-ul va fi despre structură și priorități — exact ce ai nevoie în acest stadiu. Lipsa stilului nu e lene, e o unealtă de direcționare a conversației. În plus, e mult mai ușor să arunci o schiță de 5 minute decât o machetă de 3 ore — ceea ce te face mai deschis la schimbare.
fluxul de lucru
| Nivel | Cu ce | Testezi |
|---|
| Schițe pe hârtie | Creion, 5 minute/ecran | Idei, variante multiple |
| Wireframe digital | Figma, gri | Structură, ierarhie, conținut |
| Machetă (mockup) | Culori, tipografie reale | Aspect vizual, ton, brand |
| Prototip | Ecrane legate, clicabile | Fluxul, utilizabilitatea |
regula schițelor rapide
Înainte de a deschide Figma, desenează 8 variante de aceeași pagină, câte una pe minut. Nu vor fi bune — asta e ideea. Scopul e să depășești soluția evidentă. Apoi alegi 2–3 direcții promițătoare și le duci în digital.
ce pui într-un wireframe
- Conținut real sau realist — nu „Lorem ipsum". Titlurile reale sunt mai lungi decât crezi și schimbă tot layout-ul.
- Ierarhia clară — ce e cel mai important trebuie să fie evident, chiar și în gri.
- Toate elementele — inclusiv mesajele de eroare, stările goale, butoanele secundare.
- Dimensiuni aproximative reale — un buton nu e cât un titlu.
capcana Lorem ipsum
Textul fals face orice design să arate bine — pentru că nu spune nimic. Cu conținut real descoperi că titlul are 3 rânduri, că numele produsului nu încape, că butonul „Confirmă și trimite comanda" e de două ori mai lat decât ai desenat. Conținutul e design, nu ceva turnat în design la final.
de reținut
Wireframe = structura fără stil, intenționat gri — pentru că feedback-ul urmează forma pe care i-o dai: ecran finisat → comentarii despre culori; wireframe → comentarii despre structură. Începe cu multe schițe rapide pe hârtie ca să depășești prima idee. Și folosește conținut real, nu Lorem ipsum: textul fals ascunde exact problemele pe care wireframe-ul ar trebui să le dezvăluie.
modul 04 / wireframes & prototipare
prototipuri & lucrul eficient în Figma
Un prototip leagă ecranele între ele astfel încât cineva să poată „folosi" designul înainte de a fi construit. E singurul mod de a testa un flux înainte să existe cod.
nivelurile de prototip
| Fidelitate | Ce e | Bun pentru |
|---|
| Joasă | Wireframes legate, tranziții simple | Validarea fluxului devreme |
| Înaltă | Machete finisate, interacțiuni, animații | Teste de utilizabilitate realiste, prezentări |
Regula: fidelitatea potrivită întrebării. Dacă vrei să afli „se descurcă oamenii cu fluxul?", un prototip gri e suficient — și te scutește de comentarii despre culori. Dacă vrei să afli „inspiră încredere?", ai nevoie de fidelitate înaltă.
ce prototipezi
- Un flux, nu tot produsul — traseul de la intenție la rezultat (ex: de la căutare la comandă plasată).
- Punctele de decizie — unde utilizatorul poate alege greșit.
- Stările critice — eroare, gol, succes.
lucrul eficient în Figma
| Unealtă | De ce contează |
|---|
| Frames | Ecranele propriu-zise; nu desena „liber" pe pânză |
| Auto Layout | Elementele se rearanjează singure când conținutul se schimbă — indispensabil |
| Componente | Un buton definit o dată, folosit peste tot; îl schimbi într-un loc |
| Variante | Stările unei componente (normal, hover, dezactivat) grupate |
| Stiluri / variabile | Culori și tipografie definite central |
| Constrângeri | Cum se comportă elementele la redimensionare |
de ce Auto Layout schimbă totul
Fără el, la fiecare modificare de text muți manual zeci de elemente. Cu el, machetele se comportă ca interfețele reale: se întind, se strâng, respectă spațierea. Bonus important: gândirea în Auto Layout te apropie de cum funcționează codul (flexbox), deci designurile tale devin mai ușor de implementat — și vorbești aceeași limbă cu dezvoltatorii.
igiena fișierului
- Denumește straturile — „Frame 247" nu ajută pe nimeni, nici pe tine peste o lună.
- Organizează pe pagini — cercetare, wireframes, machete, componente, arhivă.
- Nu duplica ce poate fi componentă.
- Păstrează explorările într-o pagină separată, nu le șterge — arată procesul și explică deciziile.
de reținut
Un prototip îți permite să testezi un flux înainte să existe cod — alege fidelitatea potrivită întrebării (joasă pentru flux, înaltă pentru încredere și percepție). Prototipezi un flux, nu tot produsul, incluzând stările critice. În Figma, Auto Layout și componentele sunt cele care contează cel mai mult: fac machetele să se comporte ca interfețe reale și te apropie de modul în care gândesc dezvoltatorii.
modul 05 / principii de design vizual
ierarhie vizuală & principiile Gestalt
Când cineva deschide un ecran, îl scanează în câteva sute de milisecunde și decide unde să se uite. Ierarhia vizuală e ceea ce ghidează acea privire. Fără ea, totul strigă la fel de tare — și utilizatorul nu aude nimic.
uneltele ierarhiei
| Unealtă | Cum creează importanță |
|---|
| Mărime | Mai mare = mai important (cea mai puternică) |
| Greutate | Îngroșat iese în față |
| Culoare & contrast | Contrastul ridicat atrage privirea prima |
| Spațiu | Ce e izolat pare important |
| Poziție | Sus-stânga se citește primul (în alfabete latine) |
regula celor trei niveluri
Pe orice ecran ar trebui să existe clar: ce e primul lucru pe care vrei să-l vadă, ce e al doilea și ce e restul. Dacă nu poți răspunde, ecranul nu are ierarhie. Test rapid: îngustează ochii până imaginea devine neclară — ce rămâne vizibil e ierarhia ta reală.
principiile Gestalt
Creierul grupează automat elementele vizuale după reguli previzibile. Le folosești ca să comunici relații fără a scrie explicații:
| Principiu | Creierul percepe | Aplicație |
|---|
| Proximitate | Ce e aproape e legat | Eticheta lângă câmpul ei, nu la distanță egală de două |
| Similaritate | Ce arată la fel face la fel | Toate butoanele principale identice |
| Închidere | Completează formele incomplete | Un card sugerat prin fundal, fără chenar |
| Continuitate | Urmărește liniile și alinierile | Elemente aliniate se citesc ca un grup |
| Figură/fond | Separă obiectul de fundal | Ferestre modale peste un fundal întunecat |
Proximitatea e cea mai puternică și cea mai des încălcată. Într-un formular, dacă eticheta e la distanță egală de câmpul de deasupra și de cel de dedesubt, utilizatorul nu știe cărui câmp îi aparține. Regula: spațiu mic în interiorul grupului, spațiu mare între grupuri.
de reținut
Ierarhia vizuală ghidează privirea prin mărime, greutate, contrast, spațiu și poziție — fiecare ecran trebuie să aibă clar un „primul lucru", „al doilea" și „restul". Principiile Gestalt îți permit să comunici relații fără cuvinte, iar cel mai important e proximitatea: spațiu mic în interiorul unui grup, spațiu mare între grupuri. Majoritatea formularelor confuze încalcă exact această regulă.
modul 05 / principii de design vizual
spațiere, aliniere & grile
spațiul alb nu e spațiu gol
Începătorii încearcă să umple fiecare centimetru. Spațiul negativ e un element activ de design: creează grupuri, dă respiro, semnalează importanță. Un ecran aerisit pare mai simplu și mai scump — chiar dacă are același conținut.
sistemul de spațiere
Nu alege distanțe la ochi. Folosește o scară bazată pe o unitate de bază (tipic 8px):
4 · 8 · 12 · 16 · 24 · 32 · 48 · 64 · 96
- Toate distanțele vin din această scară — nimic „17px pentru că arăta bine".
- Rezultatul e consecvență automată: ecranele făcute în zile diferite se potrivesc.
- Ușurează munca dezvoltatorilor: valorile devin variabile, nu numere magice.
alinierea
- Aliniază tot la ceva. Fiecare element trebuie să împartă o margine cu altul. Alinierile aleatorii sunt principala cauză a senzației de „neîngrijit".
- Preferă alinierea la stânga pentru text lung — ochiul găsește ușor începutul rândului. Textul centrat e greu de citit pe mai multe rânduri.
- Puține axe de aliniere — cu cât mai puține, cu atât mai ordonat.
testul rapid al ordinii
Trage linii imaginare verticale prin ecran. Dacă elementele nu cad pe câteva axe clare, ci fiecare începe din altă parte, ecranul va părea dezordonat — chiar dacă fiecare element în sine arată bine. Ordinea percepută vine din aliniere, nu din frumusețea pieselor.
grile & layout
| Element | Rol |
|---|
| Coloane | Structura orizontală (tipic 12 pe desktop, 4 pe mobil) |
| Șanțuri (gutters) | Spațiul dintre coloane |
| Margini | Spațiul de la marginea ecranului |
| Lățime maximă | Limita conținutului pe ecrane late |
Grila de 12 coloane e populară pentru că se împarte ușor: în 2 (6+6), în 3 (4+4+4), în 4 (3+3+3+3). Îți dă flexibilitate păstrând ordinea.
design responsiv — regula de bază
- Începe cu mobilul. Ecranul mic te forțează să prioritizezi; extinderea spre desktop e ușoară. Invers e mult mai greu.
- Nu doar micșora — reorganizează: meniul devine altfel, coloanele se suprapun, tabelele devin liste.
- Punctele de rupere (breakpoints) se aleg unde se strică designul, nu după dimensiunile telefoanelor la modă.
- Lungimea rândului de text: 45–75 de caractere pentru lizibilitate optimă, indiferent de lățimea ecranului.
de reținut
Spațiul alb e element activ, nu loc irosit — folosește o scară de spațiere (bazată pe 8px) în loc de valori alese la ochi, ca să obții consecvență automată. Alinierea e principala sursă a senzației de ordine: fiecare element trebuie să cadă pe o axă comună. Grila (12 coloane) dă structură, iar în responsiv începi cu mobilul și alegi punctele de rupere unde se strică designul, nu după modele de telefoane.
modul 06 / tipografie & culoare
tipografie
Majoritatea unei interfețe e text. Tipografia decide dacă produsul se citește ușor și ce personalitate are — e cea mai influentă decizie vizuală pe care o iei.
alegerea fonturilor
- Maximum două familii — una pentru titluri (poate avea personalitate), una pentru text (trebuie să fie neutră și lizibilă). Un singur font bine folosit e adesea suficient.
- Verifică diacriticele. Pentru română ai nevoie de ă, â, î, ș, ț. Multe fonturi frumoase nu au ș și ț corecte (cu virgulă dedesubt, nu cu sedilă) — sau le înlocuiesc cu glife din alt font, ceea ce se vede imediat.
- Familii cu multe greutăți îți dau flexibilitate în ierarhie fără a schimba fontul.
- Testează la dimensiuni mici — un font poate arăta superb la 48px și ilizibil la 14px.
scara tipografică
Ca și la spațiere, nu alege dimensiuni la întâmplare. Definește o scară:
12 · 14 · 16 · 20 · 24 · 32 · 40 · 56
Fiecare nivel are un rol clar (text mic, corp, subtitlu, titlu…). Cu o scară, ierarhia devine consecventă automat, iar dezvoltatorii primesc valori clare.
regulile lizibilității
| Element | Regulă practică |
|---|
| Dimensiune corp | Minimum 16px pe web (mai mic obosește) |
| Înălțimea rândului | 1,4–1,6 pentru paragrafe; mai strâns pentru titluri mari |
| Lungimea rândului | 45–75 caractere; peste, ochiul pierde rândul |
| Contrast | Minimum 4,5:1 pentru text normal (vezi modulul 8) |
| Aliniere | La stânga pentru text lung; evită justified pe web |
greșeli frecvente
- Text gri deschis pe fundal alb — arată „elegant" în machetă, e ilizibil pe un laptop la lumină.
- Prea multe dimensiuni — 11 mărimi diferite pe un ecran înseamnă că n-ai o scară.
- Majuscule pentru paragrafe — TEXTUL SCRIS TOT CU MAJUSCULE SE CITEȘTE MULT MAI GREU, pentru că dispare conturul cuvintelor. E acceptabil doar pentru etichete foarte scurte.
- Înălțime de rând prea mică — rândurile se lipesc și textul devine un bloc compact.
de reținut
Maximum două familii de fonturi, cu diacritice românești corecte (ș și ț cu virgulă — verifică mereu). Folosește o scară tipografică în loc de dimensiuni alese la ochi. Regulile de lizibilitate care contează cel mai mult: minimum 16px pentru corp, înălțime de rând 1,4–1,6, 45–75 de caractere pe rând și contrast suficient. Textul gri-deschis „elegant" din machetă e ilizibil în viața reală.
modul 06 / tipografie & culoare
culoare
Culoarea comunică înainte de cuvinte: atrage atenția, semnalează stări, transmite personalitate. Dar folosită prost, produce haos și probleme de accesibilitate.
rolurile culorilor într-o interfață
| Rol | Folosire |
|---|
| Primară | Acțiunea principală, identitatea produsului |
| Neutre | Fundaluri, text, chenare — 90% din interfață |
| Semantice | Succes (verde), eroare (roșu), avertisment, informație |
| Accent | Evidențieri rare, elemente speciale |
regula 60-30-10
Un punct de plecare simplu pentru echilibru: 60% culoare dominantă (de obicei neutră, fundalul), 30% secundară, 10% accent. Majoritatea interfețelor bune sunt preponderent neutre, cu culoare folosită rar și intenționat. Când totul e colorat, nimic nu iese în evidență — inclusiv butonul pe care vrei să-l apese.
construirea paletei
- Alege o culoare primară potrivită domeniului și brandului.
- Generează o scară de nuanțe (de la foarte deschis la foarte închis) — nu doar o singură valoare.
- Definește o scară de neutre (gri-uri) — vei folosi cel mai mult aceste valori.
- Adaugă culorile semantice (succes, eroare, avertisment).
- Verifică contrastul fiecărei combinații text/fundal.
capcane importante
- Culoarea singură nu poate purta informație. Aproximativ 1 din 12 bărbați are o formă de daltonism; iar un chenar roșu e invizibil pentru ei. Adaugă mereu un al doilea semnal: pictogramă, text, formă.
- Verde/roșu e exact combinația cea mai problematică pentru daltonism — nu te baza doar pe ea pentru „bine/rău".
- Contrast insuficient — culorile pastelate frumoase în machetă pică testele de accesibilitate.
- Sensuri culturale — culorile nu au aceleași conotații peste tot; nu presupune universalitate.
temă întunecată
Nu e o simplă inversare a culorilor. Reguli practice: evită negrul pur (#000) pentru fundal — folosește un gri foarte închis, mai odihnitor; evită albul pur pentru text; culorile saturate „vibrează" pe fundal închis, deci scad-le puțin saturația; și verifică din nou contrastul, pentru că se comportă diferit.
de reținut
Interfețele bune sunt preponderent neutre, cu culoare folosită rar și intenționat (60-30-10) — când totul e colorat, nimic nu iese în evidență. Construiește scări de nuanțe, nu culori izolate, și verifică contrastul fiecărei combinații. Regula critică de accesibilitate: culoarea singură nu poate purta informație — adaugă mereu un al doilea semnal (pictogramă, text, formă), mai ales pentru combinația verde/roșu.
modul 07 / sisteme de design & componente
gândirea în componente & stări
Când proiectezi ecran cu ecran, obții inevitabil inconsecvență: trei stiluri de buton, patru dimensiuni de card, cinci gri-uri aproape identice. Soluția e să gândești în componente refolosibile, nu în ecrane izolate.
ce e o componentă
O piesă de interfață definită o singură dată și folosită peste tot: buton, câmp de formular, card, fereastră modală, notificare. O modifici într-un loc și se schimbă pretutindeni.
stările — partea cea mai des uitată
O componentă nu are o singură înfățișare. Un buton are minimum:
| Stare | Când apare |
|---|
| Normal | Starea de bază |
| Hover | Cursorul deasupra (doar pe desktop) |
| Focus | Selectat cu tastatura — obligatoriu vizibil |
| Apăsat | În timpul clicului |
| Dezactivat | Indisponibil — și ideal, cu explicație de ce |
| În încărcare | Acțiunea e în curs |
starea de focus nu se șterge niciodată
Mulți designeri elimină conturul de focus pentru că „strică designul". Rezultatul: aplicația devine imposibil de folosit cu tastatura — pentru cine nu poate folosi mausul, pentru utilizatorii avansați, pentru cititoarele de ecran. Dacă nu-ți place conturul implicit, proiectează unul mai frumos. Nu-l elimina.
anatomia unei componente bine făcute
- Variante — primar, secundar, text; mărimi mic/mediu/mare.
- Toate stările definite pentru fiecare variantă.
- Comportament la conținut lung — ce se întâmplă cu un text de trei rânduri?
- Reguli de folosire — când folosești butonul primar și când nu.
consecvența e o funcție, nu o estetică
Când toate butoanele principale arată la fel, utilizatorul învață o singură dată ce înseamnă acel aspect și apoi îl recunoaște instant peste tot. Inconsecvența îl obligă să reînvețe la fiecare ecran — un cost cognitiv invizibil dar real.
de reținut
Gândește în componente refolosibile, nu în ecrane izolate — altfel ajungi cu trei stiluri de buton și cinci gri-uri aproape identice. Partea cel mai des uitată sunt stările: normal, hover, focus, apăsat, dezactivat, în încărcare. Nu elimina niciodată indicatorul de focus — proiectează unul mai bun. Consecvența nu e estetică, e funcție: utilizatorul învață o dată și recunoaște peste tot.
modul 07 / sisteme de design & componente
design tokens & documentație
tokens: deciziile de design ca variabile
Un design token e o decizie de design salvată ca variabilă cu nume, nu ca valoare împrăștiată prin fișiere.
❌ Peste tot în machete: #35E0E0, 16px, 12px
✅ Tokens:
culoare-accent = #35E0E0
spatiu-mediu = 16px
rotunjire-card = 12px
text-corp = 16px / 1,5
- Schimbi într-un loc — culoarea de accent se actualizează în tot produsul.
- Vorbești aceeași limbă cu dezvoltatorii — ei folosesc exact aceleași nume în cod.
- Permit teme — aceleași nume, valori diferite pentru temă deschisă/închisă.
denumire semantică vs literală
Literal: albastru-500 — descrie culoarea.
Semantic: culoare-actiune-principala — descrie rolul.
Numele semantice sunt superioare: dacă mâine acțiunea principală devine verde, numele rămâne corect. Cu albastru-500 ajungi în situația absurdă în care „albastru-500" e verde.
ce conține un sistem de design
| Parte | Conține |
|---|
| Fundamente | Culori, tipografie, spațiere, rotunjiri, umbre |
| Componente | Butoane, câmpuri, carduri, modale — cu toate stările |
| Tipare | Cum se combină: formulare, tabele, navigare, mesaje |
| Reguli de conținut | Ton, majuscule, formulări pentru erori, date, valute |
| Accesibilitate | Reguli de contrast, focus, dimensiuni minime |
documentația: partea care decide dacă sistemul trăiește
Un sistem fără documentație moare — oamenii nu știu ce există și își fac propriile variante. Fiecare componentă are nevoie de:
- Ce e și pentru ce se folosește.
- Când o folosești — și, la fel de important, când NU.
- Exemple corecte și greșite, alăturate.
- Note de accesibilitate și de conținut.
sistemul e un produs, nu un livrabil
Un sistem de design nu se „termină". Are utilizatori (echipa), are nevoie de întreținere, de versionare, de un proces prin care cineva poate propune o componentă nouă. Sistemele abandonate au aceeași cauză: au fost tratate ca un proiect cu termen, nu ca un produs viu.
de reținut
Design tokens transformă deciziile în variabile cu nume — schimbi într-un loc, vorbești aceeași limbă cu dezvoltatorii și poți face teme. Preferă numele semantice („culoare-acțiune-principală") celor literale („albastru-500"), care devin absurde când culoarea se schimbă. Un sistem conține fundamente, componente, tipare și reguli — dar ce decide dacă trăiește e documentația și tratarea lui ca produs viu, nu ca proiect cu termen.
modul 08 / accesibilitate & design incluziv
de ce & principiile WCAG
Accesibilitatea înseamnă ca produsul să poată fi folosit de oameni cu dizabilități — vizuale, motorii, auditive, cognitive. Nu e o funcție opțională adăugată la final; e o proprietate a designului bun.
de ce contează
- Scara — aproximativ 15% din populație are o formă de dizabilitate. E cel mai mare grup de utilizatori pe care îl poți exclude dintr-o dată.
- Dizabilitatea e adesea temporară sau situațională — o mână ruptă, un ecran în soare puternic, un mediu zgomotos, o conexiune proastă. Designul accesibil ajută pe toată lumea, în anumite momente.
- Legal — în multe jurisdicții e obligatoriu pentru servicii publice și tot mai mult pentru cele private.
- Calitate — un produs accesibil e aproape întotdeauna mai clar și pentru ceilalți.
curb-cut effect
Bordurile coborâte de la trecerile de pietoni au fost făcute pentru scaunele cu rotile — dar sunt folosite de părinți cu cărucioare, curieri cu troler, bicicliști, oameni cu bagaje. Ce proiectezi pentru cazurile limită îmbunătățește experiența tuturor. Subtitrările sunt un alt exemplu: create pentru persoane surde, folosite azi masiv în locuri publice și de oricine se uită la un video fără sunet.
cele patru principii WCAG (POUR)
| Principiu | Înseamnă |
|---|
| Perceptibil | Informația poate fi percepută (contrast suficient, text alternativ, subtitrări) |
| Operabil | Poate fi folosit (tastatură, timp suficient, ținte suficient de mari) |
| Ușor de înțeles | Limbaj clar, comportament previzibil, erori explicate |
| Robust | Funcționează cu tehnologii asistive (marcaj semantic corect) |
Standardul are trei niveluri: A (minim), AA (ținta practică pentru majoritatea produselor) și AAA (foarte strict, rar aplicabil integral). Când cineva spune „conform WCAG", se referă de obicei la AA.
de reținut
Accesibilitatea nu e o funcție adăugată la final, ci o proprietate a designului bun — și afectează ~15% din populație, plus pe oricine în situații temporare (soare puternic, mână ocupată, mediu zgomotos). Cele patru principii POUR: perceptibil, operabil, ușor de înțeles, robust. Ținta practică e nivelul AA. Iar efectul bordurii coborâte e regula generală: ce proiectezi pentru cazurile limită îmbunătățește experiența tuturor.
modul 08 / accesibilitate & design incluziv
reguli practice de accesibilitate
contrast — cel mai frecvent eșec
| Element | Raport minim (AA) |
|---|
| Text normal (sub 18px) | 4,5:1 |
| Text mare (18px+ sau 14px îngroșat) | 3:1 |
| Elemente de interfață (chenare, pictograme) | 3:1 |
Se verifică cu un instrument, nu din ochi. Cel mai des pică: text gri deschis pe alb, text alb pe culori deschise (galben, verde deschis) și placeholder-ele din formulare.
tastatură
- Tot ce se poate face cu mausul trebuie să se poată face cu tastatura. Test: pune mausul deoparte și parcurge un flux întreg cu Tab, Enter, Escape.
- Indicatorul de focus vizibil — mereu, fără excepție.
- Ordinea logică a tabulării — urmează ordinea vizuală, nu sare haotic.
- Fără capcane — dintr-o fereastră modală trebuie să poți ieși cu Escape.
- Link „sari la conținut" — ca utilizatorul să nu treacă prin tot meniul la fiecare pagină.
text alternativ pentru imagini
| Tip imagine | Ce scrii |
|---|
| Informativă | Ce comunică: „Grafic: vânzările au crescut cu 20% în martie" |
| Decorativă | Text alternativ gol — ca să fie ignorată de cititorul de ecran |
| Funcțională (buton/link) | Ce face: „Caută", nu „pictogramă lupă" |
Regula: descrie funcția sau informația, nu aspectul. „Poză" sau „imagine1.jpg" nu ajută pe nimeni.
formulare
- Etichete vizibile, legate de câmp — nu doar placeholder (care dispare când scrii, lăsând utilizatorul fără context).
- Erorile lângă câmp, explicate: „Data trebuie să fie în format ZZ.LL.AAAA", nu „Date invalide".
- Nu semnala doar prin culoare — adaugă pictogramă și text.
- Indică ce e obligatoriu clar, nu doar cu un asterisc roșu.
ținte de atingere & mișcare
- Minimum ~44×44 px pentru orice element atins pe mobil, cu spațiu între ele.
- Respectă preferința de reducere a mișcării — animațiile ample pot provoca amețeală sau rău de mișcare unor utilizatori.
- Nimic care clipește rapid (risc de convulsii).
de reținut
Regulile care prind majoritatea problemelor: contrast 4,5:1 pentru text normal (verificat cu instrument, nu din ochi), totul accesibil de la tastatură cu focus vizibil, text alternativ care descrie funcția sau informația, etichete vizibile în formulare (nu doar placeholder) cu erori explicate lângă câmp, și ținte de minimum 44px pe mobil. Testul cel mai simplu și mai revelator: parcurge un flux întreg fără maus.
modul 09 / testare, handoff, portofoliu · proiect & test final
testarea de utilizabilitate & handoff
Designul nu e terminat când arată bine — e terminat când oamenii reușesc să-l folosească. Testarea de utilizabilitate e singurul mod de a afla care dintre cele două e adevărat.
cum se face un test
- Definește ce vrei să afli — „găsesc oamenii cum să anuleze o comandă?"
- Scrie sarcini, nu instrucțiuni. ✅ „Tocmai ai comandat greșit. Anulează comanda." ❌ „Apasă pe Comenzile mele, apoi pe Anulează."
- Recrutează 5 participanți potriviți (nu colegi de echipă).
- Observă în tăcere. Nu ajuta, nu explica. Tăcerea ta e cea mai valoroasă unealtă.
- Cere gândire cu voce tare — „spune-mi la ce te gândești acum".
- Notează unde ezită, unde greșesc, ce spun spontan.
cea mai grea parte: să taci
Instinctul e să ajuți când vezi pe cineva blocat. Dar fiecare moment în care intervii e o informație pierdută — în viața reală nu vei fi acolo să explici. Când te întreabă „ce trebuie să fac aici?", răspunde cu „ce ai face dacă ai fi singur?". Nu-ți testezi utilizatorul; îți testezi designul. Dacă cineva se blochează, designul a eșuat, nu persoana.
de ce cinci participanți
Primii cinci utilizatori descoperă majoritatea problemelor majore de utilizabilitate. După aceea, fiecare participant în plus repetă în mare parte ce ai aflat deja. E mai valoros să faci trei runde de câte cinci, cu îmbunătățiri între ele, decât o singură rundă cu cincisprezece.
interpretarea rezultatelor
- Caută tipare, nu incidente izolate. Dacă 4 din 5 ezită în același loc, e o problemă reală.
- Separă „nu-mi place" de „nu pot". Preferințele sunt opinii; blocajele sunt defecte.
- Prioritizează după gravitate și frecvență.
- Nu implementa cererile literal. Utilizatorii raportează bine problemele, dar propun rareori cele mai bune soluții — asta e treaba ta.
handoff: predarea către dezvoltatori
Un design bun prost predat devine o implementare proastă. Ce trebuie să primească echipa:
| Element | De ce |
|---|
| Toate stările | Gol, încărcare, eroare, succes — altfel le inventează dezvoltatorul |
| Comportament responsiv | Cum se rearanjează la mobil, unde sunt punctele de rupere |
| Tokens & spațiere | Valori exacte, nu „aproximativ 20px" |
| Interacțiuni | Ce se întâmplă la click, tranziții, durate |
| Cazuri limită | Text lung, listă cu 1000 de elemente, nume de 40 de caractere |
| Note de accesibilitate | Ordinea de focus, etichete, texte alternative |
Regula practică: orice nu e specificat va fi decis de altcineva, probabil altfel decât intenționai. Iar cea mai bună predare nu e un document aruncat peste gard — e o conversație: implică dezvoltatorii devreme, ca să afli ce e costisitor înainte să proiectezi în jurul acelui lucru.
de reținut
Testarea de utilizabilitate: sarcini, nu instrucțiuni, 5 participanți per rundă (mai bine trei runde de cinci decât una de cincisprezece), și tăcere — fiecare intervenție e informație pierdută. Caută tipare, separă „nu-mi place" de „nu pot", și nu implementa cererile literal: utilizatorii raportează bine problemele, dar rareori propun cele mai bune soluții. La handoff, tot ce nu specifici va fi decis de altcineva.
modul 09 / testare, handoff, portofoliu · proiect & test final
proiect ghidat: studiu de caz complet
Pui tot cursul la lucru într-un studiu de caz complet — proiectul care demonstrează procesul și care devine piesa centrală a portofoliului tău.
ce construiești
Redesignul unui flux real și problematic. Alege ceva concret și verificabil, de preferat din contextul tău local: comanda online la un restaurant din Chișinău, programarea la o clinică, plata unei facturi de utilități, rezervarea unui bilet. Un flux făcut complet valorează mai mult decât zece ecrane frumoase fără context.
planul, pe modulele cursului
- Cercetare (mod. 1): 5 interviuri cu utilizatori reali; întrebări despre comportamentul trecut. Notează citate.
- Sinteză (mod. 1–2): o persona bazată pe date, hartă de empatie, listă de puncte de durere.
- Definire (mod. 2): declarație de problemă cu dovezi, 3–5 user stories, journey map cu momentele de frustrare, prioritizare impact/efort.
- Structură (mod. 3): arhitectura informației (verificată prin card sorting cu 8 oameni), user flow complet inclusiv stările (gol, eroare, încărcare).
- Explorare (mod. 4): 8 schițe rapide pe hârtie, apoi wireframes gri cu conținut real.
- Design vizual (mod. 5–6): scară de spațiere (8px), scară tipografică, paletă cu contrast verificat, grilă.
- Sistem (mod. 7): componente cu toate stările, tokens denumite semantic.
- Accesibilitate (mod. 8): contrast verificat cu instrument, parcurgere completă doar cu tastatura, texte alternative, ținte de 44px.
- Testare (mod. 9): prototip clicabil, test cu 5 oameni, constatări, iterație vizibilă — arată versiunea înainte și după.
- Handoff (mod. 9): specificații, stări, comportament responsiv, note de accesibilitate.
studiul de caz pentru portofoliu
| Secțiune | Ce conține |
|---|
| Context | Ce produs, ce rol ai avut, cât a durat |
| Problema | Ce nu funcționa și de unde știi (dovezi) |
| Proces | Cercetare, decizii, alternative respinse și de ce |
| Soluția | Ecranele finale, cu explicația fiecărei decizii |
| Rezultate | Ce s-a îmbunătățit (măsurat sau observat în teste) |
| Ce ai învățat | Ce ai face altfel — arată maturitate |
ce caută de fapt un angajator
Nu ecrane frumoase — pe acelea le poate face oricine cu o șablonă. Caută gândire: cum ai ajuns de la o problemă la o soluție, ce ai respins și de ce, cum ai reacționat când testele au arătat că te-ai înșelat. Un studiu de caz care arată o ipoteză infirmată și corectată e mai valoros decât unul în care totul a mers perfect din prima. Arată procesul, nu doar rezultatul.
definiția lui „gata"
- Fiecare decizie majoră de design poate fi justificată cu o dovadă din cercetare sau testare.
- Fluxul acoperă toate stările, nu doar calea fericită.
- Contrastul trece verificarea; fluxul e parcurgibil complet cu tastatura.
- Există o iterație documentată: versiunea 1, ce a arătat testul, versiunea 2.
- Studiul de caz e scris pentru cineva care nu știe nimic despre proiect.
felicitări
Ai parcurs designul UX/UI cap-coadă: procesul, cercetarea, definirea problemei, arhitectura informației, wireframes și prototipuri, principii vizuale, tipografie și culoare, sisteme de design, accesibilitate, testare și handoff — combinate într-un studiu de caz complet. Principiul central de reținut: designul nu e cum arată, ci dacă oamenii reușesc. Urmează testul final: 20 de întrebări din tot cursul. Prag: 70%. Succes!