È uscito il Piano Triennale per l’ICT, e sull’usabilità è un vero pasticcio

Il Piano Triennale 2019-2021 ha inserito l’usabilità fra gli scenari, gli obiettivi e le azioni. Nonostante evidenti passi avanti, spicca il fatto che tra gli strumenti di riferimento per l’usabilità sia citato il solo Protocollo eGLU, dicendo oltretutto che deve essere:

  1. usato dalle PA stesse (non da aziende terze che lavorano per la PA) e
  2. a costo basso o nullo.

Qui urge perciò una precisazione. Del Protocollo eGLU, che assieme a Simone Borsci ho coordinato per conto del GLU, Gruppo Lavoro Usabilità della Funzione Pubblica, si possono avere diverse visioni. Di suo è una procedura passo-passo per l’esecuzione di test di usabilità semplificati, con raccolta anche di qualche semplice metrica utile per valutazioni e comparazioni.

L’uso che se ne può fare, però, è vario e molteplice, e dipende dalla strategia globale che viene suggerita o indicata alle PA.

Primo uso possibile

Il Protocollo può benissimo essere un modo per “farsi i test in casa”, e magari, identificati i principali problemi di un sito o di un servizio, richiedere delle modifiche all’azienda incaricata. Lo possiamo vedere anche così, ma così svalutiamo e riduciamo l’usabilità a mera pratica “autosomministrata” nel tempo rubato al lavoro da persone che hanno un’altra mansione, e che si avvicinano all’usabilità per la prima volta. Però è legittimo: il Protocollo è anche uno strumento di diffusione di conoscenza, per avvicinare ai test di usabilità, sebbene semplici, anche non esperti. Sarebbe davvero un peccato se nel contesto pubblico rimanesse solo questo. Ma soprattutto, sarebbe un vero peccato se si desse l’idea che l’usabilità tutta è solo test a basso costo avulsi dal processo progettuale.

E ancora peggio se, per effetto di questa “autosomministrazione dei test” nella PA, gli unici a guadagnarci fossero… le aziende che hanno in primis prodotto il sito, il servizio o il software che richiede modifiche. Perché è scontato che le modifiche verranno richieste a loro. Hanno prodotto un software subottimale, e ora gli diamo un nuovo incarico per correggerlo. Praticamente il business model attuale. Ma è proprio quel business model che va cambiato!

Secondo uso possibile

Un altro uso che si può fare del protocollo eGLU, invece, è considerarlo uno strumento di base, che offra anche una serie di metriche di valutazione che attestino un livello di qualità del prodotto. E quindi obbligare tutte le aziende a inserirlo, assieme a altre tecniche orientate all’utente (molte sono presenti su Designers Italia, assieme al Protocollo eGLU), nel processo usato per realizzare i prodotti informatici per la PA.

A questo punto, l’indicazione di specifici strumenti da usare nel processo dovrebbe modificare, si spera in senso virtuoso, e a carico delle aziende stesse, il modo di realizzare i prodotti, rendendoli più usabili.

Terzo uso possibile

Un altro modo ancora per considerare il protocollo eGLU è, in alcune circostanze, come uno strumento (di base ma estendibile) di valutazione da affidare a professionisti terzi sul livello di qualità raggiunto dal lavoro di un’azienda. Specialmente nel caso in cui quel prodotto informatico abbia impatto sulla produttività o sulla sicurezza (penso ai software in uso dagli operatori pubblici, più che ai siti informativi). Così, per esempio, nei capitolati si potrebbero inserire non solo il rispetto dei punti funzionali, ma anche un livello minimo di facilità d’uso al primo utilizzo, o di facilità di apprendimento, o di assenza di errori, in mancanza dei quali il lavoro non si può considerare correttamente svolto.

Finale non a sorpresa

Sono tre possibili modi di intendere il Protocollo eGlu, insomma. Due obbligano le aziende a modificare i loro processi e a realizzare prodotti migliori, uno invece non interviene sui processi e aumenta la probabilità per le aziende di ricevere nuovi incarichi, ovviamente pagati, per correggere ciò che hanno fatto male in primis.

Bene. Ora, leggete il Piano Triennale e provate a valutare da voi quale di questi tre possibili modi “strategici” di usare uno strumento in sé “tecnico” come il Protocollo eGLU è stato privilegiato. Quelli evolutivi, o quello che mantiene lo status quo?

Ehi, ma perché pensate male?

Io non l’ho detto.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

È uscito il Piano Triennale per l’ICT, e sull’usabilità è un vero pasticcio

È uscito il nuovo Piano Triennale per l’informatica nella PA, il documento guida di azioni, obiettivi e strategie per una transizione digitale che la PA italiana sta faticosamente tentando da anni di intraprendere.

Piuttosto che analizzare il piano nel suo complesso (ci sarà modo e tempo), volevo concentrarmi sulle parti che riguardano l’usabilità. Molti si sono rallegrati (per esempio qui) della presenza di una specifica sezione con scenario, obiettivi e azioni dedicati all’usabilità. Analizziamo brevemente le tre parti, riportandone frammenti per capire cosa dicono.

9.3.1 – Scenario

Come ampiamente dettagliato su Designers Italia, la progettazione dei servizi digitali deve rispondere a elevati criteri di usabilità, per consentire alle PA di:

  • evitare la produzione di servizi inadeguati;
  • incentivare i cittadini ad accedere ai servizi digitali, rispetto al tradizionale sportello.

L’inizio sembra buono. Si rimanda alle linee guida di Designers Italia, che contengono molte tecniche sia di gestione di progetto che strumenti e metodi di usabilità che si possono ritenere buone pratiche.

Anche gli obiettivi di evitare servizi inadeguati e incentivare i servizi digitali sono condivisibili, sebbene non si entri nel merito del come fare.

Il problema principale sembra essere al paragrafo successivo:

Le Linee guida di design sviluppate all’interno di Designers Italia forniscono alle PA un protocollo per la realizzazione di test di usabilità, realizzato da un Gruppo di lavoro per l’Usabilità (GLU) coordinato dal Dipartimento della Funzione Pubblica, con l’obiettivo di:

  • coinvolgere direttamente le PA nella valutazione dei propri siti e servizi online;
  • sensibilizzare maggiormente gli operatori pubblici sul tema dell’usabilità;
  • mantenere molto bassi, o nulli, i costi per l’effettuazione dei test.

La prima cosa che notiamo è che mentre le linee guida di Designers Italia contengono molte indicazioni finalizzate a modellare i progetti sulle reali esigenze degli utenti, dalle ricerche qualitative (ma perché non includere anche quelle quantitative, o parlare più genericamente di ricerca con utenti rimane un mistero…), di progettazione, di principi di progettazione e di architettura dell’informazione, qui viene citato esclusivamente il Protocollo eGLU.

Il Protocollo eGLU (ne ho già parlato, non mi dilungo, ma per chi non lo sapesse sono coinvolto nella sua realizzazione) non è né uno strumento a uso esclusivo del personale interno alle PA (anzi, in molti progetti è stato usato come riferimento base che le aziende dovevano utilizzare durante la progettazione, e non la PA stessa, come è logico), né uno strumento che mira di per sé a contenere i costi dei test. Direi piuttosto che, offrendo una procedura chiara, rende facilmente stimabili anche i costi di esecuzione (in termini di effort, di ore uomo, di fasi da seguire e risultati da analizzare) sottraendoli all’arbitrio.

Ma è sempre stato percepito come strumento “a basso costo”…

Chiariamoci: solo se usato internamente, dalle redazioni, come strumento di auto-formazione, diventa uno strumento a basso costo, ma solo perché le redazioni decidono di auto-formarsi su un tema che non fa parte delle loro professionalità base. Come se si auto-formassero sugli open data seguendo una guida passo passo, per dire.

Ma inserito in un normale contesto progettuale, come dovrebbe essere a regime, il Protocollo eGLU è uno strumento come un altro, che ha un costo come tutti gli strumenti.

Preoccupano dunque molto, qui, due aspetti:

  1. Il fatto che sia indicato nel “capitolo usabilità” SOLO il Protocollo eGLU, come se la ricerca con utenti e tutte le tecniche di progettazione con gli utenti pur presenti su Designers non la riguardassero
  2. L’enfasi sul costo basso o nullo, che rischia di dare un messaggio fuorviante, e contraria ad ogni tentativo di dimostrare il ROI dell’usabilità (cosa che un altro gruppo di lavoro del GLU aveva fatto anni fa, oltretutto). Di più: presenta il rischio di far considerare i test come costi, invece che come investimenti; e di ridurli a zero, rendendo così zero anche il ROI! Un totale capovolgimento di ciò che la ricerca e le buone pratiche suggeriscono.

Attenzione: il documento non dice esplicitamente questo, ma il rischio che la formulazione scelta lasci interpretare l’usabilità e i test in questo modo è a mio parere, in un contesto sottoposto a molte spinte come quello della PA, molto alto.

9.3.2 . Obiettivi

Possono gli obiettivi successivi aiutarci a capire meglio se l’idea di usabilità che traspare dalle prime righe può essere semplicemente frutto di un fraintendimento? Leggiamoli; gli obiettivi sono:

  1. Favorire lo svolgimento di test di usabilità nelle PA, anche grazie all’adozione del protocollo per la realizzazione di test di usabilità;
  2. monitorare i miglioramenti apportati al sito in seguito alle criticità rilevate tramite i test.

Anche se in apparenza qualcuno può leggere questi due obiettivi come un passo avanti, se uniti alle dichiarazioni di scenario si parla di test di usabilità ancora una volta in maniera del tutto avulsa da ogni pratica di processo. È giusto favorire lo svolgimento di test, ma non nelle PA, in un qualsiasi arbitrario momento, bensì sui prodotti in fase di progettazione (e in alcuni casi, per identificare problemi in vista di redesign, su quelle già progettate). E non è chiaro per quale ragione la collocazione di questi test dentro il processo progettuale non viene assolutamente menzionata.

Anche l’obiettivo di monitorare i miglioramenti è condivisibile: ma i miglioramenti si possono realizzare solo se qualcuno fa le modifiche. Cioè se viene coinvolta l’azienda responsabile della realizzazione! Non viene chiarito né quando né come questa azienda debba essere coinvolta, né se deve esserlo. E, se non lo è, non è chiaro come questi miglioramenti (tranne quelli apportabili internamente dalla stessa redazione, che comunque sono una parte di quelli possibili – ad esempio il labeling) possano venir ottenuti.

Ci può ulteriormente togliere ogni dubbio di malinteso il punto successivo, riguardante le azioni?

9.3.3 – Azioni

Qui, ahimé, leggiamo ciò che conferma le nostre peggiori interpretazioni: quelle di test di usabilità autosomministrati e avulse da ogni vincolo progettuale e contrattuale con le aziende incaricate:

(..)Le pubbliche amministrazioni centrali, elencate nella Determinazione AGID n.36/2018, effettuano dei test di usabilità sui propri siti istituzionali utilizzando il “Protocollo eGLU LG per la realizzazione di test di usabilità” e i relativi kit di usabilità messi a disposizione su Designers.italia.it.(..)

Le PA inviano ad AGID il report finale del test di usabilità (giugno 2019) e alcuni dei risultati più rilevanti vengono pubblicati sul sito Designers.Italia.it.

AGID e il Dipartimento di Funzione Pubblica organizzano un incontro annuale con le PA per presentare e discutere i risultati (da dicembre 2019, con cadenza annuale).

(..) Nel breve periodo, impatto sulle PA.

Come si vede, si parla di alcune amministrazioni centrali (delle altre non è dato sapere che debbano fare, se volessero) che effettuano test (non li fanno effettuare: li effettuano loro), e mettono a disposizione i risultati per una discussione comune. Fine.

Nessun riferimento a obiettivi o a processi, nessuna dichiarazione esplcicita sull’impatto che questi test possano avere sulle aziende, sui futuri processi. Sembra una specie di opera di ricerca interna, mirata a raccogliere informazioni, più che a incidere sui processi progettuali.

Cosa manca

Queste impressioni di “estemporaneità” di interventi sull’usabilità nel PT è purtroppo rafforzata dalla completa assenza di ogni riferimento a interventi e metodi di progettazione orientati all’utente o al cittadino o a pratiche di Human Centered Design. La cosa triste, è che in passato questi riferimenti c’erano. La speranza era che, con la mole di conoscenze e di strumenti messi a disposizione anche da Designers Italia, di cui il Protocollo eGLU è entrato a far parte, questi riferimenti si ampliassero e dettagliassero. Certo, non che sparissero!

Di fatto, il PT, nonostante richiami Designers, manca di fare riferimenti puntuali, e finisce per sembrare uno strumento redatto da mani e menti differenti, più che parte di una strategia unitaria.

A cosa bisognerebbe tendere

Il problema vero è che non esiste usabilità se non cambiano i processi progettuali. Il che significa obbligare/incentivare le aziende incaricate del progetto a eseguire costantemente tecniche di coinvolgimento, monitoraggio e verifica con utenti. Anche con il Protocollo eGLU, ma senza dare l’idea che il Protocollo sia uno strumento ad uso e consumo esclusivo interno delle PA: così ha davvero un’altro senso. Sul territorio conosco personalmente pubbliche amministrazioni e aziende che questo lo hanno capito, e hanno iniziato a usare il protocollo per i test, già durante il processo progettuale. Quella dovrebbe essere la strada da indicare esplicitamente.

Non solo: il Protocollo (o qualunque altro test che offra risultati comparabili o superiori a quelli del Protocollo eGLU) può anche essere uno strumento di valutazione del lavoro svolto. In alcuni specifici casi, dove il prodotto informatico ha come missione quella di dover garantire efficacia ed efficienza certa, rapidi tempi di apprendimento per snellire l’esecuzione dei procedimenti – penso ai software in uso per implementare i procedimenti nella PA piuttosto che ai siti informativi – la valutazione può e deve essere svolta da soggetti terzi: cioè né dalla PA stessa (che non ne ha la professionalità) né dall’azienda incaricata dello sviluppo, perché in conflitto di interessi.

È lì per esempio che il lavoro di professionisti o aziende terze può intervenire e attraverso il Protocollo eGLU valutare il livello raggiunto da un certo prodotto in un certo momento, per attestare se sia conforme alle richieste.

Attenzione, perché questo è un punto cruciale: attualmente i bandi sono quasi esclusivamente centrati sul rispetto di requisiti funzionali da parte delle imprese informatiche che realizzano un prodotto. I riferimenti all’usabilità sono quasi sempre vaghi e non quantificati, in modo che sia impossibile contestare la bassa usabilità a qualsiasi prodotto. Di conseguenza, non c’è incentivo da parte delle aziende di investire in un processo HCD, perché sanno che non verranno giudicate su questo.

Il rischio di regressione

Il PT, e il “regalo” che il GLU ha provato a fare alla PA con il Protocollo eGLU, sarebbe dovuto servire anche a questo, almeno a muovere qualche passo, magari timido e incerto, nella direzione di vincolare fin dai bandi e dai capitolati all’esecuzione di tecniche orientate all’utente. O almeno a esplicitare l’importanza di diverse tecniche HCD dentro le fasi progettuali. Solo così si cambiano i risultati.

L’impatto di iniziative di “autoconoscenza istituzionale” purtroppo rischiano di rimanere solo questo: materiale buono per convegni, ma che non incide nel processi reali.