Timpul este foarte important pentru utilizatori, motiv pentru care nouă ar trebui să ne pese. La fiecare proiect trebuie să ne punem întrebările: ”Mă scutesc pe mine de câteva ore de dezvoltare în defavoarea utilizatorului?” și ”Cum aș putea să îmbunătățesc experiența pe care utilizatorul o are?”
Oamenii urăsc să piardă timpul, mai ales online. Petrecem atât de mult timp online încât și cele mai mici interacțiuni necesită timp. O mică “bubă” nu pare cine știe ce, dar mai multe adunate aduc frustrare și cresc probabilitatea că utilizatorii să renunțe la folosirea serviciului pe care încerci să îl furnizezi.
Suntem atenți la timpul nostru când începem un proiect. Avem milestone-uri de atins, demo-uri de făcut, bug-uri de rezolvat și, de parcă toate acestea nu-s de ajuns, avem și Internet Explorer. Uităm un lucru esențial: tot ce facem are efect pozitiv sau negativ asupra experienței utilizatorului. Nu trebuie să lăsăm ca sentimentele noastre față de proiect să vină înaintea experienței utilizatorului. În cele mai multe cazuri, utilizatorul suferă pentru că nouă nu ne place proiectul, nu avem timp și așa mai departe. De multe ori, puțin și bine e tot ceea ce trebuie comparativ cu mult și rău.
Steve Jobs susținea că prin îmbunătățirea timpului de pornire al Macintosh-ului ar putea salva vieți. Jobs era obsedat de a nu pierde timpul utilizatorilor ce-i folosesc produsele. Și noi ar trebui să fim la fel de atenți când vine vorba de “produsele” noastre.
Probabil milioane de oameni nu îți vor folosi site-ul dar milioane folosesc WWW-ul. La un loc furăm vieţile oameniilor prin interacţiuni făcute greşit. Când lucrez la un site, o întrebare mă macină mereu: “Mă scutesc pe mine de câteva ore de dezvoltare în defavoarea utilizatorului?”.
Acesta este miezul problemei. În disperarea de a nu depăşi deadline-ul sau bugetul ne salvăm pe noi şi totul se reflectă asupra utilizatorului. Haideţi să vedem mai exact ce efect au deciziile noastre asupra utilizatorilor.
Cel mai evident şi mai dureros mod prin care poţi frustra utilizatorii e timpul de încărcare al unui site, iar când vorbim de performanţă nu doar utilizatorii suferă ci şi clientul. Povestea cu performanţă e un pic mai complicată, majoritatea dăm vină pe server şi pe internet sau clasică poveste: “La mine pe calculator merge bine!”. În fond şi la urmă urmei e valid argumentul că serverul sau internetul e de vină, dar totodată sunt o mulţime de aplicaţi native (HTML5 API - câteva exemple - http://www.sitepoint.com/10-html5-apis-worth-looking/) care ne vin în ajutor. Putem detecta dacă utilizatorul este pe dispozitiv mobil sau nu, dacă e conectat la WI-FI sau internet mobil şi tot aşa. Avem atâtea resurse care ne vin în ajutor, dar mulţi dintre noi nu le folosim. În funcţie de tot ceea ce ştim despre un utilizator- dacă e mobil sau nu, dacă are internet de mare viteză, dacă mai are baterie la dispozitiv- putem îmbunătăţi performanţa şi totodată să oferim experienţe unice.
Problema e că îmbunătăţirea performanţei este de multe ori ultimul lucru la care ne gândim şi totodată e unul din cele mai ocolite de dezvoltatori. Am devenit leneşi odată cu extinderea internetului de mare viteză. Trişăm la optimizarea imaginilor, la reducerea cererilor HTTP şi a bibliotecilor de JavaScript. Toate acestea se întâmplă pentru că mulţi dintre noi ştim să dezvoltăm o grămadă de chestii pe web, dar nu ştim un lucru esenţial: cum funcţionează un browser şi cum redă conţinutul, informaţii elementare pentru a putea construi un web-browser performant.
Așadar, întrebările de tipul “Cum pot optimiza încărcarea acestui fişier?”, “Cum pot face această bucată de cod mai performantă?”, “Cum pot scrie aceeaşi funcţie de javascript în mai puţine linii?”, sunt cele care se circumscriu unei atitudini preocupate de performanța site-ului.
Fiecare formular are specificul lui, cu regulile şi cu problemele lui pe care le împarte cu restul formularelor. Nu există un standard, probabil ar fi util să existe unul, dar din păcate nu e aşa. Fiecare e liber să facă ce vrea pe web, mai mult sau mai puţin. Iar la formulare fiecare serviciu are algoritmii lui, unii mai complicaţi decât alţii. E de apreciat totuşi încercarea de a fluidiza procesul de înregistrare şi intrare în cont prin folosirea profilelor sociale.
Mulţi dintre noi ne oprim din completarea unui formular când întâlnim un anumit “suspect” CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart).
Inventat în anul 2000 având la bază un proces destul de simplu şi inutil în acelaşi timp. Primeşti o poză cu ceva caractere pe care doar un om le poate recunoaşte, le introduce şi trece la pasul următor. Foarte util în blocarea roboţilor în anul 2000. Au trecut 14 ani şi am avansat considerabil, nu cred că mai este necesar să pierdem timpul utilizatorilor cu completarea de CAPTCHA. Milioane de ore s-au pierdut pentru că utilizatorii au fost forţaţi să completeze în nenumărate rânduri un câmp, doar pentru a putea trimite un amărât de formular.
Toate acestea pentru că nu am rezolvat încă problema roboților. Şi aici nu vorbesc doar de CAPTCHA, vorbesc de orice sistem care obligă utilizatorii să dovedească că sunt oameni. În primul rând, de ce trebuie utilizatorii să dovedească că sunt oameni?
Problema roboţilor putea fi rezolvată dacă am fi alocat un pic de timp. “The honeytrap tehnique” este un foarte bun exemplu în acest sens. De asemenea, există soluţii server-side care ne ajută să filtrăm request-urile automate. Adevărul e că aruncând un CAPTCHA în pagină e mai rapid si efortul e relativ minim.
De regulă CAPTCHA e ultimul lucru dintr-un formular, ceea ce este bine.
Majoritatea ar răspunde “Din motive de securitate”. E adevărat că parolele trebuie să fie sigure. Dar în ultima vreme aproape fiecare te forţează ca parola să fie într-un anume fel.
De ce sunt obligat ca parola să fie un mix între numere, caractere şi caractere speciale, cu majuscule, fără majuscule, etc.? De ce nu rămâne la latitudinea utilizatorului să îşi aleagă parola? Fie ea o combinaţie de caractere sau o propoziţie. “Parolă mea e aceasta şi va provoc să o ghiciţi!”. Numărul de caractere face parola mai sigură, iar o parolă ca cea din exemplu e şi mai uşor de reţinut. Iar dacă sistemul nu acceptă spaţii, ignoră-le. De asemenea am mai putea oferi opţiunea de a vedea ce scrii în câmpul de parolă.
Nu forţa utilizatorii să “îşi corecteze” greşelile în formulare!
E de apreciat când se încearcă prepopularea conținutulului unui formular. De exemplu, pe baza codului poştal să îţi genereze adresa aproape completă. Ar putea scuti utilizatorul de completarea a patru sau cinci câmpuri. E un lucru destul de interesant şi nu mulţi îl practică, din păcate. O parte din scripturile care populează adresa după codul poştal necesită ca informaţiile introduse să nu aibă spaţii, virgule, etc. . În loc să se scoată toate caracterele înafara de cifre din configurarea scriptului, utilizatorul e forţat “să-şi corecteze greşeală”. De ce trebuie utilizatorul să introducă datele într-un mod anume? De ce le pierdem timpul şi îi obligăm să reintroducă datele într-un mod anume? De ce nu formatăm noi datele respective? Dacă un câmp nu trebuie să conţină caractere gen punct, virgulă, e mult mai simplu să formatăm noi corect dinscript decât să obligăm utizatorul să corecteze o greşeală care poate nici nu-i din vină lui.
Selectorii de ţară sunt o pacoste şi ar trebui să fie îmbunătăţiţi mult. De ce să nu fie cele mai comune ţări primele în listă sau să introducem un câmp de căutare, care să filtreze ţăriile în timp ce utilizatorul completează acel câmp? Sunt multe soluții care pot ameliora calitatea selectorilor de ţară, tot ce trebuie să facem e să acordăm un pic mai multă atenţie lucrurilor mărunte.
Un lucru care trebuie luat în considerare este şi interacţiunea cu un formular pe dispozitivele mobile. Trebuie să ne gândim la controale alternative (swipe, pull, push etc.). Să fluidizăm un pic modul în care utilizatorul completează un formular. De nenumărate ori am văzut forumulare pe telefoane care sunt imposibil de completat.
Ar mai fi multe de zis la capitolul formulare, dar mă opresc aici, pentru că articolul ar deveni prea lung.
Trebuie să fim atenţi la interacţiuni elementare. Putem reduce o fracţiune de secundă din interacţiunile repetitive? Căutarea în site de exemplu. E nevoit utilizatorul să dea click pe butonul de “Caută” sau funcţionează şi dacă apasă tasta “Return”? În primul rând nu ar trebui să apese pe butonul caută pentru a primi rezultatele. În zilele noastre majoritatea formularelor de căutare funcţionează în ambele moduri, dar doar pentru că butonul de “Caută” e în apropierea câmpului de căutare majoritatea utilizatoriilor sunt tentaţi să apese pe el.
Am început să neglijăm opţiunea de “Ţine-mă minte!” şi aceasta pentru că browser-ele moderne ne vin în ajutor, ceea ce nu-i tocmai un lucru rău. Totuşi ce facem dacă utilizatorul foloseşte un calculator public? Un răspuns relativ simplu ar fi: “Foloseşte sesiune privată!”. Sesiunile private în browser sunt ceva relativ nou, iar utilizatorii de ocazie nu sunt încă destul de familiarizaţi cu această opţiune.
Navigarea şi meniurile de tip dropdown. De câte ori nu ne-au scos din minţi meniurile pe trei nivele şi cât de greu era să ajungi la ultimul nivel. Dacă ai mai mult de două nivele de dropdown, cu toate că şi două sunt un pic cam mult, e clar că nu faci ceva bine, iar ceea ce iniţial trebuia să fie simplu şi rapid se transformă într-un proces demn de abilităţile unui chirurg, unde precizia milimetrică e la ea acasă. În majoritatea cazurilor o navigare grea e principala cauză pentru care utilizatorii părăsesc site-ul.
Pierdem aşa mult din timpul utilizatorilor cu conţinut mult şi scris prost încât e imposibil că ei să găsească bucăţile de informaţie de care au nevoie. Pentru început am putea folosi mai bine titlurile, paragrafele, liste, citate, spaţii mari între texte, zone mult mai aerisite şi aşa mai departe încât să formatăm conţinutul într-un mod în care utilizatorii să îl scaneze şi să extragă informaţii esenţiale cât mai repede.
E foarte uşor să distragi atenţia utilizatorului de la ce-i important şi să-l duci în zone din care îl poţi pierde, de aceea trebuie să fim foarte atenţi la ce punem în jurul zonelor de interes. În procesul de design împart conținutul în trei zone:
Zona unu. Navigarea, câmpul de caută, zona de intră în conta şi cont, coş de cumpărături dacă e magazin online, lista de produse, lista de articole, lista de servicii şi uneori pagină de contact şi aşa mai departe.
Zona doi. Informaţii utile, pagini secundare (despre noi, întrebări frecvente, ajutor, profile sociale, newsletter etc.)
Zona trei de obicei e zona de footer, la care nu prea multă lume acordă atenţie.
Iau ca exempul un magazin online, care ca principală cale va alege produs, adaugă în coş, plăteşte. Cu cât procesul e mai complicat, cu atât utilizatorul pierde mai mult timp şi rapdarea îi scade rezultând în abandonarea comenzii.
Toate cele menţionate mai sus sunt doar o mică parte din problemele cu care utilizatorii se confruntă zi de zi, din cauza noastră, în căutarea lor după informație. Am putea face mult mai multe în toate domeniile de pe web. De cele mai multe ori suntem conştienţi că pierdem timpul utilizatorilor, dar nu facem nimic împotriva, de aceea trebuie să fim vigilenţi și să ne întrebăm un lucru: “Cum aş putea salva puţin din timpul utilizatorului în această situaţie?”. Și mai ales să nu uităm ceea ce a spus Steve Jobs “Things don’t have to change the world to be important.”
de Ovidiu Mățan
