Baza pentru a începe testarea este definirea a ceea ce se va testa, cum și cu cine. Indiferent dacă testul de utilizabilitate este la distanță sau față în față, protocolul de testare trebuie să includă detalii precum:
- mesajul de bun venit / introducere,
- sarcinile specifice, dacă există,
- instrucțiunile pentru utilizator,
- instrucțiunile pentru moderator sau facilitator și
- aspecte importante de observat.
A fi sistematic nu înseamnă a dedica prea mult timp acestei etape de planificare, ci a fi riguros pentru a profita la maximum de procesul de testare.
Datorită naturii testului, această situație apare mai des în modul față în față decât la distanță: moderatorul urmează protocolul la literă și pierde oportunități.
Pentru a sistematiza și a avea rezultate comparabile, este important să se urmeze ghidul și protocolul. Cu toate acestea, moderatorul unui test de utilizabilitate față în față ar trebui să aibă autonomia și agilitatea de a identifica oportunități dincolo de instrucțiunile inițiale și de a profita de aceste oportunități în timp ce utilizatorul este disponibil pentru a ajunge la noi descoperiri.
Să zicem că testăm un site e-commerce unde trebuie să validăm anumite ipoteze, printre alte obiective ale testului. Dacă urmăm instrucțiunile, probabil vom putea valida ipotezele, dar dacă lăsăm utilizatorul să facă alte sarcini liber, cu siguranță vor apărea alte descoperiri.
Indiferent de tipul de test de utilizabilitate pe care îl efectuezi, față în față sau la distanță, este important să testezi protocolul pentru a valida instrucțiunile, pentru a te asigura că sarcinile care trebuie îndeplinite au fost înțelese și că limbajul folosit este simplu și clar.
Altfel spus, trebuie să testezi testul. În caz contrar, dacă greșim în alegerea unui cuvânt și observăm acest lucru după ce moderatorul a efectuat deja mai multe sesiuni, pierdem timp și bani, deoarece trebuie să creștem numărul de utilizatori participanți.
Odată ni s-a spus „de fiecare dată când facem schimbări drastice și credem că ne îmbunătățim, blocăm call center-ul”. Asta înseamnă că, deși echipa de design și dezvoltare în cauză făcea îmbunătățiri și simplifica interfața, utilizatorul frecvent cunoștea deja „capriciile” software-ului și era obișnuit să apese de 3 ori consecutiv Enter pentru a ajunge la ecranul principal, așa că schimbarea acestui flux a însemnat scoaterea lui din rutină. Se pierdea și de aceea suna la call center.
Uneori, este trecerea necesară pe termen foarte scurt pentru a genera îmbunătățiri ale experienței pe termen mediu. Alteori, este un risc care trebuie asumat dacă pe termen lung se dorește îmbunătățirea experienței utilizatorului. În acest caz, un segment important de luat în considerare sunt utilizatorii noi care, dacă au probleme, este pentru că nu cunosc interfața și nu sunt obișnuiți cu ea. Prin urmare, perioada de învățare este lentă.
Accentul este pe testare, obținerea de informații și rezultate concrete pentru a îmbunătăți, în cele din urmă, o interfață și experiența utilizatorului, nu pe filtrarea bazelor de date.
A petrece prea mult timp și resurse filtrând baze de date de clienți pentru a recruta utilizatorul perfect și a-l alege cu grijă, nu este întotdeauna un proces profitabil. Poate că este mai bine să investești aceste resurse în construirea mai multor scenarii de testare și testarea cu o varietate mai mare de utilizatori pentru a obține mai multe descoperiri.
Aici am putea aprofunda mai mult, și o vom face pe viitor, dar un detaliu de planificat cu atenție este alegerea cuvintelor în comunicarea cu utilizatorul în timpul testării, formularea instrucțiunilor și evitarea oferirii de „ajutor” sau „sfaturi” în timpul executării sarcinilor.
În timpul testului de utilizabilitate putem identifica o serie de probleme. În unele cazuri, problemele sunt evidente: utilizatorul nu găsește informația, nu vede unde este coșul de cumpărături, nu înțelege o etichetă etc.
În alte situații, problema este mai complexă, iar identificarea faptului că există o problemă și care sunt cauzele sale este sarcina moderatorului și a analistului sau a consultantului (poate fi aceeași persoană).
Propunerea de soluții la o problemă de utilizabilitate poate fi o sarcină provocatoare, dar un lucru este cert: este treaba echipei din spatele interfeței și nu a utilizatorului.
Încă o dată, testul cu utilizatori nu este un focus group (unde s-ar putea cere participanților să se gândească la alternative posibile).
Dacă în protocolul de testare există o întrebare de tipul „Cum ai face acest pas mai simplu?”, ar trebui să iei în considerare eliminarea ei și să te dedici observării mai atente, analizei rezultatelor sau îmbunătățirii designului și testării din nou.
A crede că testul de utilizabilitate este SURSA de informații care îți va spune ce să faci pentru a optimiza rezultatele și a te baza doar pe această metodologie este iluzoriu.
Alte metodologii de cercetare și surse de date relevante pe care ar trebui să le analizezi sunt:
- metricile de trafic (de exemplu, de la Google Analytics),
- hărțile de căldură ale aplicațiilor precum Clicktale sau Crazyegg,
- înregistrările secvențelor de navigare,
- analiza cazurilor pornind de la solicitările primite prin e-mail sau rețele sociale,
- analiza performanței conținutului,
- cercetarea calitativă prin interviuri,
- sondaje de satisfacție,
- benchmarking,
- cercetarea cu utilizatori interni, cum ar fi executivii de asistență sau vânzătorii etc.
Deși un test de utilizator poate fi exploratoriu într-o primă etapă, este important să se definească indicatori atunci când se sistematizează procesul și rezultatele.
Ce se va evalua? Câțiva indicatori de rezultate pentru un test de utilizabilitate:
- Rata de succes în rezolvarea unei sarcini.
- Timpul necesar pentru a finaliza o tranzacție.
- Timpul necesar pentru a găsi o informație.
- Rata de abandon a sarcinii.
Atunci când realizăm un test de utilizabilitate pentru o interfață nouă, există o provocare în ceea ce privește propunerile de fluxuri de interacțiune care vor fi testate. A avea o singură alternativă poate limita prea mult rezultatele testului.
Fluxul tranzacțional ar trebui să aibă 3 sau 4 pași? Apelul la acțiune este clar și concret? Este preferabil să se ia acest tip de decizii de design comparând eficacitatea mai multor alternative.
Felicitări, am început să testăm, avem o listă de sarcini în așteptare și priorități de lucru pentru următoarele săptămâni. Și acum?
Dacă îmbunătățim experiența utilizatorului într-o interfață digitală existentă, cu siguranță mai sunt multe de făcut. Dacă, dimpotrivă, proiectăm un site web sau o aplicație, este important să integrăm testarea ca parte a procesului de design și să testăm în etapele principale pre și post-lansare.
În ambele cazuri, să ne amintim că testul în sine nu este un scop, ci un mijloc de a proiecta experiențe remarcabile.
Testul de utilizabilitate cu utilizatori nu este același lucru cu cercetarea cu utilizatori. Nu este același lucru cu „a ieși pe stradă”, în limbajul startup-urilor, pentru a testa un produs minim viabil (PMV). Nu este un test de compatibilitate în browsere, un test A/B, un sondaj de satisfacție, un focus group, un test de gusturi sau preferințe etc.
Înțelegerea diferențelor dintre fiecare metodă și capacitatea de a le explica intern sau de a le promova, asigură că toți actorii implicați folosesc un limbaj comun.
Atenție la dorința de a testa alternative de tip buton galben versus buton roșu. Pentru a testa diferențe mici și a obține date semnificative dintr-un eșantion mai mare, este preferabil să se ia în considerare teste de tip A/B testing. Testul de utilizabilitate nu este cea mai bună metodologie pentru a măsura impactul acestui tip de variabilă.
A crede că un test de utilizabilitate reușit înseamnă o tranzacție reușită, conversii uimitoare sau vânzări odată ce interfața este în producție, înseamnă a presupune o relație de cauzalitate ignorând impactul altor variabile.
Ne-am confruntat cu situații în care, în urma unui test cu utilizatori, un flux tranzacțional este îmbunătățit (și se validează că a fost îmbunătățit), dar, odată „în aer”, rezultatele lasă de dorit. Puțini utilizatori folosesc efectiv fluxul respectiv, ceea ce generează puține tranzacții și, în cele din urmă, echipa internă declară că obiectivele nu au fost îndeplinite; este aproape un eșec.
Înseamnă că rezultatul testului a fost greșit? Sau că tranzacția este prost proiectată? Nu neapărat. Indicatorii de rezultate scăzute (sau, KPI, de la key performance indicators, în engleză) pot fi atribuiți altor cauze, cum ar fi, de exemplu, o arhitectură informațională deficitară: în marea de informații a site-ului, tranzacția se pierde.
Spre deosebire de instanța testării, când utilizatorul trebuie să îndeplinească sarcina de a efectua o tranzacție, o plată online de exemplu, pornind de la pasul 1 și terminând la pasul x, când plata este în producție și utilizatorul trebuie să treacă prin pagina principală, accesul la tranzacție „concurează” cu alte elemente de conținut. Un alt exemplu: când noua funcționalitate este lansată, lansarea coincide cu probleme de hosting, astfel încât timpul de încărcare a paginii crește și utilizatorii abandonează tranzacția.
Pentru a evita acest tip de falsă problemă cauză – efect, este important să se analizeze în profunzime ce se întâmplă și să se dispună de surse complementare de informații, atât calitative, cât și cantitative.
Dacă te gândești că un test de utilizabilitate va elimina toate riscurile în fața unei schimbări majore de design, va asigura succesul unei lansări în producție sau va fi sinonim cu o creștere a vânzărilor, ar trebui să reconsideri procesul și să te asiguri că alegi metoda corectă pentru obiectivul corect.
Dacă, dimpotrivă, pentru tine este clar, atunci ești în măsură să comunici clientului și echipei tale de lucru de ce faci un test cu utilizatori și ce ar trebui să aștepte de la rezultate.
Ce alte erori frecvente ai observat în testele de utilizabilitate cu utilizatori?
De 
![Strategia de marketing digital: erori de evitat [Partea 3]](/content-images/859a0087-errores-ideas.jpg)
