Egy csapatjáték foglalási és fizetései felületének megtervezésekor a felhasználói teszteknek köszönhetően szerencsére még a kezdeti szakaszban sikerült ráeszmélnünk arra, hogy nem lehet mindenre gondolni, és olykor olyan dolog felett is óhatatlanul elsiklunk, ami utólag magától értetődőnek tűnhet. Ebben az írásunkban szeretnénk bemutatni, hogy hogyan segített minket a felhasználó tesztelés abban, hogy a lehető leghamarabb észrevegyük hol kell irányt váltanunk a tervezésben, hogy minél hamarabb a validáltan használható és értékes funkciók kerülhessenek előtérbe.
Mire vagyunk kíváncsiak a felhasználó teszten?
Amikor felhasználó tesztnek akarjuk alávetni a termékünket, akkor próbára tesszük, szélnek eresztjük azt az elképzelésünket, amit gondosan a megrendelővel együtt kitaláltunk. Egy ilyen teszt előtt fontos érzelemmentessé válnunk attól, amit alkottunk, mert könnyen lehet, hogy rájövünk, mégse ez lesz a helyes irány. Fontos továbbá, hogy olyan embert hívjunk el alanynak, aki nem IT területről jött, és semmiképp sem UX / UI terevező, mert nem szakmai teszt alá vetjük a felületet, hanem legfőképp a használhatósági problémákra, a potenciális felhasználóink benyomásaira vagyunk kíváncsiak. Olyan gondolkodásmóddal kell hozzáállni a teszthez, hogy nem tőlük várjuk el, hogy megoldják a problémát, hanem magában a probléma feltárásában számítunk rájuk.
Egy ilyen teszt előtt kiválasztjuk a terméknek azt az útvonalát, ami döntő fontosságú a felhasználói élmény megítélésnek szempontjából, és ezt az utat leképezzük egy kattintható prototípussal. A prototípus összeállításához a képernyőterveken elvárt kattintható elemeket, mint például a gombokat, beviteli mezőket, linkeket és média tartalmakat ténylegesen interaktívvá alakítjuk, és ezáltal kiváltjuk azt az érzetet az emberekből, amit egy éles szoftver tud nyújtani. A prototípus előállításához már számos eszköz áll rendelkezésünkre (Figma, Axure, Adobe Xd), amikkel egyetlen kódsor nélkül fel lehet építeni az elképzelt koncepciót. Ez olyan, mintha elkészítenénk egy homokvárat mielőtt felépítenénk véglegesen. Ennek a homokvárnak egy nagyon jó tulajdonsága, hogy ha nem elégíti ki kellően az igényeket, illetve nem olyan, mint ahogy elképzeltük, akkor könnyebb átalakítani, mint amikor már elkezd épülni a végleges formája felé.
Hogyan készüljünk fel?
Ahhoz, hogy próbára tegyük, amit alkottunk, szükségünk van bátor és szabadidejüket feláldozó alanyokra, akik készek szembeszállni a gondosan kitalált forgatókönyvünk végkimenetelével. Mivel a projektünk nemzetközi piacra célzott, a lehető legdiverzebb nemzetiségű alanyokat próbáltunk összehívni. Így történt, hogy holland, amerikai, angol, feröeri és magyar alanyokat kerestünk fel, hogy kipróbálhassák a csapatjátéknak szánt felületeinket.
Amint sikerült őket a kitűzött időpontra elcsábítani, a gondosan kitalált forgatókönyvünk segítségével árgus szemekkel és gyermeki kíváncsisággal kértük meg őket arra, hogy hajtsanak végre bizonyos feladatokat a felületeinken, és közben arra buzdítottuk őket, hogy gondolkozzanak hangosan. Ilyenkor szokott megtörténni az “ahaaa”, vagyis a “hogy a fenébe nem gondoltunk erre” pillanat, ami az egészet izgalmassá teszi.
Hogyan is tudtunk elsiklani afelett, hogy nem írtuk sehová a helyszín nyitvatartását? Mindenre (is) próbáltunk gondolni, de ez kimaradt az egyenletből. Amikor azt gondoltuk, hogy a gyakran ismételt kérdések minden felmerülő kételyre választ szolgál, rájövünk, hogy mégsem. A sokféle nemzetiségből fakadóan valaki hiányolta az ÁFA megjelölését a végleges árból, valaki abszolút elsiklott felette. Azt gondoltuk, hogy egy olyan színt választottunk a szabad foglalások megjelölésére, ami teljesen egyértelmű lesz mindenki számára, de nem így volt.
Jelen projekt esetében 5 ilyen tesztet hajtottunk végre, amiből sok hasznos tanulságot vontunk le, amiket a következő iterációink során beleépítettünk a termékünkbe. Érdekes volt látni, hogy mennyire másképp gondolkoznak az emberek, kinek mi az egyértelmű, miket értenek félre vagy értenek máshogyan.
Tanulságként levontunk még, hogy egy ilyen teszten olykor-olykor előfordul, hogy az alanyunk nem csak használhatósági problémákra világít rá. A mi esetünkben a viking témájú csapatjátékhoz használt fotókhoz begyűjtöttük a megjegyzéseiket és tovább gondoltuk őket a tervezésben.
Hogyan prezentáld az eredményt a megrendelő felé?
Számunkra a leghatékonyabb módja a felhasználói tesztek végeredményének bemutatására egy látványos pdf dokumentum volt, ahol felsoroltuk a problémák metszetét, amit könnyen tudtunk az üzlet felé prezentálni. Emellett még elküldjük az interjúkból megírt kivonatokat és képernyő, illetve hangfelvételeket is.
Mikor építsük bele a folyamatba?
Nagyon jó előnye a felhasználói tesztelésnek, hogy bármikor bevethetjük. Legszerencsésebb esetben a termék életútjának már a legelején elkezdjük csinálni akkor, amikor még nem kezdtünk bele a fejlesztésbe, mert ilyenkor “csak” a képernyőterveket iteráljuk. Hiszen gondoljunk csak bele, ha egy olyan terméket kívánunk felhasználói tesztelni, ami már le van fejlesztve, akkor megnöveljük annak kockázatát, hogy költséges lesz a használhatósági problémákból fakadó átalakítások implementálása a termékünkben.
És ez miért jó a megrendelőnek?
Egyrészt a költség szempontok, másrészt az ügyfélelégedettség tekintetében is megéri felhasználókkal tesztelni. Minél hamarabb kijönnek a lehetséges problémák, amik eddig a felszín alá rejtőztek a tervezés során, annál korábban tudunk adaptálni, és a helyes irányba kanyarodni a terméktervezés során. Így a megrendelő a termék átadásakor már egy olyan szoftvert kap, aminek a funkcionalitása a jövőbeli felhasználók által is validálva lett. Ezek a kis validációk és iterációk remek lehetőséget adnak arra, hogy agilis kifejezéssel élve, maximalizáljuk az el nem végzett munka mennyiségét is, egyszerűvé, letisztulttá, és könnyen érthetővé tegyük a terméket, ami által költséget tudunk optimalizálni.
Miért jó nekünk?
A felhasználói tesztek által szerzett tudás egy kiváló lehetőség nekünk arra, hogy validáljuk az elképzeléseinket a termékkel kapcsolatban, hogy mérjük azt, hogy másoknak is egyértelmű-e az elgondolásunk, könnyen követhető-e a szoftver funkcionalitása. Ha bármilyen eltérést fedezünk fel, hamar tudunk adaptálni a felhasználók elvárásaihoz, így a fejlesztő csapatok nem végeznek haszontalan munkát, csak olyat, aminek az értéke már validálva van.
Ezen a projekten és számos más esetben is bebizonyosodott már, hogy a felhasználói tesztek egy termék életének bármely -de legfőképp- az első szakaszában kulcsfontosságú elemként kell, hogy szerepeljenek, hiszen ez megalapozhatja a termék sikerességét. A felhasználók bevonása nélkül csak magunkra és az elképzeléseinkre tudunk hagyatkozni, ami a legtöbb esetben nem fog a valóságra reflektálni.
“We must learn what customers really want, not what they say they want or what we think they should want.” — Eric Ries.
