Su questo stesso tema ho scritto un post su medium, con un taglio meno tecnico, rivolto principalmente alle persone che lavorano nella pubblica amministrazione.

Il post è stato citato nell'articolo di presentazione del nuovo toolkit di Designers Italia, dedicato alla valutazione dello stato dell'arte: benchmark e valutazione euristica.

Il modello comuni

Nel 2022, grazie alla collaborazione con Fifth Beat, ho avuto la possibilità di partecipare alla progettazione della versione 2.0 del modello per il sito e i servizi digitali dei Comuni italiani di Designers Italia, progetto ambizioso e sfidante. Sfidante, impegnativo ma appassionante. Lavorare con le persone di Designers Italia e con i colleghi e amici di Fifth Beat (Raffaele Boiano, Martin Milizia , Daniele Muscella, Gloria Díaz Alonso, Nina Zanarelli e Letizia Sechi) è stato un piacere.
Le attività portate a termine sono state molte:

• benchmark - inspiration analysis dei siti e dei servizi digitali dei comuni italiani
• interviste ad alcuni esperti di dominio
• valutazione euristica e test usabilità di un sito comunale che costituisce lo stato dell'arte della versione 1.0
• proposte di miglioramento a valle di valutazione e test
• analisi della versione 1.0 del documento di architettura dell'informazione (as-is)
• revisione del documento di architettura dell'informazione, integrazione delle ontologie e delle tassonomie
• progettazione di 5 modelli di servizi
• creazione dei prototipi
• documentazione

Valutazione del modello

Per comprendere le potenzialità e i limiti della versione 1.0 del modello comuni si è deciso di sottoporre ad analisi ispettiva e test di usabilità il sito di un comune capoluogo di provincia che aveva implementato il modello e che costituiva lo "stato dell'arte" dell'adozione. Poiché il fine dell'analisi (valutazione e test) non era quello di valutare il comune ma il modello, nel riportare i dati delle valutazioni abbiamo omesso i riferimenti al comune. La nostra ricerca era infatti finalizzata a comprendere i limiti del modello 1.0 al fine di proporre delle modifiche capaci di migliorarlo.

Metodi di valutazione

Possiamo distinguere 4 tipi di valutazione dell'usabilità di un prodotto [Fernandez et. al. (2011); Bussolon (2021)]:

• i metodi empirici, che coinvolgono un limitato numero di persone che rappresentano gli utenti:
  • i test di usabilità, in cui ai partecipanti è chiesto di portare a termine dei compiti usando la tecnica del thinking aloud, ovvero pensare a voce alta;
  • i metodi di indagine in cui, attraverso brevi interviste e questionari, si raccolgono le loro opinioni;
    generalmente in una sessione vengono usate entrambe le tecniche: breve intervista iniziale, test di usabilità, breve intervista e questionario finale
• i metodi ispettivi, in cui uno o più esperti di usabilità analizzano il prodotto in base a dei princìpi, a delle euristiche o a delle linee guida;
• i metodi automatici, in cui vengono utilizzati dei software per analizzare il codice - ad esempio per valutare il rispetto di alcune regole di accessibilità;
• i metodi analitici, in cui si analizzano i comportamenti degli utenti raccolti attraverso gli analytics, ovvero le statistiche d'uso delle applicazioni.

La valutazione euristica è il più noto fra i metodi ispettivi. Le euristiche sono un numero ristretto di regole piuttosto generali di usabilità, ovvero princìpi che hanno un elevato valore predittivo perché rappresentano la sintesi dei problemi di usabilità più frequenti, organizzati in categorie. Le euristiche di Nielsen, ad esempio, sono ottentute tramite analisi fattoriale su una base di 249 problemi riscontrati in studi di vario tipo [Nielsen et. al. (1990)]. La valutazione euristica consiste nel verificare quanto una interfaccia rispetti queste regole.

Una delle difficoltà della valutazione euristica è che, essendo i princìpi piuttosto generali, lasciano ampio spazio di interpretazione, riducendone la validità diagnostica [Jaspers (2009)].
Una possibile soluzione, che è quella che è stata adottata in questa circostanza, è di integrare i princìpi generali con delle regole più specifiche, più facili da verificare [Khajouei et. al. (2018)].

Pertanto, prima di procedere alla valutazione, ho elaborato una traccia che ci guidasse nella analisi, integrando fonti diverse:

• le euristiche di Nielsen (2005) e di Gerhardt-Powals (1996)

• i principi generali per l’e-government del piano d'azione UE; più in particolare ho integrato i seguenti princìpi:

  • Servizi digitali come opzione privilegiata (digitale per definizione)
  • Principio «una tantum»: evitare richieste ripetute di informazioni da parte della Pubblica Amministrazione
  • Inclusione e accessibilità per tutti
  • Apertura e trasparenza nelle informazioni e nei processi amministrativi
  • Interoperabilità dei servizi pubblici
  • Fiducia e sicurezza nei servizi digitali

• il Codice dell'amministrazione digitale

• le Linee guida di design per siti e servizi web della PA

• le Linee guida sull'accessibilità degli strumenti informatici

• una traccia di valutazione ispettiva che avevo creato alcuni anni fa e recentemente pubblicata su github

Una versione aggiornata della traccia è stata riportata come appendice alla fine di questo post ed è stata anch'essa pubblicata su github.

Perché i metodi ispettivi?

I test di usabilità sono il metodo principe di valutazione dell'usabilità di un prodotto. Perché usare anche la valutazione ispettiva? Non è raro che la valutazione euristica venga suggerita come modalità più economica di valutazione quando non ci sono le risorse e i tempi per fare i test di usabilità.
In realtà metodi ispettivi non possono sostituire i test di usabilità, ma possono costituire una importante integrazione. Metodi ispettivi e test, infatti, fanno emergere problemi di usabilità in parte differenti. Fu et. al. (2002), nel definire i rispettivi punti di forza delle due metodologie, si rifanno alla teoria degli errori di Rasmussen (1983), che distingueva fra tre livelli di errore: skill based, rule based, knowledge based. Il primo livello si riferisce all'interazione con l'interfaccia, il secondo a compiti e processi, il terzo alla conoscenza necessaria per portare a termine il compito. Ho descritto la teoria di Rasmussen nel post "La rotta per Itaca: modelli, percorsi ed usabilità".

Secondo Fu et. al. (2002) i metodi ispettivi fanno emergere principalmente errori a livello di interfaccia e degli aspetti operativi dei processi, mentre i test di usabilità fanno emergere i problemi più legati alla conoscenza e agli aspetti concettuali dei processi. Infatti è difficile "simulare" la conoscenza degli utenti, che possono essere completamente naive, e dunque non conoscere nulla del dominio, oppure estremamente esperti.

In secondo luogo gli errori knowledge-based sono legati allo specifico contesto, e questo rende meno utili le conoscenze degli esperti di ux, che sono trasversali ma non specifiche di dominio.

I livelli skill-based e gli aspetti più operativi del livello rule-based, al contrario, sono molto meno specifici: molte azioni o schemi di interazione valgono a prescindere dal dominio. In questo caso gli esperti possono applicare in maniera appropriata principi, euristiche e linee guida.

Pertanto usare in sequenza metodi ispettivi e test di usabilità offre numerosi vantaggi:

• permette di far emergere problemi che con il solo test di usabilità potrebbero non essere notati;
• diventa più facile analizzare e risolvere quei problemi che emergono da entrambi i metodi;
• l'analisi ispettiva fatta prima del test aiuta a definire i task da sottoporre ai partecipanti, e aiuta ad interpretare le osservazioni fatte durante i test.
• può far emergere degli errori grossolani che possono distrarre il partecipante nel test di usabilità; in queste circostanze, quando possibile, si fa la valutazione, si correggono gli errori più macroscopici, si fa il test con gli utenti con la versione già corretta.

L'utilizzo di differenti metodi di elicitazione è noto in letteratura come triangolazione, ed è una buona pratica anche in ambito di ricerca qualitativa e nell'integrazione di metodi di ricerca qualitativa e quantitativa.

A valle della valutazione ispettiva abbiamo dunque condotto un test di usabilità. Abbiamo coinvolto 8 partecipanti: 6 maschi e 2 femmine in un range di età fra i 23 e i 66 anni e con differenti livelli di dimestichezza con gli strumenti digitali.

I risultati delle valutazioni

Come previsto, dai due metodi sono emerse evidenze in parte simili e in parte diverse.

Risultati della valutazione ispettiva

Le problematiche più gravi emerse si riferiscono non al sito pubblico del comune, che adotta il modello 1.0, ma ai servizi online offerti da terze parti, che invece non adottano lo stesso standard.

I problemi più importanti emersi nella valutazione ispettiva del sito pubblico (aderente al modello 1.0) sono i seguenti:

• nelle schede servizio non sono sempre presenti le informazioni relative alle tempistiche, ad esempio i tempi di attesa che intercorrono tra la presentazione di una domanda e la ricezione di una risposta
• quando si chiede al cittadino di autenticarsi, non vi è un link diretto alla pagina di autenticazione; il cittadino deve capire che deve cliccare in alto a destra
• nelle pagine analizzate i contenuti sono presenti, ma spesso manca la struttura e la gerarchia, e pertanto l’utente deve scansionare tutto il documento per trovare le informazioni; le informazioni sono spesso all’interno di un testo discorsivo che obbliga l’utente a leggere per trovare quello che cerca;
• la pagina principale della sezione “servizi” è di fatto priva di architettura dell’informazione; vi è inoltre una distinzione fra servizi digitali e servizi, ma il cittadino non sa a priori per quali servizi è attivata la procedura digitale e per quali no;
• la rappresentazione (UI) delle card delle categorie è la stessa delle card dei singoli servizi, e dunque non è facilmente comprensibile che si tratta di categorie di servizi;
• nel motore di ricerca, l’anteprima “live search” suggerisce risultati diversi (e apparentemente migliori) di quelli presentati nei risultati di ricerca; apparentemente i risultati in live search sono ordinati per pertinenza, mentre nella pagina “risultati” questi sono ordinati per data di aggiornamento o altri criteri, ma è assente il criterio di pertinenza;
• una volta fatta una ricerca il campo di ricerca non è più modificabile: per modificare il testo da ricercare è necessario ritornare sul bottone della lente.

Per quanto riguarda i servizi esterni (peraltro non conformi al modello) si sono evidenziati questi problemi:

• non sempre al cittadino viene notificata l'erogazione di un servizio o un avanzamento di una pratica, e se questo avviene generalmente non attraverso l'uso di strumenti come l'app IO
• le piattaforme esterne non permettono di utilizzare i dati già in possesso del comune; il cittadino deve re immettere i dati

Infine è necessario ricordare che, nel contesto di una valutazione euristica non è stato possibile portare a termine buona parte dei processi legati all'erogazione di servizi digitali: non potevamo davvero iscrivere un bambino all'asilo o richiedere un permesso ztl.

Risultati del test di usabilità

Dal test sono emersi 3 problemi "critici" (che possono portare l'utente a non completare il task), 3 problemi "seri" (che possono avere un impatto negativo sul completamento del task) e due problemi minori.

Problemi "critici":

• l'assenza di architettura dell'informazione della sezione servizi rende difficile trovare il servizio desiderato dagli utenti;
• alcune persone avevano difficoltà a capire come autentificarsi per accedere ai servizi;
• molti partecipanti si aspettavano di poter prenotare un appuntamento direttamente dalle schede servizio, soprattutto per i servizi che non potevano essere portati a termine online.

Problemi "seri":

• nei monitor di piccole dimensioni, alcuni utenti non capivano che vi erano contenuti sotto al "folder";
• i risultati del motore di ricerca non restituivano risultati utili ai partecipanti;
• alcuni servizi hanno una collocazione ambigua (scuolabus è sotto scuola o sotto trasporti?), e se l'utente non indovina la categoria, diventa difficile trovarli.

Fra i problemi minori, l'etichetta "Documenti e dati" per alcuni utenti rappresenta i documenti e i dati del cittadino (in realtà sono documenti e dati del comune).

Confronto dei risultati

Alcuni problemi sono dunque emersi sia dal test di usabilità che con la valutazione ispettiva:

• l'assenza di un link diretto all'area personale - evidenziata dalla valutazione euristica - ha messo in difficoltà alcuni partecipanti;
• l'assenza di architettura dell'informazione della sezione servizi rende difficile trovare il servizio desiderato, immerso in un elenco di decine o centinaia di servizi in ordine alfabetico;
• nelle schede servizio i partecipanti erano costretti a leggere con attenzione tutto il testo per comprenderne i contenuti, e anche questo era stato diagnosticato dalla valutazione;
• i risultati del motore di ricerca, ordinati per data di aggiornamento, erano spesso di poco valore per i partecipanti.

Fra i problemi emersi dal test che non erano stati notati nella valutazione vanno ricordati:

• la confusione della voce di menu "documenti e dati": alcuni partecipanti si aspettavano di trovare i propri documenti e dati, e non i documenti e i dati del comune;
• l'incertezza nella collocazione del servizio scuolabus, che metà partecipanti cercava sotto scuola e l'altra metà sotto trasporti;
• la difficoltà ad accorgersi che vi fossero dei contenuti sotto alla linea di visibilità del monitor.

Problemi emersi dalla valutazione ispettiva ma non dal test di usabilità:

• mancava la data di aggiornamento delle schede servizio;
• non venivano fornite stime sui tempi di risposta o di erogazione del servizio;
• nell'unica form che è stato possibile valutare (prenotazione appuntamento) i messaggi di errore non erano del tutto conformi alle linee guida;
• non vi è distinzione grafica delle card delle categorie di servizio e dei servizi.

Proposte miglioramento sito pubblico

A valle della valutazione euristica e del test di usabilità, sono state avanzate delle proposte per affrontare le problematiche emerse.

• la voce "Documenti e dati" è diventata una voce di secondo livello di "Amministrazione";
• l'architettura dell'informazione della sezione servizi è stata in parte rivista, utilizzando lo strumento editoriale degli elementi "in evidenza": servizi in evidenza, notizie in evidenza, e così via;
• la rappresentazione grafica delle card delle categorie è stata differenziata da quella degli elementi;
• è stata aggiornata la struttura delle "schede servizio", enfatizzando la visibilità delle date importanti relative al servizio (tempi e scadenze), delle categorie di persone a cui è rivolto, di cosa serve, i costi e vincoli.

Conclusioni

Utilizzare, in sequenza, metodi ispettivi/euristici e test di usabilità permette di far emergere un numero maggiore di problemi. La valutazione ispettiva, se fatta prima del test, aiuta inoltre gli esperti ad impostare il test di usabilità, a scegliere quali compiti far eseguire ai partecipanti e quali aspetti indagare durante il test e l'intervista.

I problemi riscontrati da entrambi i metodi sono più facili da interpretare e da correggere, in quanto la valutazione ispettiva ci permette di identificare il principio o la linea guida violata, e dunque ci offre gli strumenti per correggere l'errore, e il test ci permette di verificare come la violazione abbia delle conseguenze negative sull'esperienza degli utenti.

Il test di usabilità ci permette di far emergere soprattutto problemi specifici del dominio, legati alla mancata conoscenza da parte di utenti non esperti, quali i cittadini che usano un servizio della pubblica amministrazione, che possono avere difficoltà di comprensione, di identificazione, di scelta e possono non riuscire a portare a termine il compito.

I risultati sono solo in parte in linea con la letteratura [Jaspers (2009)], secondo cui

• la valutazione ispettiva/euristica fa emergere più problemi, ma generalmente di gravità minore e più a livello di interfaccia;
• i test con utenti fanno emergere i problemi più gravi, che potrebbero avere un impatto maggiore nell'esperienza d'uso

Nel nostro caso il numero di errori emersi dalla sola valutazione ispettiva è piuttosto limitato. Questo può essere dovuto a due ragioni.
La prima: i risultati della valutazione sono stati usati come guida per il test, e questo probabilmente ha permesso di confermare con gli utenti alcuni problemi emersi dalla valutazione.
La seconda: la valutazione si è focalizzata sul sito pubblico del comune, che costituiva il miglior esempio di adozione del modello 1.0. I servizi erogati da fornitori esterni erano talmente fuori standard che non aveva senso analizzarli in dettaglio, ma se lo avessimo fatto sarebbero emerse decine di problemi. Il fatto che dalla valutazione del sito pubblico il numero di problemi emersi fosse relativamente limitato era la conferma che, sebbene con una serie di limiti che nella riprogettazione abbiamo affrontato, la versione 1.0 del modello era comunque un ottimo punto di partenza.

Infine, la valutazione ispettiva permette di verificare il rispetto di linee guida e princìpi che non emergerebbero dal test di usabilità ma che sono vincolanti in alcuni contesti, come quelli dei servizi digitali delle pubbliche amministrazioni.

Limiti del lavoro

La traccia utilizzata per la valutazione era stata redatta in tempi molto ristretti. La versione che riporto qui sotto è una revisione di quella traccia. Inoltre sebbene nella valutazione io sia stato aiutato da Daniele Muscella, buona parte dell'analisi è stata fatta da me. Idealmente, però, la valutazione ispettiva andrebbe condotta, indipendentemente, da almeno tre o quattro esperti [ Nielsen et. al. (1990); Jaspers (2009)].

La checklist

Riporto la versione aggiornata della checklist utilizzata per la valutazione ispettiva. Come descritto nel post, è il risultato della sintesi di alcune euristiche, alcuni principi per l'e-government e una check list sviluppata precedentemente per siti web commerciali (non PA).

Valutazione ispettiva siti della pubblica amministrazione

Versione 1.0 della traccia utilizzata per la valutazione ispettiva. Come descritto nel post "La valutazione ispettiva", è il risultato della sintesi di fonti diverse:

• le euristiche di Nielsen (2005) e di Gerhardt-Powals (1996)
• i principi generali per l’e-government del piano d'azione UE
• una traccia di valutazione ispettiva pre-esistente

Coerenza interna ed esterna e conformità agli standard - Usare l'aspetto grafico e visivo al servizio dell'usabilità

Va valutata (anche con strumenti esterni alla presente check list) la conformità del sito e dei servizi digitali alla normativa vigente e alle linee guida nazionali e internazionali

Linee guida

• rispetto delle linee guida di design per i servizi web della PA

Accessibilità

• Vengono rispettati i requisiti di accessibilità

Responsività

• L'esperienza nell'uso del servizio digitale è coerente su ogni device e browser

Contesto generale: cittadini ed ecosistema

• il sito e i servizi si integrano in maniera coerente con il contesto più ampio dell'ecosistema della pubblica amministrazione
• il sito e i servizi tengono conto dello user journey del cittadino in una prospettiva di ampio respiro che tenga conto non soltanto dei touch point della pubblica amministrazione

Corrispondenza tra il sistema e il mondo reale

• Il sito e il servizio sono aggiornati ed informativi rispetto al quadro di riferimento (leggi, norme, contesto)
• Il cittadino è informato dei termini di scadenza per la fruizione del servizio

Promuovere la flessibilità e l'efficienza

• il cittadino ha la possibilità di utilizzare gli strumenti di identità digitale (SPID/CIE) per l'accesso ai servizi;
• il cittadino ha la possibilità di inviare e ricevere documenti completamente online ("digitale per definizione");
• quando possibile il cittadino ha la possibilità di compiere i propri compiti sia esclusivamente online, sia presso uno sportello fisico, sia in modalità ibrida, attraverso la prenotazione di un appuntamento;

Visibilità dello stato del processo

• è presente una stima della durata dell’intero processo;
• sono definiti ed indicati i termini in cui la PA agisce/risponde/eroga il servizio (carta dei servizi)
• il cittadino riceve una notifica quando il servizio è stato erogato e/o la transazione effettuata;
• è garantito il tracciamento dei progressi nell’accesso al servizio;

Feedback del sistema

• è sempre chiaro cosa sta succedendo sul sito - applicazione
• il feedback è tempestivo, chiaro, appropriato
• è facile contattare l'help desk o avere aiuto

Libertà e possibilità di controllo del sistema da parte dell'utente

• il cittadino ha la possibilità di portare a termine il percorso di un servizio digitale anche in sessioni diverse, e può salvare le cose fatte per riprenderle in una sessione successiva;
• il cittadino può correggere, modificare e cancellare dati e documenti inseriti, oppure annullare il processo finché non sono stati firmati ed inviati

Gestione degli errori

Prevenire gli errori - Fornire all'utente i mezzi per riconoscere e riparare gli errori

• sono state adottate buone pratiche per la prevenzione degli errori (ad esempio nel controllo degli input)
• i messaggi di errore sono comprensibili e chiari
• i messaggi di errore forniscono azioni chiare per correggere
• se opportuno, i messaggi di errore offrono la possibilità di ottenere assistenza
• è possibile verificare e correggere prima di firmare ed inviare un documento/modulo/richiesta

Linguaggio e comprensibilità

• il linguaggio è appropriato, semplice, chiaro e comprensibile ai cittadini
• non si fa uso di gergo e linguaggio tecnico, se non quando strettamente necessario
• è semplice identificare e comprendere i punti principali del contenuto

Architettura dell'informazione, interazione

• le informazioni sono organizzate in strutture significative
• se appropriato, vi sono possibilità multiple di fruizione dell'informazione
• è chiara la funzione di ogni pagina e ogni sezione
• è chiaro cosa i cittadini devono fare per portare a termine un processo
• la terminologia è appropriata per la funzione
• è facile comprendere e completare i compiti

Interoperabilità

• il servizio dialoga con altre basi di dati e altri servizi per garantire l'interoperabilità e l'importazione esportazione dei dati

Principio «una tantum»

Le pubbliche amministrazioni dovrebbero evitare di chiedere ai cittadini e alle imprese informazioni già fornite.

• al cittadino non è chiesto di immettere dati già in possesso della pubblica amministrazione, o che la PA può ottenere attraverso l'uso dell'interoperabilità
• vengono messi a disposizione del cittadino, quanto più possibile, moduli pre-compilati (es. IMU precompilato)

Ascolto e misurazione

• il cittadino può lasciare una valutazione sulla utilità delle pagine del sito
• il cittadino può lasciare una valutazione sulla performance del servizio digitale
• la soddisfazione degli utenti è monitorata con appropriati KPI (non valutabile dall'euristica)

Testi citati