User testing kezdőknek

Magyarul nem volt elérhető User Testing tananyag, és kértek, csináljak egyet. Több előadást tartottam már a témában (és tartanak még sokan), gondoltam itt az ideje írni is egyet…

Mi az user test (usability test?)

A user test (felhasználói teszt, rossz fordításban: felhasználó-tesztelés) egy a UX pszichológiai ágából származó kvalitatív vizsgálati módszer, a számítógép-ember interakciót vizsgálja szimulált vagy felügyelt kontextusban. 

Messzebről nézve a felhasználói teszt nem pusztán egy feladat végrehajthatóságát vizsgálja az adott környezetben, hanem azt is, milyen gondolatokat, élményeket vált ki a rendszer használata.

Mi nem a user test?

A user test nem véleménykérés. A teszt rendszerint két „funkcionális” kérdésre keresi a választ: 

• képes-e az ember a szimulált feladat végrehajtására az adott eszközzel?
• az eszköz az emberi elvárásoknak (expectation) és biológiai adottságainak megfelelően működik?

Ezek egy része (pl. ha a mobilappban egy fontos gomb hüvelykujjal elérhetetlen) programozási szempontból nem-funkcionális, de UX szempontból annak tekintjük, hiszen a feladat végrehajtási módját befolyásolja.

Hogy kinek mi és mennyire tetszik, ezt a felhasználói teszt nem méri jól. Azt se méri jól, mire lenne még szükség, legfeljebb azt, mi hiányzik.

A user test nem statisztikai alap. A kutatási képlet továbbra is: 

kutatás = kvalitatív x kvantitatív

A kvalitatív mérések felhívják a figyelmet jelenségekre, amelyek előfordulását lehet mérni kvantitatív (számszerű) mérésekkel, valamint lehetséges magyarázatot adhatnak a már megfigyelt jelenségekre. Ily módon a kvalitatív és kvantitatív vizsgálatok kiegészítik egymást. 

Ettől függetlenül, a miértek ismeretében néhány jelenség esetén a gyakorlatban gyakran vonunk következtetéseket kvantitatív ellenőrzés nélkül: ha már a második felhasználó se tudott belépni mert a login gomb „el van dugva”, ennek várhatóan vannak kvantitatív következményei is, egyszerűbb kijavítani mint pl. A/B teszttel lemérni ennek valóságalapját. 

Mi kell a teszthez?

Három dolog szükségeltetik:

• Egy szoftver vagy prototípus
• Egy tesztalany
• Egy megoldandó tesztfeladat

Ezekről később lesz szó.

Ezen kívül jó ha van nálunk:

• Egy képernyő-felvevő eszköz
• Egy (beszéd)hang felvevő eszköz
• Egy arcfelvevő eszköz
• Papír-ceruza

Az eszközök jó részét biztosítja asztali szoftver esetében a Camtasia, de vannak ingyenes eszközök is*. Mobilon iOS esetében reflector-t használunk, de a budapesti székhelyű UXStudio két webkamerával és egy fakanállal intézte el az egészet.

Általánosságban elmondható, hogy ingyenes, beépített szoftverrel és hardverrel is gyönyörűen meg lehet oldani egy tesztelést, de természetesen szakeszközök is tömérdek mennyiségben állnak rendelkezésre.

Fontos: az európai uniós törvények szerint mindennemű rögzítéshez a tesztalany explicit beleegyezése szükséges. Erre érdemes kitöltetni egy beleegyező nyilatkozatot. 

Az első tesztünk mindig legyen személyes teszt: tehát a tesztalany, a tesztelendő szoftver, és a tesztet vezető moderátor (azaz mi) tartózkodjunk egymás kb. 1 m-es körzetén belül.

Kikkel tesztelünk?

Rövid válasz: akit találsz. 

Hosszú válasz: a legtöbb hiba nem felhasználó-függő. Bárki, aki nem ismeri a szoftver működését belülről megfelel a célnak. **

Ebből rögtön következik az is, hogy mind te, mind a megrendelő alkalmatlan usertesztre tesztalanynak. 

Egyszerűen képtelen vagy nem tudni amit tudsz: olyan mint nem gondolni a rózsaszin elefántra. Bár szavakban játszhatsz ilyet, a viselkedésed más szinten dől el. Magyarul erről Kolboid blogján olvashatsz, az eredeti (egyszerű, órán reprodukálható) kísérlet Elizabeth Newton nevéhez fűződik.

Ritka az a szoftver, amely komoly fogalmi ismereteket feltételez: természetesen érdemes olyannal tesztelni, aki könnyen bele tudja élni magát a szerepbe, ha máséba nem, egy friss gyakornokéba. 

A szerepet elsősorban a felmerülő probléma határozza meg: a tesztalany számára a problémának (lesz még róla szó) kell életszerűnek lennie.

Itt, a FIBA-n belül vannak olyan részek, amelyet csak szervezőkön tudunk tesztelni (a probléma az ő munkájukban jön csak elő, sportági sajátosság), más dolgokat tetszőleges, a sportok iránt picit is érdeklődő embereken is lehet. Mivel azonban célunk, hogy bárkiből lehessen szervező aki már látott kosárlabdát, néhány komplex helyzetet kivéve játékosokon, edzőkön, játékvezetőkön és szülőkön is rendszeresen tesztelünk szervezőknek szóló szolgáltatásokat.

A belső munkatársakkal teszteléssel vigyázzunk: bár rendszerint nincs velük baj, volt, hogy a teszt eredménye – akaratunk ellenére – a tesztalany negatív megítélésével járt. Járjunk el körültekintően!

Hány emberrel tesztelünk?

Rövid válasz: legalább 1.

Hosszú válasz: Nielsen szerint 5 felhasználói tesztből már a hibák döntő többsége kinyerhető. Ez egy kvalitatív, nem kvantitatív teszt – nem lesz statisztikai bizonyosságod arról, mennyire jellemző a hiba amit találtál. Az én saját minimumszámom a 3, addig nem szeretek nyilatkozni.

A Prezi iteratív tesztelésében ha egy hiba előfordul, akár már egy felhasználói teszt után is változtatnak a tesztelt prototípuson. Ezt a módszert hívják RITE-módszernek.

Kérdezheted: Egy? Igen, pl. ha a feladathoz be kéne jelentkezni, de te kompletten lehagytad a bejelentkezés gombot, ez már egy felhasználóval kiderül. Ennél sokkal finomabb okosságokat is meg lehet tudni akár egyetlen felhasználótól, ugyanis beszéltetni fogjuk őket: arra vagyunk kiváncsiak, milyen gondolatok, érzések játszódnak le egy ember fejében használat közben, és hasonló jelek kiválthatnak hasonló gondolatokat más emberekben is – érezni fogod!

Mit tesztelünk?

Nem csak szoftvert lehet, de elsőre érdemesebb azzal kezdeni 

Első körben mindig kész szoftvert teszteljünk: legyen az a saját vagy piaci konkurenciánk szoftvere. 

Később akár egy rakás kézi rajz vagy színes cetli felett is tudunk tesztelni (ahogy tette ezt pl. Könczöl Eszter a GE-nél), sőt, én rendszeresen tesztelek egyetlen vázlatos rajzból álló prototípusokat is. 

Mi az a tesztfeladat?

A „kattintgassa meg” nem user test. 

Egy user testhez mindig tartozik egy vagy több, a szoftver szempontjából valós életbeli feladat. 

A szoftver szempontjából nem valós életbeli az a feladat, amely a szoftver belső működését feltételezi.

„Ha a bejárati ajtó mellett lévő csengőt kéne teszteltetnem, két szót biztos nem ejtenék ki teszt közben: bejárati ajtó és csengő”

Laufer László (UX Breakfast, 2014 szeptember)

Tipikus tesztfeladatok:

• Nagyanyjához utazik péntek munka után Kaposvárra. Vásároljon vonatjegyet (tesztcélpont: MÁV Start jegyvásárló rendszer)
• Lejár a bérlete ötödikén, vásároljon újat (tesztcélpont: BKV jegyautomaták)
• X dolgot akar csinálni. A google-ba beírta, hogy X, az ön által most tesztelt honlap jött fel első találati eredményként. Próbálja meg vele megoldani X-et! (bármi ami pl. 30 napos próbaverziós, X pl. lehet képernyőfelvevő userteszthez 🙂

A jó tesztfeladat tartalmaz valamennyi konkrétumot, de nem túl sokat. Pl. ha egy e-boltot tesztelünk (GRoby, Tesco Online), nem árt egy bevásárlólistát előállítanunk, vagy legalábbis belőni mondjuk egy elkészítendő ételt. Azt is lehet, hogy ezt az alany hozza magával (pl. tegnap esti bevásárlás megismétlése online).

A tesztfeladatokat néha kerettörténetekbe szervezzük. A kerettörténetnek van

• egy főszereplője, akit a tesztalany játszik el
• egy célja, amit meg akar valósítani
• kontextusa /  korlátozó tényezői, amik a teszt kereteit biztosítják (pl. ha még nem vagyunk bent a Google-ben az adott feladatra, viszont nem konkurenciatesztet akarunk végezni, játszhatjuk hogy a mi oldalunk jött be első találatként)

Ez adja a szimulációt.

Lehetséges, hogy a feladat nagyon is valós, ekkor felügyelt környezetnek hívjuk ezt, ahol az elemek megfigyelhetőek. Példa: ha az illetőnek tényleg kell vennie egy BKV bérletet mostazonnal 🙂

Hány tesztfeladat? Milyen hosszúak legyenek?

Az emberi figyelem korlátai miatt egy jó teszt felnőttekkel maximum nettó 20 perces.

Egy prototípus-teszt van hogy 3 perc alatt lezajlik, máshol 4-5 feladat is végrehajtható ennyi idő alatt, de van hogy egyetlen feladatra is túl korlátozónak tűnik ez a kitétel.

Ne feledjük el, hogy egy jól használható szoftverben a folyamatokat amúgy is érdemes maximum negyed óránként otthagyható részfeladatokra bontani, pont az említett figyelemkorlátok miatt. Ha nem férünk bele, gondolkozzunk jól van-e ez így!

Hol teszteljünk?

Bárhol. Rendszeresen szoktam kosárlabdameccseken állva tesztelni, vagy épp a Gozsdu udvar környékének kocsmáiban, első tesztre azonban azt javasolnám, lehetőleg ülve, egy asztal környékén, ne túl zajos környezetben kerüljön sor – az ugyanis zavarná a felvételt.

Kiválóan megfelel tetszőleges meetingszoba, konyha, kávézó vagy pláza foodcourt asztalsora (csúcsidőn kívül).

Hogyan tesztelünk?

A user tesztelés 3 ökölszabálya

• A szoftvert teszteljük, nem a user-t
• Nincs Feedback – Pókerarc
• Gondolkodtasd hangosan

Térjünk ki egyesével ezekre

A szoftvert teszteljük, nem a user-t

A usertesztelés egy zárt ajtós pszichológiai viselkedésteszt, amely a felhasználó-gép interakciót teszteli. Óhatatlanul kiderülnek a felhasználókról is dolgok. Egy userteszten minden csak és kizárólag a szoftver hibája lehet. Mindig gondoljunk abba: amibe egy felhasználó belebukik, belebukhat másik is!

Ezt minden esetben mondjuk is el a tesztalanynak:

itt minden hiba a szoftver lelkén szárad, ha valami nem megy, az a szoftvert minősíti, semmiképp sem engem vagy téged, itt és most nem tudsz hibázni. 

Sokan mondják, hogy az első feladatok között valami szándékosan lehetetlent (de nem lehetetlennek látszót) kell adni, hogy a tesztalany természetesnek érezze a hibázást. 

Olyat is tanácsolnak, hazudjuk azt, hogy a szoftvert nem mi terveztük, sőt, közünk nincs a céghez: bár ez az amerikaiaknál tényleg fontos lehet, én az őszinteség híve vagyok: mondjuk azt, hogy „tudjuk, hogy teli van hibákkal, amit most fogunk cserélni / a fejlesztés már előbbre tart”, esetleg „a prototípusra nem volt túl sok idő, ne számíts rá hogy bármi is működik benne”. Az esetek többségében a helyzet valóban ez eleve.

Nincs Feedback – Pókerarc

Valós élethelyzetet szimulálunk: egy valós élethelyzetben nincs senki aki kijavítaná a felhasználót, segítene neki, vagy a kérdéseire válaszolna.

Ne válaszoljunk a felhasználó rendszert érintő kérdéseire érdemben! Ha kérdez, nyugodt hangon figyelmeztessük, hogy a tényleges felhasználók mögött se fog ülni senki. Esetleg kérdezzünk vissza: „te mit tennél ebben az esetben?” „szerinted miért van ez így?” „Számodra ez hogy lenne logikus?” „Te mire számítanál?„, stb. Természetesen ez nem vonatkozik arra, ha pl. egy pohár vizet kér…

Üljünk úgy hogy a felhasználó ne lássa a testbeszédünket! A testbeszédünk sokmindent elárulhat arról, hogy mi az, ami nem elképzeléseink szerint alakul. Ha a fogszívást, felnyögést sikerül is megúsznunk valahogy, testünk még ezer módon kommunikálhatja meglepődésünket. A legjobb, ha a felhasználó mögé ülünk úgy, hogy még lássuk az általa használt felületet, és halljuk amit mond, de ő ne lássa a mi arckifejezésünket. 

Ne terelgessük a felhasználót! Ha a felhasználó nem találja meg magától a dolgokat, az bizony usability hiba.

Hagyjuk a felhasználót hibázni! Amíg szó szerint életveszélyes helyzet nem áll elő, a felhasználó igenis bukdácsoljon – más is fog, pont ezért tesztelünk.

Az is rendben van, ha nem sikerül megoldani a feladatot! Ez is egy teszteredmény! Ne akarjuk minden áron megoldatni!

Persze, ha kevés felhasználóval van csak lehetőségünk tesztelni, és a tesztalany önmagától már semmiképp nem jutna tovább, néha kénytelenek vagyunk súgni. Ekkor az adott tesztfeladatot könyveljük el bukottnak, mintha a felhasználó nem tudta volna megoldani, és dolgozzunk a megoldáson a következő iterációban!

A kérdések nem megválaszolása is olyasmi, amit előre illik közni a tesztalannyal. Pl. így:

ha kérdésed van, kérdezz bármikor bármit nyugodtan, és ha tehetem, válaszolok. Kérlek, vedd figyelembe viszont hogy a való életben se ül a felhasználók mögött senki, így néhány kérdésedre esetleg nem fogok tudni válaszolni, a kérdésfelvetéseid viszont nagyon is fontosak számunkra.

Gondolkodtasd hangosan

A felhasználói élmény azon gondolatok (és érzések) összessége, amit egy felhasználó a használat során átél. 

Ahhoz, hogy képet kapjunk arról, mi is ez az élmény, ami belül történik, a leginkább célra vezető mód, ha valós időben, folyamatosan beszéltetjük róla a tesztalanyt.

szeretnélek megkérni, hogy amennyire csak lehet, a teszt folyamán gondolkozz hangosan: mondd, mire nézel épp, mit keresel, mit próbálsz elérni, mit gondolsz, mit érzel. Ezzel sokat segítesz a problémák megértésében. 

Amennyiben a felhasználó már jóideje csendben van, esetleg feltehetünk neki kérdéseket:

• most min gondolkodsz?
• (váltásnál) mit látsz most?
• mit szeretnél elérni?
• mit keresel?

a kérdések megfogalmazásával csínján kell bánni, feleslegesen ne zökkentsük ki a felhasználót gondolatmenetéből. Próbáljuk meg inkább megtalálni a réseket.

Különösen prototípustesztelésnél (pl. papírprototípus) hasznos, ha a felhasználót megkérdezzük a művelet elvégzése előtt, mire számít. pl. ha azt mondja, ő erre a gombra katinttana, megkérdezhetjük, mi az, amire számít, mi fog történni, majd miután eljátszottuk az interakciót (pl. lapot cseréltünk), megkérdezhetjük, mi az amit szerinte lát, és hogy ez mennyire van összhangban azzal, amit gondolt. 

Jutalmazás

Mint minden felhasználókutatási feladatnál, itt is érdemes a tesztalanyt a teszt végével megköszönni. Erre tipikusan pénz, utalvány, céges merch vagy élelmiszer való – e-commerce körökben megszokott, hogy egyszerűen a teszt során megvásárolt dolgokat ingyen odaadjuk (pl. kártyafeltöltéssel, vagy 100%-os kuponnal).

A felhasználó tesztelés nem nyereményjáték: nem pusztán a „sikeres” tesztfeladat végrehajtást jutalmazzuk, hanem mindenkit, aki megpróbálta! Abból tanulunk a legtöbbet, akiknek kevésbé, sőt, akiknek egyáltalán nem sikerül! Az is információ persze, ha valami elsőre megy…

Az eredmények tálalása

Az eredmények tálalására első alkalommal én leginkább a „ragasztós” módszert szoktam javasolni, ami azt jelenti, hogy a felvétel egy fogyasztásra előkészített (pl. összevágott, feliratozott, 10 percbe maximalizált) változatát elindítjuk a kivetítőn/monitoron, miközben minden érdekeltet (ügyfelet, programozókat) a helyiségbe terelünk és olyan székbe ültetjük amiből a kétoldalú ragasztó hatására nem lehet hamar felállni. Mozidélután!

Készüljünk fel: az első nagy felfedezések élőben végignézése előtt mindenkinek lenne jobb dolga. E-mailben elküldeni felesleges, kilinkelni felesleges, szinte kizárólag az explicit végignézetés segít. 

A helyzet utána rendszerint azonnal és drámaian változik, főleg, ha több tesztalanyunk is ugyanarra az eredményre jutott.

Ezután már el lehet gondolkozni a teszteredmények írásbeli sommázásán, a főbb felfedezések, alanyok szájából elhangzó kulcsmondatok kiemelésén, a „beletekerős” youtube-videók (jobbklikk -> Copy video URL at current time) linkelésén.

További információk

• Elsődleges információforrás Steve Krug: Rocket Surgery Made Easy című munkája. 
• Hasznosak ezek ingyenesen letölthető mellékletei is
• A UXPin nemrégiben publikált egy angol nyelvű Usability Test Kit-et
• Lin Wang guerilla tesztjét a Spotify-ról nem lehet elégszer linkelni
• Az Ubuntu 2010-ben végzett Rhythmbox tesztje ennél hivatalosabb formátum („attached pdf”)

Bónuszkontent

A két leggyakrabban használt tartalmat, Krug felvétel beleegyező nyilatkozatát és tesztforgatókönyvét lefordítottam magyarra, és Google Docs-ként most közreadom. 

Fontos dolgok:

• A magyar adatvédelmi szabályok ennél bonyolultabbak, adatkezelési nyilatkozat és társai is kéne, de általában jó lesz – ha jobb kell, keress egy ügyvédet
• Jogi garanciát nem vállalok semmire
• A fordítás hevenyészett és részben átdolgozott, egyfelől modernizált (mobilappok, tárolási idő…), másfelől igyekeztem belevinni azokat a stíluselemeket amiket én szoktam mondani tesztelés közben
• Ettől még a Copyright Steve Krug-é, a fordítást „Fair Use” jelleggel, oktatási célból tettem közzé, az eredeti forrás megjelelölésével, mindenféle szerzői jogomról lemondok

Cserébe egyet kérek: kezdj el tesztelni most!

* bár szeretek a TechSmith-nek reklámot adni, mert a Camtasia egy életmentő eszköz volt sok esetben, mac-en sokan nyersen a quicktime-ot használják, Mac OS Yosemite esetén már mobilhoz sem kell Reflector, Windowsra is van pár eszköz, de volt hogy egyszerűen a mobilomat kitámasztotam egy doboz facsavarral felvenni a laptopot.

** nyilván lehet kifinomultabbnak lenni, kezdő tesztelő ne válogasson. Nem kell, hogy a felhasználó „technikai” ember legyen a legtöbb ember a világon nem az, nem mintha számítana. 

Az illusztrációként használt kép Luca Mascaro munkája, a sketchin UX cégnél készült. A szerző által biztosított Creative Commons jogok gyakorlásával került felhasználásra.