A használhatósági tesztelés méltatlanul kapta azt a hírnevet, hogy drága és lassú. Amikor az emberek azt hallják, hogy „felhasználókutatás”, egyirányú tükörre, jegyzettömbös moderátorra és kéthetes ütemtervre gondolnak. A tesztelésnek ez a változata létezik, és megvan a maga haszna – de nem ez az, amire a legtöbb termékcsapatnak a legtöbbször szüksége van.
Amire a legtöbb csapatnak szüksége van, az egyszerűbb: öt felhasználó, egy Figma-prototípus vagy egy staging környezet, egy videóhívás, és munkamenetenként 45 perc. Jól csinálva ez a launch előtt felszínre hozza a súlyos használhatósági problémák többségét. Következetesen végezve – akár sprintenként egyszer is – olyan halmozódó termékminőség-javulást eredményez, amelyet semmilyen indulás utáni analitika nem tud pótolni.
Íme, hogyan csináld nulláról.
Öt résztvevő a megfelelő szám a legtöbb használhatósági teszthez. Jakob Nielsen kutatása megállapította, hogy öt felhasználó a használhatósági problémák nagyjából 85%-át felfedi, utána pedig csökkenő a hozadék. A tervezési folyamat különböző pontjain tartott, egyenként öt felhasználós három munkamenet értékesebb, mint egy tizenöt fős.
A toborzási kritériumok fontosabbak, mint a szám. Egy öt emberrel végzett használhatósági teszt, akik szorosan megfelelnek a célfelhasználónak, valódi problémákat fog felfedni. Egy tizenöt emberrel végzett teszt, akik nem felelnek meg, zajt fog termelni. Határozz meg két-három szűrési kritériumot – szerep, használati kontextus, technikai jártasság szintje –, és tartsd magad hozzájuk.
A legtöbb csapat számára a leggyorsabb toborzási útvonal az, ha e-mailt írsz olyan meglévő felhasználóknak, akik engedélyt adtak a kapcsolatfelvételre. Ajánlj fel szerény ösztönzőt – egy £20-os ajándékutalvány elegendő egy 45 perces munkamenetért. Igyekezz ugyanarra a hétre ütemezni az üléseket; minél hosszabb idő telik el a toborzás és a tesztelés között, annál magasabb a meg nem jelenők aránya.
A leggyakoribb forgatókönyvírási hiba, hogy a feladatokat utasításként fogalmazzák meg: „Kattints a Beállításokra, majd navigálj az Értesítésekhez, és módosítsd a beállításodat...” Ez megmondja a felhasználónak, mit csináljon, vagyis azt teszteled, hogy képes-e követni az utasításokat, nem pedig azt, hogy a felület intuitív-e.
A feladatokat inkább szituációként írd meg: „Képzeld el, hogy túl sok értesítést kapsz, és csak akkor szeretnél értesítést kapni, ha valaki közvetlenül megemlít téged. Mutasd meg, mit tennél.” Ez valósághű célt ad a felhasználónak, és megfigyelheted, hogyan navigál valójában – azt is, hol zavarodik meg.
A használhatósági teszt moderálásának legnehezebb része, hogy ellenállj a segítési kényszernek. Amikor egy felhasználó összezavarodik, minden ösztönöd azt súgja, hogy ugorj be, és mutasd meg, hova kell kattintani. De a zavar maga az adat. A küszködő felhasználó azt mondja el neked, hogy valami nincs rendben a felülettel – és abban a pillanatban, hogy közbeavatkozol, elveszíted a jelet.
Kérd meg a felhasználókat, hogy az egész munkamenet alatt gondolkodjanak hangosan: „Ahogy haladsz, csak mondd el, mit nézel és mit gondolsz.” Ez folyamatos adatfolyamot ad a mentális modelljükről. Ne csak a hibákat jegyezd fel, hanem a tétovázást is – az a felhasználó, aki három másodpercig habozik, mielőtt a helyes gombra kattint, akkor is felfedett egy tervezési problémát, ha végül sikerrel járt.
A szintézis az a lépés, ahol az érték nagy része keletkezik – és ahol a legtöbb csapat spórol. Az öt munkamenet nyers jegyzetei még nem eredmények. Azzá akkor válnak, ha csapatként értékelitek őket, a megfigyeléseket témák szerint csoportosítjátok, és súlyossági besorolást rendeltek hozzájuk.
Az értékelést ugyanazon a napon tartsd meg, amikor a munkamenetek zajlottak, amíg a megfigyelések frissek. A problémákat három kategóriába sorold: kritikus (a felhasználók nem tudták teljesíteni a feladatot), mérsékelt (a felhasználók teljesítették a feladatot, de jelentős nehézséggel vagy hibával), és csekély (olyan súrlódás, amely nem akadályozta a teljesítést). A kritikus problémákat a kiadás előtt meg kell oldani. A mérsékelt problémákat a következő sprintben kell priorizálni. A csekély problémák a backlogba kerülnek.
Az eredményeket egyetlen oldalon foglald össze: a három legfontosabb kritikus probléma, mindegyikhez legalább két résztvevő bizonyítékával, és mindegyikhez egy javasolt tervezési módosítás. Ami ennél több helyet igényel, az külön dokumentumba tartozik.