A használhatósági tesztelésnek nem érdemelt híre van, hogy drága és lassú. Amikor emberek "felhasználó kutatásról" hallanak, egy egyirányú tükörre, egy vágólappal rendelkező moderátorra, és egy kéthetes ütemtervre gondolnak. Ez a verzió létezik és van értelme — de nem ez az a verzió, amelyre a legtöbb termékcsapatnak szüksége van a legtöbb időben.
Az a verzió, amelyre a legtöbb csapatnak szüksége van, egyszerűbb: öt felhasználó, egy Figma prototípus vagy egy staging környezet, egy videóhívás, és 45 perc munkamenet. Jól végezve ez felfedi a súlyos használhatósági problémák többségét a szállítás előtt. Következetesen végezve — még egy sprint-ben is — olyan összeadódó termékminőség-javulást hoz létre, amelyet semmilyen post-launch analitika nem lehet másolni.
Íme hogyan futtatsd azt a nulláról.
Öt résztvevő a megfelelő szám a legtöbb használhatósági teszthez. Jakob Nielsen kutatása azt állapította meg, hogy öt felhasználó felfedi a használhatósági problémák körülbelül 85%-át, az ezt követő csökkenő visszatérésekkel. Az a tervezésfolyamat különböző pontjaiban futtatott öt felhasználós három munkamenet értékesebb, mint egy tizenöt személyes.
A toborzás kritériumai fontosabbak, mint a szám. Egy használhatósági teszt öt emberrel, akik szorosan illeszkednek a célfelhasználóhoz, valódi problémákat fog felfedni. Egy teszt tizenöt emberrel, akik nem illeszkednek, zajt fog generálni. Határozzon meg két vagy három szűrési kritériumot — szerep, használat kontextusa, technikai kényelem szintje — és tartsd magad hozzájuk.
A legtöbb csapat leggyorsabb toborzási útvonala az olyan meglévő felhasználók emailezése, akik adtak kapcsolatfelvételi engedélyt. Ajánlj egy szerény ösztönzőt — egy 20 £-es ajándékutalvány elegendő egy 45 perces munkamenethez. Tervezzél munkameneteket ugyanarra a hétre; minél nagyobb a toborzás és a tesztelés közötti távolság, annál magasabb a nem-megjelenési arány.
A legelterjedtebb scriptírási hiba az, hogy a feladatokat utasítások formájában írjuk le: "Kattints a Beállításokra, majd navigálj az Értesítésekhez, és módosítsd az előnézetet..." Ez azt mondja meg a felhasználónak, hogy mit csináljon, ami azt jelenti, hogy azt teszteled, hogy tudnak-e utasítások követni, nem azt, hogy a felület intuitív-e.
Helyette forgatókönyvként írj feladatokat: "Képzelje el, hogy túl sok értesítést kap, és csak azokat szeretné kapni, amelyekről valaki közvetlenül megemlít. Mutasd meg, mit tennél." Ez reális célt ad a felhasználónak, és azt figyelheted meg, hogyan navigálnak valóban — beleértve azt, hogy hol zavarosodnak.
A használhatósági teszt moderálásának legnehezebb része a segítségnyújtási vágy elleni ellenállás. Amikor egy felhasználó zavaros, minden ösztön azt mondja, hogy ugorj be és mutasd meg, hova kell kattintani. De a zavarossá az adatok. Egy küszködő felhasználó azt mondja neked, hogy valami baj van a felülettel — és abban a pillanatban, amikor beavatkozol, elveszíted a jelet.
Kérd meg a felhasználókat, hogy gondolkozzanak hangosan az egész munkamenet alatt: "Ahogy haladsz, csak mondd el nekem, mit nézel és mit gondolsz." Ez a mentális modelljükről folyamatos adatáramlást nyújt. Jegyzeteld fel nemcsak a hibákat, hanem a tétovázásokat — egy felhasználó, aki három másodpercig szünetel, mielőtt a helyes gombra kattintana, még akkor is felfedett egy tervezési problémát, még akkor sem, ha végül sikerült.
A szintézis lépése az, ahol az érték nagy része jön létre — és ahol a legtöbb csapat sarkallódik. Az öt munkamenetből származó nyers jegyzetei nem eredmények. Akkor válnak eredménnyé, amikor a csapatként megbeszélész, témák szerinti megfigyeléseket csoportosítasz, és súlyosságbesorolást rendelsz.
Végezd el a megbeszélést ugyanazon a napon, mint a munkameneteket, míg a megfigyelések frissek. Csoportosítsd a problémákat három kosárba: kritikus (felhasználók nem tudták befejezni a feladatot), mérsékelt (felhasználók befejezték a feladatot, de jelentős nehézséggel vagy hibával), és apró (súrlódás, amely nem akadályozta a befejezést). A kritikus problémákat a szállítás előtt meg kell oldani. A mérsékelt problémákat a következő sprint-ben kell prioritálni. Az apró kérdések a teendőlistára kerülnek.
Írj fel az eredményeket egyetlen oldalon: a legjobb három kritikus probléma, legalább két résztvevőtől származó bizonyítékkal, és egy javasolt tervezési módosítással mindegyikhez. Bármi, aminek több helyre van szüksége, mint amely egy külön dokumentumba tartozik.