Használhatósági tesztelés

A használhatósági tesztelés egy olyan kutatási módszer, amelynek során valós vagy reprezentatív felhasználók próbálnak meg meghatározott feladatokat elvégezni egy termék, prototípus vagy weboldal segítségével, miközben egy megfigyelő rögzíti, hogy hol sikerül nekik, hol nehézségeik vannak, és hogyan írják le a tapasztalataikat, jellemzően hangosan gondolkodva munka közben. A felmérésekkel vagy elemzésekkel ellentétben, amelyek a felhasználók cselekedeteit vagy mondásait utólag jelentik, a használhatósági tesztelés közvetlenül és kontextusban figyeli meg a viselkedést, így ez az egyik legközvetlenebb módja annak, hogy megállapítsuk, egy felület valóban könnyen érthető és használható-e, vagy csak feltételezi azt a csapat, amely építette.

A módszer azért fontos, mert az interfészproblémák, amelyek láthatatlanok a tervezők számára, gyakran nyilvánvalóak az első alkalommal használók számára. Ezt a hiányosságot gyakran a tudás átkával magyarázzák, ahol a termékkel mélyen ismerő tervezők és érdekelt felek nehezen veszik észre azokat a kétértelműségeket, amelyekkel egy új felhasználó azonnal találkozik. A széles körben idézett használhatósági kutatások kimutatták, hogy akár öt résztvevővel végzett tesztelés is jellemzően feltárja az adott interfészben jelen lévő használhatósági problémák nagy többségét, gyakran nagyjából 85 százalékát, ezért a használhatósági tesztelést általában kis, iteratív résztvevői körökkel végzik, nem pedig nagyszabású tanulmányokkal, lehetővé téve a csapatok számára, hogy gyorsan teszteljenek, javítsanak és újra teszteljenek, ahelyett, hogy egy nagy minta összegyűjtésére várnának, mielőtt bármilyen változtatást végrehajtanának.

A használhatósági tesztelést többféle formátumban végzik: moderált tesztelés, ahol a facilitátor valós időben, személyesen vagy videón keresztül vezeti végig a résztvevőket a feladatokon, és további kérdéseket tehet fel a zavaró pillanatok tisztázása érdekében; moderálatlan távoli tesztelés, ahol a résztvevők önállóan végzik el a feladatokat egy tesztelési platform segítségével, képernyőjüket és hangjukat rögzítve későbbi áttekintés céljából, ami gyorsabb és olcsóbb adatgyűjtést kínál anélkül, hogy a pillanatnyi reakciókat kellene felmérni; és gerilla tesztelés, egy informális, alacsony költségű megközelítés, amely gyors visszajelzést gyűjt az elérhető résztvevőktől, például kollégáktól vagy járókelőktől, ami hasznos a korai szakaszban történő validációhoz, amikor a teljes körű tanulmány még nem indokolt. A tesztelési munkamenetek jellemzően konkrét, realisztikus feladatforgatókönyvek köré épülnek, nem pedig nyílt végű feltárásra, és a sikert olyan mérésekkel értékelik, mint a feladat elvégzésének aránya, a feladatra fordított idő, a hibák száma és a résztvevő szubjektív használati könnyűségére vonatkozó értékelése, amelyet gyakran egy szabványosított eszközzel, például a Rendszer Használhatósági Skálájával gyűjtenek.

Gyakori tévhit, hogy a használhatósági tesztelés és az A/B tesztelés ugyanazt a célt szolgálja, holott valójában különböző kérdésekre adnak választ különböző szakaszokban: a használhatósági tesztelés azonosítja, hogy a felhasználók miért küzdenek egy felülettel, mielőtt az elkészülne vagy széles körben bevezetnék, jellemzően egy prototípuson vagy egy már élő, de nem validált terv alapján, míg az A/B tesztelés azt méri, hogy a már elkészített változatok közül melyik teljesít jobban nagy léptékben, miután a forgalom elérhetővé vált. Magának a használhatósági tesztelésnek egy gyakori buktatója olyan résztvevők toborzása, akik nem reprezentatívak a tényleges célközönségre, például egy vállalati szoftver munkafolyamat tesztelése olyan résztvevőkkel, akik nem ismerik az alapul szolgáló üzleti folyamatot, ami félrevezető súrlódási pontokat eredményez, amelyek a valódi célfelhasználóknál nem jelennének meg. Egy másik gyakori hiba, hogy a résztvevőket tippekkel vagy javaslatokkal vezetik egy munkamenet során, ahelyett, hogy hagynák őket küzdeni, és őszintén megfigyelnék ezt a küzdelmet, egy másik gyakori hiba, amely aláássa az eredmények érvényességét.

A CRO-n belül és UX Tanácsadási megbízások során a használhatósági tesztelést gyakran alkalmazzák diagnosztikai céllal, hogy megértsék, miért teljesít alul egy meglévő folyamat, valamint validációként, mielőtt egy újratervezést széles körben bevezetnének, egy új prototípust tesztelve egy kis, reprezentatív felhasználói csoporttal, hogy feltárják a főbb használhatósági problémákat, mielőtt a fejlesztési és tesztelési erőforrásokat egy teljes A/B tesztelésre fordítanák. A használhatósági tesztelés eredményeit jellemzően egy priorizált problémalistába szintetizálják, amelyet gyakran a súlyosság és a résztvevők száma szerint rangsorolnak, majd ezt közvetlenül beépítik a tervezési változtatásokba vagy a kísérleti hipotézisekbe, amelyek az ügyfél tágabb optimalizálási ütemtervét alkotják.

Egy konkrét példa szemlélteti a módszer hatékonyságát: egy öt résztvevővel tesztelő csapat, amely egy újratervezett fiókbeállítás-oldalt tesztel, megfigyelheti, hogy az ötből négyen nem találják az értesítési beállítások módosítására szolgáló lehetőséget, mindegyikük egymástól függetlenül ugyanabban a rossz helyen keres a felületen. Ez az egyetlen, rendkívül következetes megállapítás, amely egy kis és olcsó tesztelési körből származik, általában elegendő indok a beállítás áthelyezésére a bevezetés előtt, anélkül, hogy nagyobb és időigényesebb tanulmányra lenne szükség annak megerősítéséhez, hogy amiről már korábban is megfigyelték, hogy megbízhatóan és ismételten kudarcot vall szinte minden tesztelt résztvevőnél.