Riprogettare siti web della PA
Un approccio iterativo per migliorare l’usabilità
Cos’è l’usabilità e perché è importante?
La digitalizzazione dei servizi costituisce un importante passaggio nel rapporto fra le pubbliche amministrazioni e i cittadini. I servizi digitali, se implementati correttamente, aumentano l'efficienza e riducono la burocrazia, con un impatto positivo sui tempi di gestione ed erogazione. Contribuiscono ad aumentare l'accessibilità ai servizi, soprattutto per le persone che per vari motivi hanno difficoltà ad accedere agli sportelli fisici degli enti, eaumentano inoltre la trasparenza dei processi.
L'adozione dei servizi digitali da parte dei cittadini richiede però che siano in primis facili da usare, infatti l’usabilità non solo favorisce un’esperienza d’uso positiva della tecnologia, ma aumenta la fiducia dei cittadini nelle amministrazioni pubbliche e garantisce una maggiore inclusività, soprattutto nei confronti di quelle persone con una minor propensione all'interazione con il digitale.
L'usabilità è il grado in cui un prodotto (un servizio digitale) può essere usato dagli utenti per raggiungere certi obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto d'uso. Un servizio è efficace se permette all'utente di raggiungere l'obiettivo che si era prefissato. A parità di efficacia, un servizio è più efficiente se richiede all'utente meno sforzo, quindi risorse (ad esempio meno tempo, meno spostamenti, meno burocrazia, minor costi). La soddisfazione infine è influenzata dall'utilità percepita e dal livello di comfort avvertito da parte dell'utente durante la fruizione.
Ma come possiamo valutare l'usabilità di un servizio?
Possiamo distinguere 4 tipi di valutazione dell’usabilità di un prodotto [Fernandez et. al. (2011); Bussolon (2021)]:
- i metodi empirici, quali i test di usabilità, che coinvolgono un limitato numero di persone che rappresentano gli utenti; ai partecipanti è chiesto di portare a termine dei compiti decisi dai ricercatori;
- 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 le statistiche d’uso delle applicazioni.
Perché affiancare metodi ispettivi a quelli empirici?
I test di usabilità sono il metodo principe di valutazione dell’usabilità di un prodotto. Perché usare anche la valutazione ispettiva? Non è raro che questo tipo di valutazione venga scelta come modalità più economica di valutazione quando non ci sono le risorse e i tempi per fare i test di usabilità.In realtà i metodi ispettivi non possono sostituire i test di usabilità, ma possono costituire un’ importante integrazione. Metodi ispettivi e test con gli utenti, infatti, fanno emergere problemi di usabilità in parte differenti. La teoria degli errori di Rasmussen (1983), distingue tre livelli di errore:il primo livello si riferisce all’interazione con l’interfaccia, il secondo a compiti e aspetti operativi dei 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à”.
""
Il framework Skills, Rules, Knowledge (SRK) di Rasmussen è un modello che descrive il comportamento umano e il processo decisionale in sistemi complessi. Il quadro è composto da tre livelli:
Comportamento basato sulle abilità: questo livello prevede azioni automatiche e di routine eseguite senza pensiero cosciente. Queste azioni si basano su competenze ben praticate e vengono eseguite in modo rapido ed efficiente. Gli esempi includono la digitazione su una tastiera, la guida di un'auto su un percorso familiare o l'utilizzo dell'interfaccia di uno smartphone.
Comportamento basato su regole: a questo livello, gli individui seguono una serie di regole o procedure per guidare le loro azioni. Queste regole vengono generalmente apprese e applicate consapevolmente e aiutano le persone a prendere decisioni e a risolvere problemi in situazioni familiari ma non di routine. Ad esempio, seguendo una ricetta per cucinare un nuovo piatto o seguendo una serie di linee guida per la risoluzione di un problema informatico.
Comportamento basato sulla conoscenza: questo livello prevede la risoluzione di problemi e il processo decisionale in situazioni non familiari o complesse. Gli individui attingono alla loro comprensione del sistema e dei suoi principi sottostanti per ideare nuove soluzioni e adattarsi a nuove circostanze. Questo livello richiede pensiero cosciente, analisi e creatività. Gli esempi includono la progettazione di una nuova interfaccia software, la risoluzione di un problema tecnico complesso o la presa di decisioni strategiche in un contesto aziendale.
Secondo Fu et. al. (2002), nel definire i rispettivi punti di forza delle due metodologie, si rifanno a questa teoria e affermano che 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 pregressa 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.
Inoltre gli errori a livello di conoscenza 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 di interazione e gli aspetti più operativi del livello dei processi, 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.
Utilizzare, in sequenza, metodi ispettivi 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.
L’utilizzo di differenti metodi di elicitazione è noto in letteratura come triangolazione, ed è una buona pratica sia in ambito di ricerca qualitativa che nell’integrazione di metodi di ricerca qualitativa e quantitativa.
I metodi ispettivi
Il più noto tra i metodi ispettivi è quello della valutazione euristica. 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 ottenute 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. Ad esempio, le prime regole euristiche di Nielsen sono: 1. Visibilità dello stato attuale del sistema; 2. Corrispondenza tra il sistema e il mondo reale; 3. Libertà e possibilità di controllo del sistema da parte dell'utente.
Una delle difficoltà della valutazione euristica è che, essendo i princìpi piuttosto generali, e non specifici per un determinato settore e/o target, 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)].
Inoltre le regole possono essere adattate a contesti specifici, ad esempio un sito o applicazione della pubblica amministrazione. Il risultato è una checklist in cui, per ogni princìpio generale, vengono definite delle regole più specifiche, più facili da verificare nel corso della valutazione e meno soggette ad interpretazioni.
Il contesto: il modello comuni
L'idea di sviluppare una checklist specifica per i siti della pubblica amministrazione è emersa durante la progettazione della versione 2.0 del modello per il sito e i servizi digitali dei Comuni italiani di Designers Italia.
Una delle attività del progetto era quella di valutare la versione 1.0 del modello, per identificarne i limiti e correggere i problemi di usabilità nella nuova versione. Prima di fare il test di usabilità con gli utenti abbiamo deciso di fare una valutazione ispettiva, e per farla abbiamo sviluppato una checklist specifica per le pubbliche amministrazioni.
Quali sono i principi da valutare per l’usabilità di siti della PA?
Nel definire la checklist siamo partiti da 3 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 checklist pre-esistente, non specifica per le pubbliche amministrazioni ma più focalizzata su siti e applicazioni del settore privato, che avevo sviluppato alcuni anni fa e che utilizzo prevalentemente come strumento didattico nel mio insegnamento. Ho recentemente pubblicato la checklist su github
Nel definire la checklist per la pubblica amministrazione abbiamo tenuto conto anche delle principali norme nel contesto italiano (il Codice dell'amministrazione digitale, le Linee guida per accesso telematico ai servizi della Pubblica Amministrazione, le Linee guida sull'accessibilità degli strumenti informatici. Ci siamo però focalizzati esclusivamente sugli aspetti legati all'usabilità e all'esperienza d'uso, e dunque non su aspetti quali accessibilità, privacy, sicurezza informatica, autenticazione, utilizzo di software open source e così via. Per questo motivo il primo punto della checklist ribadisce che va valutata con strumenti esterni la conformità alla normativa e alle linee guida nazionali e internazionali.
La valutazione del Modello Comuni
Come detto, la creazione della checklist è stata motivata dalla necessità di valutare la versione 1.0 del Modello Comuni. Per poterlo fare su una implementazione reale abbiamo fatto la valutazione (prima con la checklist, poi con il test di usabilità) del sito di un comune capoluogo di provincia che ha adottato il modello e che ne costituisce lo stato dell'arte. Poiché il fine dell'analisi (valutazione ispettiva 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.
A valle della valutazione ispettiva abbiamo dunque condotto un test di usabilità. Abbiamo coinvolto 8 partecipanti, di cui 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 della valutazione ispettiva ci hanno aiutato a definire, almeno in parte, i compiti del test.
Il confronto fra i risultati
Come previsto, dai due metodi sono emerse evidenze in parte simili e in parte diverse:
- 4 problemi, di cui alcuni piuttosto seri, sono emersi sia dalla valutazione ispettiva che dal test di usabilità.
- 3 problemi sono emersi solo dal test di usabilità.
- 4 problemi sono emersi solo dalla valutazione ispettiva.
Per una analisi più dettagliata dei risultati, si veda il post nella mia newsletter.
L'indagine conferma dunque quello che avevamo immaginato: la valutazione ispettiva non può sostituirsi al test di usabilità, perché alcuni problemi emersi dal test non erano emersi dalla valutazione. Ma costituisce un'importante integrazione, perché permette di rilevare problemi che dal test non erano apparsi, perché ci aiuta nella definizione dei compiti del test e perché ci aiuta a definirne le possibili soluzioni.
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.
La checklist
Riporto la versione aggiornata della traccia 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).
Coerenza interna ed esterna e conformità agli standard
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à, valutati con strumenti specifici
Responsività (mobile first)
- 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
- [Quando disponibili, vengono utilizzate le piattaforme abilitanti bla bla bla]
- 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 del cittadino
- 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)
Segnalazione di Ilaria
Valutare l'usabilità dei siti web della pubblica amministrazione
Un approccio basato su metodologie complementari per analizzare lo stato dell’arte
Da dove iniziare quando ci si trova a dover rinnovare o riprogettare un sito informativo della pubblica amministrazione? Come applicare la logica dell’approccio iterativo per ‘non reinventare la ruota’ ma invece capitalizzare su quanto fatto in passato? Il processo progettuale in 5 fasi di DI non si intende come lineare e da seguire in toto per tutte le tipologie di progetto, ma come una struttura di massima che aiuta ad orientare la definizione delle attività progettuali a seconda dello stato dell’arte di un prodotto e degli obiettivi che si vogliono raggiungere.
Il processo progettuale seguito per migliorare la prima versione del modello Comuni 1.0 di Designers Italia, rappresenta un ottimo esempio in cui si è ripartiti dalla fase di validazione, affiancando alla ricerca primaria, ovvero i test di usabilità, anche la ricerca secondaria, l’analisi euristica.
L'analisi euristica è una metodologia ben nota, con criteri consolidati da anni a livello internazionale (vedi ref. Nielsen...), tuttavia questi sono universali e comunemente applicati nell’ambito del privato, invece questo caso studio presenta una prima esplorazione in cui sono stati definiti crtieri ad-hoc, in modo da applicare la metodologia dell’analisi euristica all’ambito specifico dei siti della pubblica amministrazione.
Per saperne di più leggi l’articolo che spiega come sono state integrate le due metodologie di ricerca e quali sono i criteri fonamentali per valutare l’usabilità di un sito pubblico: LINK ARTICOLO
Lancio social
Come valutare l’usabilità dei siti web della PA? Come applicare efficacemente la metodologia dell’analisi euritica al settore pubblico? Condividiamo con te quello che abbiamo imparato, insieme a @fifthbeat, nel riprogettare il modello Comuni di Designers Italia.
Per approfondire:
link nostro medium da inserire
perché ispettivi e empirici perché ispettivi non solo euristiche
rimetti un paragrafo sul fatto che abbiamo testato la checklist in occasione del redesign del modello comuni. link a modello comuni
mancano una serie di cose che sono importanti: privacy, sicurezza, licenze .... solo front-end, non backend e backoffice
https://designers.italia.it/norme-e-riferimenti/linee-guida-di-design/
Link utili:
cose da rimettere
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.