1 Designul centrat pe utilizator

IU exemplu pozitiv sau negativ?

Sybase PowerBiulder este un mediu de dezvoltare a aplicațiilor. Utilizatorii pot crea cu
ajutorul acestui program interfețe, selectând si apoi desenând controalele (butoane, liste,
diferite obiecte grafice).

Controalele sunt selectate dintr-un meniu ce apare accesând un icon din toolbar. Meniul
seamănă cu un toolbox, dar se comporta ca un meniu derulant (pulldown menu) astfel încât
după ce se face o selecție din el dispare. După ce este selectat controlul, iconul său este afișat
în toolbar, iar dacă se face click pe formular, va apărea controlul selectat.

Acest design rezolvă câteva probleme: cea mai mare parte a timpului, toolbox-ul este ascuns,
lăsând astfel utilizatorului spațiu pentru a vizualiza formularul pe care încearcă sa-l creeze. Se
pot crea mai ușor multiple instanțe ale aceluiași control. De exemplu utilizatorul vrea să
creeze mai multe butoane deodată. Controlul curent este afișat chiar daca toolbox-ul nu este
vizibil.

Însă ultima caracteristică conduce la o nefericita problema de design: iconul din toolbar este
diferit de fiecare dată când utilizatorul încerca să îl găsească. Chiar și utilizatorii curenți ai
aplicației PowerBilder au raportat aceasta problemă a “vânării” butonului de access la
toolbox. Butonul este în aceeași poziție, însă un este ușor de găsit, datorită faptului că este
localizat în mijlocul altor butoane a toolbarului. Forma butonului definește însuși butonul într-
un toolbar, dar aceasta de schimbă în permanență.

Un task ce probabil părea trivial creatorilor aplicației PowerBuilder – utilizatorul trebuie să

știe unde este butonul de vreme ce-l folosește deja – s-a dovedit că nu e deloc trivial.

La o astfel de situație se poate ajunge când nu se aplică un model corect de dezvoltare a

interfețelor utilizator.

1.1 Modelul cascadă - Procesul tradițional de inginerie software

Modelul cascadă, este unul dintre primele procedee de design pentru dezvoltarea de
software. Acesta bazează pe modelarea procesului de design ca o secvență de etape. Fiecare
etapă rezultă într-un produs concret (un document de cerințe, un design, un set de module de
cod) care va fi folosit apoi la următoarea etapă. Fiecare etapă include de asemenea propria
validare: designul este validat cu cerințele, codul este validat conform designului ș.a.m.d.

Cea mai mare îmbunătățire pe care modelul cascadă l-a adus în dezvoltarea de software față
de modelele precedente (haotice) este disciplina pe care o impune programatorilor, aceea de a
gândi întâi și apoi de a scrie cod. Cerințele și designul preced în general prima linie de cod.
În producție, un dezvoltator de software are în atribuțiile de serviciu nu numai scrierea de cod
ci și identificarea cerințelor.

1.2 Modelul cascada cu feedback

Validarea unei etape nu este întotdeauna suficientă. Câteodată unele probleme nu apar decât
la următoarea etapă. Încercarea de a scrie cod conform designului ar putea dezvălui probleme
de design (de exemplu nu se poate implementa cu respectarea cerințelor de performantă).
Încercarea de a integra codul modularizat ar putea dezvălui bug-uri în cod de abia în etapa de
testare. Astfel modelul cascadă implică feedback între etape.

Pericolul apare în momentul în care o greșeală dintr-una din etapele inițiale (de exemplu o
cerință omisă) nu este descoperită decât într-una din etapele finale (de exemplu testele de
acceptare). Astfel de greșeli pot costa refacerea tuturor etapelor intermediare.

1.2.1 Modelul cascadă nu este bun pentru designul IU

Deși modelul cascadă este util pentru diferite aplicații software, nu este foarte potrivit pentru
dezvoltarea interfețelor utilizator.

În primul rând dezvoltarea interfețelor utilizator este un proces riscant. Nu este întotdeauna
ușor de potrivit modelul utilizator cu modelul program. Nu există încă o metoda simplă de a
anticipa succesul unei IU.
În al doilea rând, când se aplică modelul cascadă în mod standard, utilizatorii apar în procesul
de dezvoltare în doua locuri: analiza cerințelor și testele de acceptare. Deci mai întâi, la
început întrebam utilizatorii ce au nevoie (analiza cerințelor), și apoi începem să scriem cod,
și nu mai cerem feedback de la utilizatori decât atunci când putem să le prezentam un sistem
complet. Astfel dacă greșim design-ul, modelul cascadă nu ne va permite să aflăm decât la
final. Nu vom ști cât de bună este interfața noastră decât la final.

În al treilea rând, când apar problem de IU, de obicei acestea cer schimbări dramatice: cerințe
noi, sau design nou, ceea ce ar presupune renunțarea la parți bune de cod scris și testat.

1.3 Designul iterativ (Proiectarea iterativă)

Designul iterativ oferă o cale de administrare a riscului pe care îl presupune designul IU. În
designul iterativ, software-ul este rafinat în mod repetat în jurul unui ciclu de design: Mai
întâi ne imaginam (design), apoi îl realizam fizic (implement), apoi îl testam (evaluare).

Luat intr-o singură iterație însă, acesta seamănă cu cel mai rău caz al modelului cascada, unde
facem tot de la design pana la testul de acceptare înainte de a descoperi o greșeală de design
care ne va forța să repetam procesul! Se pune deci întrebarea: care ar fi avantajul acestui
design?

1.3.1 Designul iterativ aplicat greșit

Din nefericire, multe proiecte de IU au urmat acest model, fiecărui iterație corespunzându-i
câte un release. Au aplicat modelul cascadă standard, au creat o IU greșită și au lansat pe piață
produsul. Evaluarea a avut loc astfel la nivelul pieții, unde clienții ghinioniști au testat sau
chiar au cumpărat produsul și au identificat probleme de utilizabilitate. Procesul de design a
fost apoi iterat în versiunea 2.

Folosirea clienților, care plătesc pentru produsul nostru, în rolul de evaluatori al utilizabilității
implică două probleme majore:
- acestora nu le v-a plăcea produsul și nici situația în sine
- nu vor mai cumpăra versiunea 2 a produsului

1.3.2 Designul iterativ aplicat corect: modelul spiralat

Modelul spiralat oferă rezolvarea acestei probleme. Se vor lua în calcul câteva iterații în
procesul de design, astfel încât primele iterații să fie cât mai ieftine cu putință.

Dimensiunea radială a modelului spiralat (raza spiralei), corespunde costului fiecărei etape a
iterației (sau echivalent, ar putea corespunde fidelității sau acurateței interfeței la fiecare
iterație).

De exemplu implementarea de început ar putea fi făcută ca schiță pe hârtie sau poate fi o

machetă. Are acuratețe redusă, reprezintă doar o umbră, o idee a ceea ce ar trebui să devină
interfața finală. Dar este extrem de ieftin de realizat, și o putem evalua arătând și întrebând
utilizatorii despre ea.

1.4 Prototipurile timpurii pot detecta problemele de utilizabilitate

Click & Print Certificates este un program ce permite crearea diferitelor modele de certificare,
diplome și premii. Diferitele stiluri de certificare pot fi selectate din bara de scroll bar
orizoltală. Fiecare click pe bara orizontală afișează diferite stiluri de certificare.
În acest design există două probleme majore: în primul rând, singura posibilitate de a vedea ce
stil e disponibil este de a da scroll pană la capăt, trecând prin toate stilurile. O a doua
problemă este aceea că singura posibilitate de a selecta un stil este navigând prin toate stilurile
ce preced stilul dorit.

Aceste probleme de utilizabilitate presupun cu siguranță redesignul aplicației. Însă aceste

probleme de design ar fi fost ușor rezolvate dacă ar fi fost mai întâi testate ca o simplă schiță
pe hârtie, într-o iterație de început a designului spiralat. În acel punct, schimbarea designului
ar fi costat doar încă o schiță în loc de o zi de scris cod.

1.5 Designul iterativ al interfețelor utilizator

În iterațiile de început, riscurile sunt mari, deoarece avem puține cunoștințe despre interfața pe
care dorim să o dezvoltam. Astfel ne luam cele mai mici angajamente pentru implementările
de început.

Prototipurile de început sunt făcute pentru a putea renunța ușor la ele. În această abordare se
poate folosi intensiv designul paralel. Daca ne găsim în situația în care avem mai multe
alternative de design, putem construi mai multe prototipuri și apoi le evaluam, acest lucru
făcându-se fără o cheltuială prea mare.

După ce am evaluat și reproiectat de câteva ori, putem spune că am acoperit suficiente situații
posibile pentru a putea evita erorile majore ce pot apărea în IU. După primele iterații, riscurile
ce pot apărea in IU au fost atenuate și putem mai apoi să facem implementări mai costisitoare
a IU, care ar putea să însemne un prototip pe care intenționăm să-l păstrăm. Evaluam apoi din
nou și rafinăm în continuare.

Cu cât facem mai multe iterații cu atât rafinam mai mult designul. Suntem în situația în care
“urcam dealul”, nu “exploram” spațial designul random. Păstrăm părțile de design care merg,
și regândim părțile cu probleme. Deci ar trebui să obținem o interfață mai bună cu cât facem
mai multe iterații. Numai iterațiile mature sunt vizualizate de către utilizatori la scară largă.

1.6 Designul centrat pe utilizator

Designul iterativ este o parte extrem de importantă a designului centrat pe utilizator (proces
de design al interfețelor utilizator larg răspândit în rândurile designerilor de UI).

Exista o întreagă varietate de tehnici de design bazat pe utilizator (ex: GUIDE, STUDIO,
OVID, LUCID). Dar majoritatea au trei caracteristici în comun:
- Designul iterativ pentru crearea de prototipuri rapide (rapid prototyping)
- Focalizarea timpurie pe utilizatori si taskurile lor
- Evaluarea continuă la fiecare iterație în procesul de design.

Inițial concentrarea trebuie focalizată pe utilizatori (beneficiari) și pe task-urile acestora

- Se va face o analiza a utilizatorilor: cine sunt utilizatorii care vor folosi aplicația?
- Apoi se vor analiza task-urile utilizatorilor: ce au nevoie sa facă?
- Utilizatorii vor fi implicați ca evaluatori, consultanți și câteodată chiar designeri

De-a lungul evoluției dezvoltării produsului software se va face o evaluarea constantă

 - Utilizatorii sunt implicați în fiecare iterație
- Fiecare prototip este cumva evaluat

Mai jos este descrisă o variantă de design centrat pe utilizator

1. Analiza taskurilor
2. Schițarea designului
3. Prototipul pe hârtie
4. Testarea prototipului cu utilizatorii
5. Prototipul pe calculator
6. Evaluare heuristică
7. Implementare
8. Testarea făcută de utilizatori

Etapele sau termenii proiectului sunt construiți astfel încât să urmărească următorul model
spiralat:
1. Analiza taskurilor: colectarea cerințelor pentru IU
2. Schițarea design-urilor: schițe ale IU făcute pe hârtie
3. Prototipul din hârtie: un prototip interactiv făcut din hârtie și alte materiale ieftine
4. Testarea prototipului cu utilizatorii: prototipul va fi testat de către utilizatori în vederea
obținerii feedback-ului de la aceștia cu privire la eventualele defecte majore în
interfață.
5. Prototipul făcut pe calculator: un prototip software interactiv la care suntem pregătiți
ca eventual să renunțăm.
6. Evaluare heuristică: prototipul software va fi evaluat sistematic din punct de vedere al
utilizabilității.
7. Implementarea: se va implementa o versiune pe care intenționăm să o păstrăm
8. Testarea făcută de utilizatori: implementarea va fi testată de către utilizatori și apoi
rafinată la fiecare nouă iterație.

Fiecare dintre aceste etape pot suferi mai multe iterații dacă este necesar.