MetenU: Rating the Severity of Usability Problems

Als slechts 1 op de 1000 gebruikers een probleem met een website heeft, dan is het een klein probleem.

Als die zin je stoort, dan zou dat zo moeten zijn.

Het kan zijn dat dat ene probleem ertoe heeft geleid dat de financiële gegevens van een bezoeker per ongeluk op de website zijn geplaatst, zodat de hele wereld ze kan zien.

Of het kan een kleine aarzeling zijn met een label op een obscuur deel van een website.

Het behoort tot de verantwoordelijkheid van gebruikerservaringsprofessionals om ontwikkelaars te helpen beslissingen te nemen over wat te repareren.

Rekening houden met probleemfrequentie en ernst zijn twee kritieke ingrediënten bij het communiceren van het belang van bruikbaarheidsproblemen. Het zijn ook twee van de inputs die nodig zijn voor een Failure Modes Effects Analysis (FMEA), een meer gestructureerd prioriteringsproces.

Problem Frequency

Het meten van de frequentie van een probleem is over het algemeen rechttoe rechtaan. Neem het aantal gebruikers dat op een probleem stuit, gedeeld door het totale aantal gebruikers. Bijvoorbeeld, als 1 op de 5 gebruikers een probleem tegenkomt, is de probleemfrequentie .20, of 20%. De probleemfrequentie kan dan worden gepresenteerd in een matrix per gebruiker en per probleem. Het kan ook worden gebruikt om de steekproefgrootte te schatten die nodig is om een bepaald percentage van de problemen te ontdekken.

Probleemernst

Het beoordelen van de ernst van een probleem is minder objectief dan het vinden van de probleemfrequentie. Er zijn een aantal manieren om de ernst van een probleem te beoordelen. Ik heb een paar van de populairste benaderingen uit de literatuur geselecteerd, en zet die af tegen de methode die wij bij Measuring Usability gebruiken.

Er zijn weliswaar verschillen in aanpak, maar in het algemeen stelt elke methode een vergelijkbare structuur voor: een reeks geordende categorieën die de impact van het probleem op de gebruiker weerspiegelen, van klein tot groot.

Jakob Nielsen

Jakob Nielsen stelde enkele decennia geleden de volgende schaal van vier stappen voor:

0 = Ik ben het er helemaal niet mee eens dat dit een bruikbaarheidsprobleem is
1 = Alleen een cosmetisch probleem: hoeft niet te worden opgelost tenzij er extra tijd beschikbaar is voor het project
2 = Een klein bruikbaarheidsprobleem: het oplossen hiervan moet lage prioriteit krijgen
3 = Groot usability probleem: belangrijk om op te lossen, dus moet hoge prioriteit krijgen
4 = Usability catastrofe: absoluut oplossen voordat product kan worden uitgebracht

Jeff Rubin

In Jeff’s invloedrijke boek uit 1994 schetste hij de volgende schaal voor probleemernst:

4: Onbruikbaar: De gebruiker kan of wil een bepaald onderdeel van het product niet gebruiken vanwege de manier waarop het product is ontworpen en geïmplementeerd.
3: Ernstig: De gebruiker zal het product hier waarschijnlijk gebruiken of proberen te gebruiken, maar zal ernstig beperkt worden in zijn of haar mogelijkheden daartoe.
2: Matig: De gebruiker zal het product in de meeste gevallen kunnen gebruiken, maar zal enige matige moeite moeten doen om het probleem te omzeilen.
1: Irritant: Het probleem treedt slechts met tussenpozen op, kan gemakkelijk worden omzeild, of is afhankelijk van een norm die buiten de grenzen van het product ligt. Kan ook een cosmetisch probleem zijn.

Dumas en Redish

Joe Dumas en Ginny Redish bieden in hun baanbrekende boek, A Practical Guide to Usability Testing, een vergelijkbare indeling als Rubin en Nielsen, maar voegen aan de problemen een globale versus lokale dimensie toe. Het idee is dat een probleem dat de wereldwijde navigatie van een website beïnvloedt, kritischer is dan een lokaal probleem dat slechts één pagina beïnvloedt.

Niveau 1: verhindert het voltooien van een taak
Niveau 2: veroorzaakt aanzienlijke vertraging en frustratie
Niveau 3: problemen hebben een gering effect op de bruikbaarheid
Niveau 4: subtiel en mogelijk verbeteringen/suggesties

Chauncey Wilson

Chauncey Wilson stelt voor om de schaal voor de ernst van bruikbaarheid af te stemmen op de ernst van bugtracking-systemen in een bedrijf. Hij biedt een vijf-punt schaal met de volgende niveaus. Eerder gebruikte hij een soortgelijke vierpuntsvariant.

Niveau 1: Catastrofale fout met onherroepelijk verlies van gegevens of schade aan de hardware of software tot gevolg. Het probleem kan leiden tot grootschalige storingen waardoor veel mensen hun werk niet meer kunnen doen. De prestaties zijn zo slecht dat het systeem de bedrijfsdoelen niet kan bereiken.
Level 2: Ernstig probleem, met mogelijk verlies van gegevens tot gevolg. Gebruiker heeft geen workaround voor het probleem. De prestaties zijn zo slecht dat het systeem algemeen als ‘erbarmelijk’ wordt beschouwd.
Level 3: Matig probleem dat geen permanent verlies van gegevens veroorzaakt, maar wel tijdverspilling. Er is een work-around voor het probleem. Interne inconsistenties leiden tot hogere leer- of foutpercentages. Een belangrijke functie of kenmerk werkt niet zoals verwacht.
Level 4: Klein maar irritant probleem. Over het algemeen veroorzaakt het verlies van gegevens, maar het probleem vertraagt gebruikers enigszins. Er zijn minimale schendingen van richtlijnen die het uiterlijk of de perceptie beïnvloeden, en fouten die te herstellen zijn.
Level 5: Minimale fout. Het probleem is zeldzaam en veroorzaakt geen gegevensverlies of groot tijdverlies. Klein cosmetisch of consistentieprobleem.

De Wilson en Dumas & Roodachtige schalen hebben het ernstigere probleem met lagere getallen. Dat komt omdat in de begindagen van de informatica ernstige bugs “niveau 1 bugs” werden genoemd en die moesten worden verholpen voordat het product werd vrijgegeven (Dumas, persoonlijke communicatie 2013). In deze schaal worden de problemen gedefinieerd in termen van gegevensverlies in plaats van hun impact op de prestaties of emotionele toestand van gebruikers.

Molich & Jeffries

Rolf Molich is beroemd om zijn reeks vergelijkende bruikbaarheidsevaluaties (CUE). Hij is ook beroemd om het beoordelen van en het schrijven (vaak kritisch) over de kwaliteit van bruikbaarheidsrapporten. Hij en Robin Jeffries kwamen met een driepuntsschaal.

1. Minor: vertraagt de gebruiker kort.
2. Ernstig: vertraagt de gebruiker aanzienlijk, maar stelt hem uiteindelijk in staat de taak te voltooien.
3. Catastrofaal: verhindert de gebruiker zijn taak te voltooien.

Deze driepuntsbenadering is eenvoudiger dan andere, maar neigt ertoe sterk te vertrouwen op hoe het probleem de tijd beïnvloedt die de taak in beslag neemt.

Onze aanpak

Oorspronkelijk begonnen we met een zevenpuntsschaal waarop beoordelaars de ernst van het probleem een waarde toekenden van cosmetisch (1) tot catastrofaal (7), maar we ontdekten dat het moeilijk was om gemakkelijk onderscheid te maken tussen niveau 2 en 6. We brachten dit terug tot een vierpuntsschaal, vergelijkbaar met Rubin, Nielsen en Dumas/Redish hierboven, en behandelden ze meer als categorieën dan als een continuüm.

Hoewel er veel minder onduidelijkheid was met vier punten, vonden we nog steeds een troebel onderscheid tussen de twee middelste niveaus in zowel het toekennen van de ernst als het rapporteren van de niveaus van problemen aan cliënten.

Dus brachten we onze schaal van ernst terug tot slechts drie niveaus, samen met één voor inzichten, suggesties van gebruikers of positieve attributen.

1. Minor: Veroorzaakt enige aarzeling of lichte irritatie.
2. Matig: Veroorzaakt incidentele mislukking van taken voor sommige gebruikers; veroorzaakt vertragingen en matige irritatie.
3. Kritisch: Leidt tot het mislukken van taken. Veroorzaakt extreme irritatie bij gebruikers.

Inzicht/Suggestie/Positief: Gebruikers noemen een idee of opmerking die de algehele ervaring doet of zou kunnen verbeteren.

Samenvatting

Ik heb verkorte versies van deze schalen hieronder in de tabel gezet om de overeenkomsten in sommige van de termen en niveaus te laten zien. Ik heb de schalen ook zo uitgelijnd dat hogere cijfers ernstigere problemen aangeven.

Enige lessen uit deze probleemernstniveaus:

1. Streef niet naar het juiste aantal categorieën of labels: Drie categorieën is waarschijnlijk voldoende, maar het samenvoegen van schalen met bug tracking niveaus of het hebben van meer niveaus om meer interne buy-in te genereren zijn beide legitieme redenen om meer punten te hebben. Als u eenmaal een systeem hebt gekozen, probeer er dan aan vast te houden om vergelijking in de loop van de tijd mogelijk te maken.
2. Er zal nog steeds inter-beoordelaar onenigheid en beoordelingsgesprekken zijn: Dit zijn ruwe gidsen, geen precieze instrumenten. Verschillende beoordelaars zullen het oneens zijn, ondanks de duidelijkheid van de ernstniveaus. Een van de beste benaderingen is om meerdere beoordelaars de ernst onafhankelijk van elkaar te laten beoordelen, de overeenstemming te berekenen, en dan het gemiddelde van de beoordelingen te berekenen.
3. De aan elk niveau toegekende cijfers zijn enigszins arbitrair: Maak je niet al te druk over de vraag of problemen met een hogere ernst een hoger of een lager cijfer moeten krijgen. Ik geef de voorkeur aan het laatste, maar het is de volgorde die betekenis heeft. Hoewel de intervallen tussen de ernstgraden 1, 2 en 3 waarschijnlijk verschillend zijn, kunnen de rangen worden gebruikt voor aanvullende analyse bij het vergelijken van verschillende beoordelaars of van de ernst en de frequentie van problemen.
4. Vergeet de positieven niet: Dumas, Molich & Jeffries schreven een overtuigend artikel waarin werd gesproken over de noodzaak om te wijzen op positieve bevindingen. Hoewel een bruikbaarheidstest meestal bedoeld is om problemen aan het licht te brengen, is het begrijpen van de positieve bevindingen een aanmoediging voor de ontwikkelaars en komt u of uw team niet over als de voortdurende voorbodes van slecht nieuws.
5. Behandel frequentie apart van ernst: We rapporteren de frequentie van een issue samen met de ernst ervan. Waar mogelijk, laten we een aparte analist de ernst van een probleem beoordelen zonder de frequentie te kennen – een onderwerp voor een toekomstige blog.