Nel 1989 Jakob Nielsen, oltre a semplificare le stesse regole di “design usabile” riassumendole in semplici principi euristici, ha proposto di semplificare i test di usabilità.

Negli anni ’80 spesso questi erano complessi e onerosi:

1. Si svolgevano in veri e propri laboratori
2. Utilizzavano molti partecipanti come negli esperimenti scientifici per ottenere indicazioni con elevata attendibilità
3. Si svolgevano su prodotti già in parte implementati, con la conseguenza di dover spendere nuove ore/uomo di programmazione per le modifiche che i test avrebbero reso necessarie.

Nielsen e la Discount Usability

Secondo Nielsen questi vincoli ostacolavano la diffusione su larga scala dell’usabilità. Suggeriva così un approccio alternativo:

• utilizzare molti meno utenti: ad esempio, solo 5 per ogni tornata di test.
• eseguire i test su prototipi (anche cartacei) anziché sui software sviluppati
• focalizzare i test soprattutto sull’osservazione qualitativa dei problemi, anziché sulla misurazione attendibile di aspetti quantitativi dell’esperienza d’uso
• ripeterli più volte (almeno 3) nel corso del processo di progettazione.

Secondo l’approccio di Nielsen, i test di questo tipo non servono a decidere con elevata affidabilità quale interfaccia è migliore fra una versione A e una versione B (attività che richiede effettivamente un numero elevato di utenti). Ma “solo” per far emergere problemi precocemente, quando è più conveniente intervenire e modificare l’interfaccia, in particolare perché non si è ancora investito nell’attività di programmazione.

Questa era la ratio dell’espressione “discount usability” coniata da Nielsen, e che poi è stata ripresa e ulteriormente semplificata da Steve Krug nei suoi libri. Il costo si intende ridotto rispetto all’usabilità “anni ’80”, e non nel senso che non costi niente: ogni attività deve costare il giusto. Tipicamente, fra il 10 e il 20% del budget di progetto (includendo in questo budget non esclusivamente i test, ma anche i test).

Il protocollo eGLU

Ispirato in parte dagli approcci di Nielsen e Krug, il Dipartimento della Funzione Pubblica (DFP) ha dato vita nel 2012 ad un Gruppo di Lavoro per l’Usabilità (GLU). Dal 2013 ho il piacere di coordinare con il collega Simone Borsci un sottogruppo di professionisti e accademici che si è occupato di definire un semplice protocollo, cioè un testo con delle istruzioni operative passo passo, per la progettazione, la conduzione e l’analisi di semplici test di usabilità.

Gli scopi del protocollo

Gli scopi sono due:

1. Anzitutto, diffondere la cultura dell’usabilità. Constatato che, quando il gruppo è nato (ma in tutt’Italia ancor oggi) nella PA spesso i test di usabilità non si sapeva nemmeno cosa fossero, salvo poche e lodevoli eccezioni, si è deciso di spiegare a “inesperti” di che si trattasse.
2. Come strategia di diffusione, si è ritenuto che far capire che con una guida passo-passo anche dei non esperti – come ad esempio i redattori web delle PA -potevano provare a preparare dei test semplificati. Non per sostituirsi agli esperti, come talvolta erroneamente è stato inteso, ma per rendersi conto in prima persona dei problemi di usabilità che altrimenti non sarebbero mai stati evidenziati. In questo modo, provando a eseguire dei semplici test, per quanto semplificati (ma provando comunque a evitare gli errori più comuni per dei profani), l’idea era che i problemi di usabilità sarebbero diventati evidenti a tutti, e sarebbero stati fatti presenti ai responsabili.

In questo modo, nelle successive gare d’appalto, ci sarebbe stata maggior consapevolezza dei problemi legati all’usabilità e si sarebbero potute bandire fra le altre cose delle attività di testing.

L’applicazione in situazioni di mercato

Il Protocollo eGLU è giunto ora alla sua versione 2.1 e la scommessa pare per il momento vinta. La procedura infatti è utilizzata non solo da alcuni enti pubblici internamente, ma anche da aziende che lavorano per gli enti pubblici, perché è diventata sinonimo di “procedura consolidata” e riconosciuta per i test di usabilità nella PA.

Il Protocollo eGLU è stato infatti anche inserito come procedura per l’analisi dell’usabilità all’interno delle linee guida di design per i siti della PA. Ma in quanto procedura di base, può essere estesa a piacere dai professionisti.

Formazione e divulgazione

In quanto frutto di un lavoro pubblico, il Protocollo eGLU è scaricabile e leggibile, con tanto di allegati che aiutano nell’elaborazione dei risultati, sul sito del Dipartimento, ed è dunque utilizzabile da chiunque, sia per il proprio lavoro (da proporre ad enti e aziende) che come attività di autoformazione.

E la formazione è un altro dei capitoli collegati al protocollo: in quanto strumento “riconosciuto”, è ora più facile parlare di test di usabilità in generale e di Protocollo eGLU in particolare anche nella formazione per enti pubblici.

Per chi fosse interessato, su Usabile.it è possibile richiedere una formazione dedicata sui test di usabilità e sul Protocollo eGLU.

Il Protocollo come procedura di base per aggiunte modulari

Nello specifico, una delle caratteristiche su cui abbiamo creduto di impostare il lavoro di stesura del protocollo a partire dalla versione 2.0 è quella della modularità e della sua estendibilità.

Il protocollo eGLU è infatti pensato come una procedura di base che possa prevedere aggiunte ed estensioni di metodo laddove un professionista che lo adotti lo ritenga utile. Ad esempio:

• Si può eseguire un test secondo il Protocollo eGLU, ma scegliere di raccogliere anche i tempi di esecuzione dei task (non trattati in questa procedura, perché impossibili da spiegare a un livello di base), se il tipo di test lo richiede.
• O integrarlo con la rilevazione dei movimenti oculari (se ha senso per il tipo di test).
• O aggiungere questionari di altro tipo (come il SEQ, per esempio).
• O prevedere il calcolo dei click o degli errori.

E’ cioè possibile partire dal Protocollo eGLU, riferimento “compreso” all’interno della PA, per svolgere anche analisi e test più complessi.

Oltre il protocollo: strumenti di HCD nei bandi di gara

E’ sufficiente? No. Oltre alla formazione, che va sempre condotta e portata avanti, sull’argomento, abbiamo preso atto che ogni buon sito dipende in maniera stretta dalla bontà dei processi che lo generano. E quindi abbiamo iniziato a immaginare una guida, un aiuto per l’inserimento di attività HCD all’interno dei capitolati dei bandi pubblici, una volta constatato che questo inserimento è raro e talvolta approssimato.

Questa guida è contenuta nel documento “Le linee guida appalti web HCD” sulla stessa pagina del GLU linee guida.

Gli strumenti offerti (e migliorabili) tolgono ogni alibi

C’è da auspicare una sempre maggior circolazione e diffusione di Protocollo eGLU e delle Linee guida per gli appalti web HCD. Fare test di usabilità all’interno di un progetto web non è infatti una questione di soldi: quelli vengono spesi comunque, solo che senza spenderli per i test si spendono peggio. E’ una questione di volontà, e di capire che questo (assieme alle altre pratiche HCD) è l’unico modo per costruire un sistema digitale veramente utilizzabile dai cittadini ed evitare di buttare i soldi dei progetti come tante volte è stato purtroppo fatto, anche di recente, in Italia.

Ma la novità è che se queste opportunità non verranno colte, non si potrà invocare la mancanza di strumenti o il loro costo: dipenderà esclusivamente delle scelte dei dirigenti e dei responsabili dei progetti.

Credits: L’immagine dell’articolo è tratta dal film Kitchen Stories, che vi consigliamo di vedere.