MisurareU: Valutare la gravità dei problemi di usabilità

Se solo un utente su 1000 incontra un problema con un sito web, allora è un problema minore.

Se questa frase ti ha infastidito, dovrebbe esserlo.

Potrebbe essere che quel singolo problema ha portato le informazioni finanziarie di un visitatore ad essere inavvertitamente pubblicate sul sito web perché il mondo lo veda.

O potrebbe essere una leggera esitazione con un’etichetta su una parte oscura di un sito web.

Fa parte della responsabilità dei professionisti dell’esperienza utente aiutare gli sviluppatori a prendere decisioni su cosa risolvere.

Tener conto della frequenza e della gravità del problema sono due ingredienti critici quando si comunica l’importanza dei problemi di usabilità. Sono anche due degli input necessari per una Failure Modes Effects Analysis (FMEA), un processo di prioritizzazione più strutturato.

Frequenza del problema

Misurare la frequenza di un problema è generalmente semplice. Prendete il numero di utenti che incontrano un problema diviso per il numero totale di utenti. Per esempio, se 1 utente su 5 incontra un problema, la frequenza del problema è .20, o 20%. La frequenza dei problemi può essere presentata in una matrice utente per problema. Può anche essere usata per stimare la dimensione del campione necessaria per scoprire una certa percentuale di problemi.

La gravità del problema

Valutare la gravità di un problema è meno obiettivo che trovare la frequenza del problema. Ci sono diversi modi per assegnare valutazioni di gravità. Ho selezionato alcuni degli approcci più popolari descritti in letteratura, e li confronterò con il metodo che usiamo a Measuring Usability.

Mentre ci sono differenze negli approcci, in generale ogni metodo propone una struttura simile: un insieme di categorie ordinate che riflettono l’impatto che il problema ha sull’utente, da minore a maggiore.

Jakob Nielsen

Jakob Nielsen ha proposto la seguente scala a quattro livelli qualche decennio fa:

0 = Non sono d’accordo che questo sia un problema di usabilità
1 = Solo un problema cosmetico: non deve essere risolto a meno che non sia disponibile tempo extra sul progetto
2 = Problema di usabilità minore: risolvere questo dovrebbe avere bassa priorità
3 = Grande problema di usabilità: importante da risolvere, quindi dovrebbe avere alta priorità
4 = Catastrofe di usabilità: imperativo risolvere questo problema prima che il prodotto possa essere rilasciato

Jeff Rubin

Nell’influente libro di Jeff del 1994, ha delineato la seguente scala di gravità del problema:

4: Non utilizzabile: L’utente non è in grado o non vuole usare una particolare parte del prodotto a causa del modo in cui il prodotto è stato progettato e implementato.
3: Grave: L’utente probabilmente userà o tenterà di usare il prodotto in questo caso, ma sarà gravemente limitato nella sua capacità di farlo.
2: Moderato: L’utente sarà in grado di usare il prodotto nella maggior parte dei casi, ma dovrà intraprendere qualche moderato sforzo per aggirare il problema.
1: Irritante: Il problema si verifica solo a intermittenza, può essere aggirato facilmente, o dipende da uno standard che è fuori dai confini del prodotto. Potrebbe anche essere un problema cosmetico.

Dumas e Redish

Joe Dumas e Ginny Redish, nel loro libro seminale, A Practical Guide to Usability Testing, offrono una categorizzazione simile a quella di Rubin e Nielsen ma aggiungono una dimensione globale contro locale ai problemi. L’idea è che se un problema colpisce la navigazione globale di un sito web, diventa più critico di un problema locale che colpisce solo, diciamo, una pagina.

Livello 1: Impedisce il completamento del compito
Livello 2: Crea un ritardo significativo e frustrazione
Livello 3: I problemi hanno un effetto minore sull’usabilità
Livello 4: Sottile e possibili miglioramenti/suggerimenti

Chauncey Wilson

Chauncey Wilson suggerisce che le scale di gravità dell’usabilità dovrebbero corrispondere alla valutazione della gravità dei sistemi di tracciamento dei bug in una società. Egli offre una scala a cinque punti con i seguenti livelli. In precedenza, ha usato una variante simile a quattro punti.

Livello 1: errore catastrofico che causa una perdita irrevocabile di dati o danni all’hardware o al software. Il problema potrebbe portare a guasti su larga scala che impediscono a molte persone di fare il loro lavoro. La performance è così scadente che il sistema non può realizzare gli obiettivi di business.
Livello 2: Problema grave, che causa la possibile perdita di dati. L’utente non ha soluzioni al problema. Le prestazioni sono così scarse che il sistema è universalmente considerato “pietoso”.
Livello 3: Problema moderato che non causa perdita permanente di dati, ma perdita di tempo. C’è una soluzione al problema. Le incongruenze interne provocano un aumento dei tassi di apprendimento o di errore. Una funzione o caratteristica importante non funziona come previsto.
Livello 4: Problema minore ma irritante. Generalmente causa la perdita di dati, ma il problema rallenta leggermente gli utenti. Ci sono minime violazioni delle linee guida che influenzano l’aspetto o la percezione, ed errori che sono recuperabili.
Livello 5: Errore minimo. Il problema è raro e non causa perdite di dati o grandi perdite di tempo. Minore problema cosmetico o di coerenza.

Le bilance Wilson e Dumas &rossa hanno il problema più grave con i numeri più bassi. Questo perché nei primi tempi dell’informatica, i bug gravi erano chiamati “bug di livello 1” e dovevano essere risolti prima del rilascio del prodotto (Dumas, comunicazione personale 2013). In questa scala, i problemi sono definiti in termini di perdita di dati piuttosto che il loro impatto sulle prestazioni degli utenti o sullo stato emotivo.

Molich & Jeffries

Rolf Molich è famoso per la sua serie di valutazioni comparative di usabilità (CUE). È anche famoso per rivedere e scrivere (spesso in modo critico) sulla qualità dei rapporti di usabilità. Lui e Robin Jeffries hanno proposto una scala a tre punti.

1. Minore: ritarda brevemente l’utente.
2. Grave: ritarda significativamente l’utente ma alla fine gli permette di completare il compito.
3. Catastrofico: impedisce all’utente di completare il suo compito.

Questo approccio a tre punti è più semplice di altri ma tende a fare molto affidamento su come il problema influisce sul tempo sul compito.

Il nostro approccio

In origine abbiamo iniziato con una scala di valutazione a 7 punti in cui i valutatori assegnavano alla gravità del problema un valore da cosmetico (1) a catastrofico (7), ma abbiamo scoperto che era difficile distinguere facilmente tra i livelli 2 e 6. Abbiamo ridotto questo ad una scala a quattro punti simile a Rubin, Nielsen e Dumas/Redish e li abbiamo trattati più come categorie che come un continuum.

Mentre c’era molta meno ambiguità con quattro punti, abbiamo ancora trovato una distinzione oscura tra i due livelli medi sia nell’assegnare la gravità che nel riportare i livelli di problemi ai clienti.

Così abbiamo ridotto la nostra scala di gravità a soli tre livelli, insieme a uno per le intuizioni, i suggerimenti degli utenti o gli attributi positivi.

1. Minore: Causa qualche esitazione o leggera irritazione.
2. Moderato: Causa il fallimento occasionale del compito per alcuni utenti; causa ritardi e moderata irritazione.
3. Critico: Porta al fallimento del compito. Causa estrema irritazione all’utente.

Insight/Suggestion/Positive: Gli utenti menzionano un’idea o un’osservazione che fa o potrebbe migliorare l’esperienza complessiva.

Sommario

Ho messo versioni abbreviate di queste scale sotto nella tabella per mostrare le similitudini in alcuni termini e livelli. Ho anche allineato le scale in modo che i numeri più alti indichino problemi più gravi.

Alcune lezioni da questi livelli di gravità del problema:

1. Non ossessionatevi nel trovare il giusto numero di categorie o etichette: Tre categorie sono probabilmente sufficienti, ma fondere le scale con i livelli di bug tracking o avere più livelli per generare più buy-in interno sono entrambe ragioni legittime per avere più punti. Una volta scelto un sistema, provate ad attenervi ad esso per permettere il confronto nel tempo.
2. Ci sarà ancora disaccordo tra i vari revisori e chiamate di giudizio: Queste sono guide approssimative, non strumenti precisi. Diversi valutatori non saranno d’accordo, nonostante la chiarezza dei livelli di gravità. Uno dei migliori approcci è quello di avere più valutatori che valutano la gravità in modo indipendente, calcolare l’accordo e poi fare la media delle valutazioni.
3. I numeri assegnati ad ogni livello sono in qualche modo arbitrari: Non ossessionatevi troppo sul fatto che i problemi di maggiore gravità debbano avere numeri più alti o più bassi. Io preferisco la seconda, ma è l’ordine che ha significato. Mentre gli intervalli tra le gravità di 1, 2 e 3 sono probabilmente diversi, i ranghi possono essere usati per ulteriori analisi quando si confrontano diversi valutatori o la gravità e la frequenza dei problemi.
4. Non dimenticare i positivi: Dumas, Molich & Jeffries ha scritto un articolo persuasivo parlando della necessità di evidenziare i risultati positivi. Mentre un test di usabilità è di solito inteso a scoprire i problemi, comprendere gli aspetti positivi incoraggia gli sviluppatori e non fa apparire voi o il vostro team come i costanti forieri di cattive notizie.
5. Trattate la frequenza separatamente dalla gravità: Riportiamo la frequenza di un problema insieme alla sua gravità. Quando possibile, abbiamo un analista separato che valuta la gravità di un problema senza conoscere la sua frequenza – un argomento per un futuro blog.