MérésU:

Ha 1000 felhasználóból csak egy találkozik problémával egy weboldalon, akkor ez egy kisebb probléma.

Ha ez a mondat zavarja Önt, akkor ezt kell tennie.

Ez lehet, hogy ez az egyetlen probléma azt eredményezte, hogy egy látogató pénzügyi adatai véletlenül felkerültek a weboldalra, hogy a világ láthassa.

Vagy lehet egy kis tétovázás a weboldal egy homályos részén lévő címkével kapcsolatban.

A felhasználói élményért felelős szakemberek felelősségének része, hogy segítsenek a fejlesztőknek döntést hozni arról, hogy mit kell javítani.

A probléma gyakoriságának és súlyosságának figyelembe vétele két kritikus összetevő a használhatósági problémák fontosságának kommunikálásakor. Ezek egyben a hibamód-hatáselemzéshez (FMEA), egy strukturáltabb priorizálási folyamathoz szükséges két bemenet is.

Probléma gyakorisága

A probléma gyakoriságának mérése általában egyszerű. Vegyük a problémával találkozó felhasználók számát osztva a felhasználók teljes számával. Ha például 5 felhasználóból 1 találkozik problémával, akkor a probléma gyakorisága 0,20, azaz 20%. A probléma gyakoriságát ezután egy felhasználónkénti problémamátrixban lehet bemutatni. Arra is használható, hogy megbecsüljük a problémák egy bizonyos százalékának felfedezéséhez szükséges minta méretét.

Probléma súlyossága

A probléma súlyosságának értékelése kevésbé objektív, mint a probléma gyakoriságának meghatározása. A súlyossági besorolások kiosztásának többféle módja van. Kiválasztottam néhányat a szakirodalomban leírt népszerűbb megközelítések közül, és ezeket szembeállítom az általunk a Measuring Usability-nél használt módszerrel.

Míg a megközelítések között vannak különbségek, általában mindegyik módszer hasonló struktúrát javasol: a probléma felhasználóra gyakorolt hatását tükröző, rendezett kategóriák halmazát a kisebbtől a nagyobbig.

Jakob Nielsen

Jakob Nielsen néhány évtizeddel ezelőtt a következő négyfokozatú skálát javasolta:

0 = Egyáltalán nem értek egyet azzal, hogy ez egy használhatósági probléma
1 = Csak kozmetikai probléma: nem kell javítani, hacsak nem áll rendelkezésre több idő a projektben
2 = Kisebb használhatósági probléma: A javításnak alacsony prioritást kell adni
3 = Jelentős használhatósági probléma: fontos a javítás, ezért magas prioritást kell adni
4 = Használhatósági katasztrófa: feltétlenül ki kell javítani, mielőtt a termék megjelenik

Jeff Rubin

Jeff 1994-ben megjelent nagy hatású könyvében a következő skálát vázolta fel a probléma súlyosságára:

4: Használhatatlan: A felhasználó nem tudja vagy nem akarja használni a termék egy adott részét a termék tervezési és megvalósítási módja miatt.
3: Súlyos: A felhasználó valószínűleg használni fogja a terméket, vagy megkísérli használni, de erősen korlátozva lesz ebben a képességében.
2: Mérsékelt: A felhasználó a legtöbb esetben képes lesz használni a terméket, de mérsékelt erőfeszítéseket kell tennie a probléma megkerülése érdekében.
1: Irritáló: A probléma csak időszakosan fordul elő, könnyen megkerülhető, vagy olyan szabványtól függ, amely kívül esik a termék határain. Lehet kozmetikai probléma is.

Dumas és Redish

Joe Dumas és Ginny Redish A Practical Guide to Usability Testing (A gyakorlati útmutató a használhatósági teszteléshez) című korszakalkotó könyvükben hasonló kategorizálást kínálnak, mint Rubin és Nielsen, de a problémákhoz egy globális versus helyi dimenziót is hozzáadnak. Az elképzelés szerint, ha egy probléma a weboldal globális navigációját érinti, az kritikusabbá válik, mint egy helyi probléma, amely csak mondjuk egy oldalt érint.

1. szint: Megakadályozza a feladat elvégzését
2. szint: Jelentős késedelmet és frusztrációt okoz
3. szint: A problémák kisebb hatással vannak a használhatóságra
4. szint: Finom és lehetséges javítások/javaslatok

Chauncey Wilson

Chauncey Wilson azt javasolja, hogy a használhatósági súlyossági skáláknak meg kellene egyezniük a vállalat hibakövető rendszereinek súlyossági besorolásával. Ő egy ötfokozatú skálát javasol a következő szintekkel. Korábban egy hasonló négypontos változatot használt.

1. szint: Katasztrofális hiba, amely visszavonhatatlan adatvesztést vagy a hardver vagy a szoftver károsodását okozza. A probléma nagymértékű meghibásodást eredményezhet, amely sok embert akadályoz a munkájában. A teljesítmény annyira rossz, hogy a rendszer nem tudja teljesíteni az üzleti célokat.
2. szint: Súlyos probléma, amely lehetséges adatvesztést okoz. A felhasználónak nincs megoldási lehetősége a problémára. A teljesítmény annyira rossz, hogy a rendszert általánosan “szánalmasnak” tartják.
3. szint: Mérsékelt probléma, amely nem okoz tartós adatvesztést, de időveszteséget okoz. Van megoldás a problémára. A belső következetlenségek megnövekedett tanulási vagy hibaarányt eredményeznek. Egy fontos funkció vagy funkció nem működik az elvárásoknak megfelelően.
4. szint: Kisebb, de bosszantó probléma. Általában adatvesztést okoz, de a probléma kissé lelassítja a felhasználókat. Az irányelvek minimális megsértése, amely hatással van a megjelenésre vagy az érzékelésre, és a hibák helyreállíthatók.
5. szint: Minimális hiba. A probléma ritka, és nem okoz adatvesztést vagy jelentős időveszteséget. Kisebb kozmetikai vagy konzisztenciaprobléma.

A Wilson és Dumas & Vöröses skáláknál az alacsonyabb számoknál súlyosabb a probléma. Ennek az az oka, hogy a számítástechnika korai időszakában a súlyos hibákat “1-es szintű hibáknak” nevezték, és ezeket még a termék kiadása előtt ki kellett javítani (Dumas, személyes közlés 2013). Ezen a skálán a problémákat inkább az adatvesztés szempontjából határozzák meg, mint a felhasználók teljesítményére vagy érzelmi állapotára gyakorolt hatásuk szempontjából.

Molich & Jeffries

Rolf Molich az összehasonlító használhatósági értékelések (CUE) sorozatáról híres. Híres arról is, hogy a használhatósági jelentések minőségét vizsgálja és írja (gyakran kritikusan). Ő és Robin Jeffries egy hárompontos skálát ajánlott fel.

1. Kisebb: rövid ideig késlelteti a felhasználót.
2. Súlyos: jelentősen késlelteti a felhasználót, de végül lehetővé teszi számára a feladat elvégzését.
3. Katasztrofális: megakadályozza, hogy a felhasználó elvégezze a feladatát.

Ez a hárompontos megközelítés egyszerűbb, mint mások, de hajlamos nagymértékben támaszkodni arra, hogy a probléma hogyan befolyásolja a feladat elvégzésének idejét.

A mi megközelítésünk

Eredetileg egy 7 pontos értékelési skálával kezdtük, ahol az értékelők a probléma súlyosságát a kozmetikától (1) a katasztrofálisig (7) terjedő értékkel értékelték, de úgy találtuk, hogy nehéz volt könnyen különbséget tenni a 2. és 6. szint között. Ezt a Rubin, Nielsen és Dumas/Redish fenti skálájához hasonló négypontos skálára csökkentettük, és inkább kategóriákként, mint kontinuumként kezeltük őket.

Míg a négy pontnál sokkal kevesebb volt a kétértelműség, még mindig homályos különbséget találtunk a két középső szint között mind a súlyosság hozzárendelése, mind a problémák szintjeinek az ügyfeleknek való jelentése során.

Ezért a súlyossági skálánkat mindössze három szintre csökkentettük, valamint egy szintre a meglátások, a felhasználói javaslatok vagy a pozitív tulajdonságok esetében.

1. Kisebb: Némi tétovázást vagy enyhe irritációt okoz.
2. Mérsékelt: Alkalmanként feladatmeghiúsulást okoz egyes felhasználóknál; késedelmet és mérsékelt irritációt okoz.
3. Kritikus: A feladat meghiúsulásához vezet. A felhasználónak rendkívüli irritációt okoz.

Észrevétel/javaslat/pozitív: A felhasználók olyan ötletet vagy észrevételt említenek, amely javítja vagy javíthatná az általános élményt.

Összefoglaló

E skálák rövidített változatait helyeztem el a táblázatban, hogy megmutassam a hasonlóságokat néhány kifejezés és szint között. A skálákat is összehangoltam, hogy a magasabb számok súlyosabb problémákat jelezzenek.

Néhány tanulság ezekből a problémasúlyossági szintekből:

1. Ne legyen rögeszméje a kategóriák vagy címkék megfelelő számának megtalálása: Három kategória valószínűleg elegendő, de a skálák összevonása a hibakövetési szintekkel vagy a több szint létrehozása a nagyobb belső elfogadás érdekében mindkettő jogos ok arra, hogy több pont legyen. Ha egyszer kiválasztott egy rendszert, próbáljon meg ragaszkodni hozzá, hogy idővel összehasonlítható legyen.
2. Az értékelők közötti nézeteltérések és ítélkezések továbbra is fennállnak: Ezek durva útmutatók, nem pedig pontos eszközök. A különböző értékelők a súlyossági szintek egyértelműsége ellenére nem fognak egyetérteni. Az egyik legjobb megközelítés az, ha több értékelő egymástól függetlenül értékeli a súlyosságot, kiszámítja az egyetértést, majd átlagolja az értékeléseket.
3. Az egyes szintekhez rendelt számok némileg önkényesek: Ne törődjön túlságosan azzal, hogy a magasabb súlyosságú problémáknak magasabb vagy alacsonyabb számokat kell-e kapniuk. Én inkább az utóbbit részesítem előnyben, de a sorrendnek van jelentősége. Bár az 1, 2 és 3 súlyossági fokozatok közötti intervallumok valószínűleg eltérőek, a rangsorok további elemzéshez használhatók, amikor különböző értékelőket vagy a problémák súlyosságát és gyakoriságát hasonlítjuk össze.
4. Ne feledkezzünk meg a pozitívumokról: Dumas, Molich & Jeffries meggyőző cikket írt, amelyben a pozitív eredmények kiemelésének szükségességéről beszél. Bár a használhatósági teszt általában a problémák feltárására szolgál, a pozitívumok megértése bátorítja a fejlesztőket, és nem teszi Önt vagy a csapatát a rossz hírek állandó hírnökeinek.
5. A gyakoriságot külön kezelje a súlyosságtól: Egy probléma gyakoriságát a súlyosságával együtt jelentjük. Ha lehetséges, egy külön elemzővel értékeltetjük a probléma súlyosságát anélkül, hogy ismernénk annak gyakoriságát – ez egy jövőbeli blog témája.