Test di usabilità, questi sconosciuti

Ripetete con me: usabilità significa test di usabilità. Non opinioni su che cosa sia l’usabilità, non patetiche intenzioni di design. L’usabilità si misura nei fatti, ovvero là dove gli utenti incontrano le nostre interfacce. E per passare dalle parole ai fatti esiste solo un modo: i test. Per parlare di questo oggi ospito sul mio blog, con molto piacere, un post di Raffaella Roviglioni, esperta di usabilità e User experience, nonché mia collaboratrice su progetti intranet. Se volete saperne di più la scheda di Raffaella è più sotto (oltre che nella sezione “collaboratori“).

L’usabilità delle intranet: testarla per migliorarla

di Raffaella Roviglioni

Una intranet usabile è quella che consente alle persone di svolgere facilmente e velocemente i loro compiti quotidiani e le loro attività online. Rispetto ai siti web le intranet dovrebbero essere molto più usabili, per una serie di motivi: abbiamo un controllo completo sull’ambiente digitale a disposizione (piattaforma e pc), conosciamo in dettaglio gli utenti (nostri colleghi) e riscontriamo in modo diretto il vantaggio di investire sull’usabilità per guadagnare in efficienza.

E invece non è così, come ci racconta Nielsen. Come mai? Spesso le intranet scontano problemi legati da una parte a un’architettura obsoleta, non pensata per i veri utilizzatori della piattaforma, e dall’altra a una navigazione difficoltosa per la presenza di tanti applicativi sviluppati con tecnologie che non si parlano tra loro (o, se lo fanno, complicano ancora di più le cose).

Che cosa possiamo fare in questa situazione? La cosa migliore è sempre quella di pianificare una serie di test con gli utenti sia per monitorare la situazione attuale (ed eventualmente decidere di intraprendere un percorso di riprogettazione) sia per affiancare un lavoro di progettazione ex-novo.

test di usabilità

Primo passo: i compiti da svolgere
In entrambi i casi, una delle prime cose da fare è individuare i compiti da far svolgere alle persone durante i test. Non dobbiamo inventarli di sana pianta, ma piuttosto “ricavarli” a partire dalle azioni quotidiane che le persone svolgono sulla Intranet. Ecco, a titolo puramente indicativo, alcuni esempi di azioni:

  • Hai bisogno rapidamente del numero di Roberto Rossi per chiamarla al telefono.
  • Devi organizzare una riunione con 5 partecipanti (te compreso) dalle 10:00 alle 11:00 di venerdì prossimo (20 aprile).
  • Ti arriva un avviso sull’e-mail perché un tuo collaboratore ha richiesto una settimana di ferie. Segui il link fino a questa pagina e procedi.
  • Tuo figlio si è ammalato e vuoi avere informazioni sul congedo per malattia.

Se non avete ancora questo elenco buttate giù una lista a partire da quello che è possibile fare sulla vostra intranet: richiedere delle ferie, scaricare il modulo per il rimborso spese, verificare la busta paga, cercare un collega per avere il suo numero  interno, e così via. Sottoponete poi questo elenco ai vostri colleghi per verificarlo e completarlo, e a partire da ciascun elemento scrivete un caso d’uso verosimile.

I risultati migliori si hanno quando si riesce a descrivere un compito sotto forma di storia, in cui la persona è protagonista dell’azione da svolgere.

Secondo passo: le persone
Una volta elaborati i compiti, bisogna trovare le persone giuste su cui testarli. Normalmente una sessione con 5-6 persone è sufficiente per far emergere i problemi di usabilità principali. L’importante è che siano un campione rappresentativo della popolazione aziendale: scegliete persone con ruolo, anzianità aziendale, sesso e nazionalità diversi.

Test di usabilità su carta

Terzo passo: il setting
I test possono essere svolti  direttamente presso le postazioni dei colleghi, utile soprattutto se state valutando la intranet attuale, oppure in una postazione ad hoc allestita in una sala riunioni in cui farete accomodare di volta in volta i partecipanti. Questa seconda modalità è usata in particolare quando si testano prototipi cartacei durante un processo di progettazione (ecco un video che ne illustra uno).

Se volete essere rigorosi sarebbe meglio registrare la sessione in video, inquadrando sia il viso delle persone che lo schermo o il prototipo con cui stanno interagendo. In caso non sia proprio possibile registrate almeno l’audio e usate un osservatore che prenda appunti dettagliati su cosa fa il partecipante in ciascun compito.

Quarto passo: i ruoli
Nello svolgimento del test è utile ricordare il vostro molteplice ruolo:

  • Osservatore: non dovete interferire con il compito del partecipante, quindi lo osserverete in totale silenzio, senza mai suggerire alcunché (nemmeno con il linguaggio non verbale!). Segnatevi su un quaderno eventuali domande da fare alla fine del test, se volete chiarimenti o spiegazioni.
  • Moderatore: sta a voi tenere il tempo, quindi eventualmente fermare un compito che si dilunga troppo o saltare al successivo se il partecipante si blocca e non riesce a finirlo. Siete anche voi a mimare le interazioni della piattaforma qualora stiate svolgendo un test su carta.
  • Facilitatore: tenete sempre a mente che è il partecipante che si sentirà sotto esame anche se voi state testando un applicativo e non le sue capacità. Rassicuratelo all’inizio e durante tutto il test, e accompagnate le sue osservazioni annuendo e prendendo appunti.

Quinto passo: l’analisi dei risultati
L’analisi dei risultati può essere più o meno schematica, a seconda dei casi e delle necessità. Anche quando volete ottenere dati sintetici, il mio consiglio è di non saltare alle conclusioni basandovi sulle proprie impressioni a caldo: spesso la memoria ci inganna, specie se siamo noi i progettisti. Pur non essendo un test quantitativo, a volte è utile ricorrere ad alcuni indicatori numerici come punto di partenza:

  • Il successo nel completamento del compito, che può essere espresso come 0/1 o come scala, per esempio da 0 a 3 (non completato, completato con molta frustrazione, completato con alcuni ostacoli e difficoltà, completato senza problemi).
  • Il tempo di svolgimento del compito, magari confrontato con un riferimento valutato in precedenza, o per testare le vostre aspettative.

Le conclusioni che si possono trarre dai test sono molteplici: potete essere fiduciosi che un compito che nessuno dei partecipanti è riuscito a svolgere sia un campanello d’allarme di qualcosa che va risolto e alla svelta. Se invece solo alcune persone hanno incontrato delle difficoltà specifiche, il problema forse si presenta solo per alcuni tipi di utenti o in situazioni particolari.

Anche se meno prioritario del caso precedente può comunque essere d’impatto per l’usabilità della vostra intranet, quindi sondate ulteriormente ripetendo test mirati, con altre persone, fino a che non l’abbiate compreso in profondità.

Ecco, per finire, qualche libro utile per approfondire l’argomento:

Buona lettura e buoni test a tutti 🙂

 

Raffaella Roviglioni

Raffaella Roviglioni

[Raffaella Roviglioni]

Si è occupata di web e progettazione, nell’ultimo decennio, prima in veste di curatrice di contenuti e in seguito come architetto dell’informazione, web project manager e infine come User Experience Designer. Arriva a questa professione da un percorso non esattamente ortodosso, ma che rappresenta per lei un arricchimento e una spinta a non smettere mai di imparare e di mettersi in discussione.
E’ convinta di contribuire a rendere il mondo un posto migliore grazie a una progettazione che mette al centro le persone. Attualmente lavora come consulente freelance progettando portali e applicazioni intranet, siti web, app e giochi, oltre a interessarsi di sistemi più complessi di service design.

Mail: raffaella@roviglioni.it
LinkedIn: http://it.linkedin.com/in/raffirovi
Web: http://roviglioni.it
Twitter: @raffiro