Grazie a Cristiano Rastelli sono venuto a conoscenza di una iniziativa secondo me encomiabile: la creazione di un sistema di linee guida per i siti web della pubblica amministrazione (Per un design dei servizi della pubblica amministrazione | Linee guida di design per i siti web della PA), attraverso la piattaforma Github: italia-it/designer.italia.it.
Perché è importante?
L'iniziativa è importante, a mio avviso, per diversi motivi
Evangelizzazione
La sensibilità, in Italia, nella pubblica amministrazione e non solo, per i temi del design centrato sull'utente, dell'usabilità e della user experience non è, notoriamente, molto alta. Questo progetto può costituire un utile tassello nella direzione della sensibilizzazione e della formazione di chi - all'interno o come consulente - si occupa di progettare i servizi web e mobile della PA.
Economia di scala
Una delle motivazioni alla base delle linee guida (e di una implementazione di riferimento) è che permette di evitare, alle singole PA, di re-inventare, ogni volta, la ruota. Se nei progetti grossi (PA centrale, grandi regioni) questo risparmio può risultare marginale, nei progetti più piccoli (sto pensando, ad esempio, ai comuni di piccole dimensioni) il poter disporre di una base pronta, da cui partire, può essere un vantaggio notevole.
Coerenza
La coerenza interna ed esterna è una delle euristiche più note in letteratura. Nel decalogo di Nielsen, si legge "Coerenza interna ed esterna e conformità agli standard comunemente accettati dagli sviluppatori di siti Web".
Per coerenza interna si intende che l'interfaccia di una organizzazione sia consistente in tutte le sue pagine e sezioni.
Per coerenza esterna si intende la necessità che l'interfaccia rispetti sia gli standard formali del web che gli standard di fatto.
Linee guida e design pattern sono gli strumenti che rendono possibile il rispetto di questo princìpio. Nel caso del progetto per le PA, uno dei fini è quello di garantire una coerenza fra i siti delle diverse amministrazioni pubbliche - possibilmente mantenendo la possibilità che le varie amministrazioni possano comunque mantenere un proprio brand, un proprio marchio istituzionale.
Testabilità
Nei mesi scorsi il Gruppo di lavoro per l'usabilità dei siti web - GLU ha elaborato un protocollo per la realizzazione di test con utenti, che costituisce la base per la valutazione empirica, ovvero con gli utenti, dei test di usabilità.
Le linee guida possono costituire il riferimento per la valutazione euristica, ovvero la valutazione fatta dagli esperti. Gli esperti (ma in fondo anche i meno esperti) possono verificare che le varie pagine e sezioni del sito rispettino le linee guida stabilite.
Perchè open source?
L'idea di utilizzare la piattaforma github per sviluppare le linee guida è in linea con il principio di utilizzare formati di documenti, software e dati in modalità aperta. La mia opinione pesonale è che questo sia un princìpio, anche politico, fondamentale (e, da utente Linux, la cosa non dovrebbe sorprendere). Indicazioni in questo senso sono già state assunte dalla PA negli scorsi anni:
Sviluppo dal basso
Uno dei vantaggi dell'approccio open source è la possibilità che, a contribuire alla definizione delle linee guida, siano non solo gli enti preposti, ma anche esperti esterni.
Progettare le linee guida
Il mio interesse nei confronti del progetto è legato anche al fatto che il tema delle linee guida mi sta appassionando da alcuni mesi. In un post precedente, Una guida alle linee guida, ho iniziato a classificare varie tipologie di linee guida, e ho fatto un benchmark di quelle più importanti.
Nel mio intervento a Better Software ho introdotto il concetto di grammatica della user experience, ovvero delle linee guida semantiche, che identifichino i concetti e le funzioni comuni all'interno di un sistema informativo (o, nel caso della PA, di un meta-sistema informativo).
Il metodo
Non essendo uno sviluppatore, non ho intenzione di contribuire (se non molto marginalmente) agli aspetti implementativi delle linee guida. Mi piacerebbe, al contrario, contribuire alla metodologia di sviluppo del progetto.
Nel mio corso di Interazione Uomo Macchina racconto ai miei studenti che, prima di iniziare a disegnare interfacce, sono necessari alcuni passaggi preliminari: strategia, audience, benchmark, audit dei contenuti per citarne alcuni.
La strategia
Identificare la visione strategica del progetto. Qual'è la sfida? Qual'è il valore atteso del progetto? Quali gli ostacoli? Quali i vincoli? Vincoli di legge, vincoli tecnologici, vincoli culturali, e princìpi generali? Quali sono le risorse? Visto che parliamo di Pubblica Amministrazione, qual è il commitment delle istituzioni preposte?
L'audience
A chi sono rivolte le linee guida? Sarebbe opportuno definire dei personaggi, ovvero i ruoli principali a cui il progetto è rivolto. Provo a delineare quelli che, ragionevolmente, sono i destinatari principali.
- Le figure interne della PA:
- I decisori all'interno della PA: referenti politici e dirigenti con potere decisionale.
- I referenti per i servizi web, ad esempio i responsabili della comunicazione dell'ente.
- I referenti tecnologici interni: i tecnici che lavorano all'interno degli enti, e che vengono coinvolti nei progetti
- Le aziende appaltatrici (o i consulenti) che si fanno carico di progettazione e sviluppo dei servizi:
- I project manager
- Gli esperti ux (ux researcher, interaction designer, architetti dell'informazione, information designer, esperti di usabilità, graphic designer)
- Gli sviluppatori, soprattutto front-end
- I cittadini
Definire i personaggi è utile anche per stabilire il linguaggio appropriato. Ad esempio, è probabile che i documenti che definiscano gli aspetti implementativi siano rivolti esclusivamente agli sviluppatori, le sezioni dedicate ad usabilità e accessibilità agli esperti ux, le guide di stile ai graphic designer.
Il benchmark
L'ispirazione per questo progetto arriva, esplicitamente, da uk.gov. Sarebbe però opportuno analizzare anche altri progetti: linee guida di altre nazioni (US, Svizzera), le Human Interface Guidelines di Apple, Google, Windows, i documenti del w3c, e linee guida di aziende private. Da questo punto di vista, il mio post, già citato, potrebbe costituire un punto di partenza.
Lo stato dell'arte della PA
Sì, lo sappiamo, la pubblica amministrazione Italiana non è propriamente all'avanguardia. Ma sono convinto che ci sia anche qualche eccellenza, qualche esempio che possa fare da modello. Un benchmark interno potrebbe essere senz'altro utile.
Approccio partecipativo?
Ha senso coinvolgere, magari proprio con spirito open, un numero rappresentativo delle figure delineate sopra? Identificare un ragionevole processo di ricerca che coinvolga decisori, responsabili di comunicazione, ux, sviluppatori, project manager?
Livelli di astrazione
La discussione, nello spazio github, è vivace.
Alcune discussioni riguardano il codice html: usare il tag main? Che codice usare per le icone?
Alcune, i formati: icone come font o come svg?
Alcune, il processo implementativo: Integrare CSS dei template?
Alcune, il framework da utilizzare: bootstrap? Che versione? Un framework progettato ad hoc?
Alcune, i vincoli tecnologici degli utenti: IE8 va supportato?
A me pare chiaro che queste issues abbiano piani di astrazione diversi. Sarebbe opportuno identificare e rendere espliciti questi piani.
Ad onor del vero, nemmeno le linee guida che ho studiato per il mio benchmark brillano da questo punto di vista. Ad esempio, nella pagina User-centred design del Government Service Design Manual vengono elencate una serie di risorse: metodologia, princìpi, tecniche di ricerca, elementi di ui, design pattern, accessibilità, elencati in un ordine che non mi è chiaro. Resta, però, una questione a mio avviso importante.
La gerarchia
Confesso che io stesso non ho chiaro quale dovrebbe essere la gerarchia. L'ordine che propongo è dunque del tutto provvisorio.
- i princìpi generali; ad esempio essere centrati sul cittadino, essere inclusivi, essere finalizzati alla semplificazione e alla facilità d'uso, essere aperti (open source, open standard, open data) e così via;
- i princìpi di design: citando ancora GOV.UK: focalizzarsi sui bisogni e gli scopi, con un approccio che si basa sui dati, possibilmente snello (do less), orientato ai servizi (digital services);
- i princìpi cognitivi dell'ucd (sulla falsariga delle euristiche di Nielsen o di Gerhardt-Powals); ad esempio: minimizzare il carico cognitivo, minimizzare l'incertezza, essere consistenti, usare rappresentazioni adeguate all'infomazione, al contesto, al compito, usare una terminologia appropriata, prevenire e minimizzare gli errori, permettere l'esplorazione, dare all'utente il controllo, rappresentare lo stato del sistema, facilitare l'apprendimento, usare l’aspetto grafico e visivo al servizio dell’usabilità;
- i princìpi dell'accessibilità;
- la definizione di un design language, ad esempio sulla falsariga di Google Material design;
- la mappa delle più importanti funzioni e servizi online di pertinenza di una pubblica amministrazione: registrarsi e creare un profilo, autenticarsi, procedure per fare una domanda, chiedere un documento o un certificato, contattare un referente o un ufficio, inviare una certificazione, richiedere e usare la firma digitale, e così via;
- l'elenco dei concetti più comuni ed un prototipo di template: il concetto di referente / persona, distinto per referente politico (il sindaco, il consigliere) e referente amministrativo (il responsabile dell'ufficio); il concetto di ufficio, con un prototipo (nome dell'ufficio, indirizzo, mappa (magari openstreetmap), orario di apertura, responsabile, organigramma, competenze, servizi offline, servizi online), e così via;
- definizione del layout - o meglio, di un set di layout in base alle tipologie di pagine: home, pagina index, pagine di funzione, pagina di oggetto; un buon punto di partenza sono le sample pages della Swiss Styleguide;
- la definizione dell'anatomia della pagina: intestazione, navigazione principale, navigazione contestuale, area principale, footer, e la definizione dei requisiti di ogni area;
- la definizione degli elementi dell'interfaccia, in base ad un approccio modulare e gerarchico, sulla falsariga dell'atomic Design;
- i princìpi di implementazione: che strumenti usare (grub, javascript, sass, bootstrap), quali vincoli (IE8 va supportato?) e così via;
- una linea guida per il codice css, html e javascript (le Styleguide di Github possono essere un buon punto di partenza); Un'ottima lista è CSS Style Guides di CSS-Tricks;
- dei princìpi di stile grafico (colori, tipografia), e brand guidelines; ad esempio il Guardian, Twitter, Facebook, Uber;
- princìpi di stile di scrittura: ad esempio The Economist;
- una implementazione di riferimento delle guide.
Conclusioni
Come accennato, queste riflessioni sono piuttosto provvisorie, anche perché, nel mio benchmark, un modello chiaro di progettazione gerarchica delle linee guida non l'ho trovato. Pertanto, sia la metodologia che la gerarchia saranno soggette ad evoluzione.
In questo post ho colto l'occasione del progetto design.italia.it, ma metodologia e gerarchia, opportunamente adattate, possono tornare utili in qualsiasi contesto di progettazione. Naturalmente i contenuti andranno adattati ai princìpi generali, alla strategia, al brand e all'immagine dell'istituzione o dell'azienda che adotterà le linee guida.