Docs Italia beta

Documenti pubblici, digitali.

Linee guida di design per i servizi digitali della PA

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Le linee guida per il design dei servizi digitali della Pubblica Amministrazione sono uno strumento di lavoro per la Pubblica Amministrazione e i loro fornitori, e servono ad orientare la progettazione di ambienti digitali fornendo indicazioni relative al service design (progettazione dei servizi), al content design (progettazione dei contenuti), alla user research (ricerca con gli utenti), e alla user interface (interfaccia utente).

La versione stabile delle Linee Guida corrisponde a 2020.1.

Le linee guida presentano, nel capitolo introduttivo, un quadro sinottico degli obiettivi e delle azioni chiave che la pubblica amministrazione deve mettere in atto per progettare servizi orientati ai bisogni delle persone. In secondo luogo trova spazio un nuovo capitolo dedicato alla progettazione e alla prototipazione di un servizio digitale, pensato come punto di convergenza delle diverse competenze necessarie allo sviluppo di un servizio della pubblica amministrazione. Aggiornamenti significativi riguardano infine la sezione di architettura dell’informazione e quella relativa alla ricerca quantitativa.

Introduzione alle linee guida di design

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

I cittadini al centro

Designers Italia considera le effettive esigenze degli utenti come punto di partenza per pensare, costruire e migliorare i servizi digitali. Grazie all’approccio human-centered è possibile:

  • coinvolgere cittadini e operatori in ogni momento del percorso progettuale, per capire le loro necessità, generare idee e validare le scelte progettuali in corso d’opera;
  • modellare i servizi digitali sulla base di esigenze concrete e risorse esistenti evitando sprechi, duplicazione di attività e creando servizi utili;
  • disegnare e sviluppare flussi di interazione chiari, che rispondano con efficacia alle necessità dei diversi utenti, generando un’esperienza d’uso positiva;
  • strutturare i contenuti in modo semplice, con uno stile comunicativo coerente e una strategia editoriale sostenibile nel tempo.

Designers Italia copre tutte le fasi di ideazione, progettazione, sviluppo e miglioramento progressivo dei servizi della Pubblica Amministrazione, abbracciando tutte le attività digitali della PA e definendo le modalità:

  • per una corretta allocazione delle risorse, basata sull’identificazione delle priorità e l’adozione di standard che evitano sprechi e duplicazioni di attività;
  • per la realizzazione di servizi digitali efficaci, moderni, che fanno risparmiare tempo e inutili complicazioni agli utenti.

Designers Italia rappresenta il punto di riferimento per la Pubblica Amministrazione e i propri fornitori, definendo un metodo di lavoro e una lista chiara di azioni da compiere anche nel rispetto degli specifici obblighi normativi. La Pubblica Amministrazione, anche attraverso i propri fornitori, è tenuta a perseguire i seguenti obiettivi e a realizzare le relative azioni.

Obiettivi Azioni chiave Linee guida Kit di riferimento
Focalizzarsi sulle priorità e tradurre gli obiettivi in indicatori misurabili Definire in modo esplicito obiettivi, destinari del servizio e stakeholder coinvolti nel processo di progettazione. Predisporre un set di indicatori per misurare l’efficacia del servizio Service Design

Co-design workshop

Human-centered KPI (in lavorazione)

In fase di progettazione o riprogettazione di un servizio, chiarire e rappresentare le future funzionalità del servizio Mappatura delle funzioni (user stories) del servizio e realizzazione di un prototipo Prototyping

User stories

Wireframe kit

UI Kit

Favorire il raggiungimento degli obiettivi anche attraverso il pieno coinvolgimento dei fornitori di servizi Inserire nei capitolati di gara un riferimento esplicito al rispetto delle linee guida per il design dei servizi e relativi riferimenti normativi Linee guida di design per i servizi digitali della PA  
Miglioramento progressivo di un servizio esistente Adottare un’organizzazio ne del lavoro orientata al miglioramento continuo delle soluzioni, anche attraverso attività di manutenzione evolutiva e ricorso a test A/B

Accessibilità

A/B Test

A/B Test
Rendere i servizi accessibili a tutti gli utenti, secondo un principio di inclusività Rendere accessibili aspetto, contenuti, struttura, comportamento secondo i requisiti di legge Accessibilità  
Permettere all’utente di raggiungere in modo semplice le informazioni e i servizi desiderati, secondo criteri comuni alla intera PA Progettare, prototipare e testare l’architettura informativa del servizio, adottando i criteri standard di organizzazione delle informazioni della PA Architettura dell’Informazione

Information Architecture

Wireframe kit

Rendere i contenuti trovabili dagli utenti sui motori di ricerca Produrre contenuti utilizzando le regole SEO previste nelle linee guida SEO SEO
Semplificare il linguaggio dei siti della Pubblica amministrazione e dei documenti amministrativi Pubblicare contenuti e documenti sul web rispettando gli obblighi normativi e utilizzando le regole contenute nella guida al linguaggio Linguaggio Content Kit
Comprendere i bisogni a cui il servizio intende dare risposta. Osservare come gli utenti interagiscono con il servizio Condurre interviste agli utenti e test di usabilità

Usabilità

Ricerche qualitative

User Interviews

Usability test

Analizzare esperienza d’uso del sito da parte degli utenti mediante i dati delle visite relative al servizio offerto Utilizzo di un sistema di web analytics e interpretazione dei dati quantitativi Web analytics Kit Web analytics
Costruire, con un risparmio di tempi e costi, interfacce utente facili da usare, anche su dispositivi mobile Utilizzare lo UI kit della PA per progettare l’interfaccia del sito. E” possibile utilizzare direttamente il kit di sviluppo Bootstrap Italia UI Kit

Web development kit

UI Kit

Utilizzare soluzioni comuni per tipologie di enti in modo da ridurre tempi, costi ed essere più efficaci Utilizzare starter kit specifici per tipologie di enti, quando disponibili all’interno delle linee guida Kit di sviluppo e design

Kit per i siti web dei comuni

Kit per i siti delle scuole (in lavorazione)

Offrire ai cittadini un’esperienza di autenticazione ai servizi e di pagamento facile e comune ai diversi servizi della pubblica amministrazione Prevedere un’esperienza d’uso basata sulle piattaforme abilitanti (es. spid, pagopa) Normativa

UI Kit

Wireframe kit

Gestire i dati dei cittadini nel rispetto della privacy e del GDPR Includere nel processo di progettazione di un servizio i temi GDPR in un’ottica privacy by design (informativa, cookies, ecc.) In corso di pubblicazione GDPR KIT (in lavorazione)

Per discutere sul design dei servizi pubblici è disponibile il nostro forum. Per collaborare alle linee guida è possibile usare gli strumenti descritti di seguito.

Sviluppo collaborativo

Le linee guida sono un documento pubblico, e chiunque può partecipare al processo di revisione e aggiornamento attraverso gli strumenti messi a disposizione attraverso GitHub, in particolare le issues (per le discussioni) e le pull request (per le proposte di modifica).

I contenuti delle linee guida sono scritti in file .rst e possono essere aggiornati via GitHub. Qui è disponibile una guida alla sintassi RST.

Altre risorse per l’editing in formato .rst:

Le linee guida di design hanno senso solo se viste come un sistema in continua evoluzione, che segue le roadmap pubblicate in ciascuna delle sezioni di Designers Italia. Solo adottando un’ottica di miglioramento continuo possiamo sperare di renderle efficaci e utili per tutte le Pubbliche Amministrazioni. Poiché le linee guida evolvono continuamente (diciamo con frequenza mensile) diventa fondamentale introdurre il versionamento che consente di tenere traccia delle diverse release nel tempo. Grazie al versionamento, chi realizza siti aderenti alle linee guida può fare riferimento ad una precisa versione (da citare, ad esempio, quando si partecipa ad un bando di gara).

Version control e release della documentazione

Le linee guida beneficiano del version control system di GitHub, per cui esiste una traccia pubblica di tutte le modifiche effettuate e dei relativi autori. Le linee guida di design adottano un sistema di release basato sui tag di GitHub. Ogni release è etichettata secondo un sistema basato su anno e versione. Le versioni sono espresse attraverso un numero progressivo. Il sistema delle release è in vigore dal 2017, quindi la prima release delle linee guida è 2017.1 (prima release del 2017). I nuovi contenuti e le modifiche a contenuti esistenti dopo essere approvati vengono pubblicati nella versione «bozza» delle linee guida, disponibile per una discussione pubblica e revisione da parte della community ma priva di valore ufficiale. Solo successivamente, in occasione di una nuova release delle linee guida, il team di Designers Italia decide di consolidarle e farle confluire, dopo eventuali modifiche, nella versione ufficiale stabile delle linee guida.

Stile della documentazione

Le linee guida sono scritte seguendo la style guide di redazione dei testi pubblici. In particolare:

  • linguaggio semplice e comprensibile ad un pubblico ampio;
  • brevità e uso di elenchi;
  • ricorso ad esempi, meglio se supportati da immagini e link.

Consultazione della documentazione

La documentazione è disponibile su Docs Italia, la piattaforma di gestione della documentazione pubblica creata da Team per la Trasformazione Digitale. Tutti i documenti di Docs Italia possono essere fruiti anche in formato .epub e .pdf.

Kit di sviluppo e di design

Il progetto di design dei servizi pubblici digitali prevede che oltre al rilascio di linee guida ci sia il rilascio di kit di sviluppo e di design per i siti pubblici (ad es. icon kit, kit di sviluppo, ecc.). I kit - e la documentazione dei kit - possono essere citati all’interno delle linee guida, ma non sono contenuti all’interno di questo repository. I kit sono espressione delle linee guida, ma il versionamento delle linee guida e quello dei kit sono processi indipendenti.

Vai ai kit per il design dei servizi digitali della Pubblica Amministrazione

Vai ai kit di sviluppo

Service design

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Con l’adozione delle metodologie di service design si intende migliorare la progettazione e quindi le caratteristiche di un servizio, orientando funzionalità, processi e componenti intorno alle effettive esigenze degli utenti. Il servizio digitale erogato deve essere di facile utilizzo, eventualmente corredato da un contesto di informazioni sintetiche e chiare.

Principi di design dei servizi

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Principi di service design

Il service design è un approccio alla progettazione che si occupa di definire come si svolge la relazione tra un utente e un’organizzazione, generando un’esperienza di qualità per entrambe le parti coinvolte e agevolando il raggiungimento del risultato desiderato.

Quando l’organizzazione è la Pubblica Amministrazione l’utente è un cittadino: l’interazione avviene tramite una serie di canali (chiamati touchpoint) che definiscono le possibilità di relazione tra le due parti, fornendo da un lato al cittadino degli strumenti per svolgere attività specifiche e raggiungere i propri obiettivi, e dall’altro lato alla Pubblica Amministrazione un modo per rendere disponibili i propri servizi.

In fase di progettazione dei servizi ci sono alcune raccomandazioni da seguire.

Partire dai bisogni dei cittadini Significa indagare, attraverso attività di user research (come i web analytics o la realizzazione di interviste e focus group) in che modo l’utente utilizza il sistema, e fare in modo che tutte le funzionalità siano disegnate intorno alle sue esigenze e modelli mentali, consentendogli di ottenere facilmente e rapidamente ciò di cui ha bisogno, senza passaggi inutili e con istruzioni comprensibili. I servizi devono essere progettati intorno ai bisogni cittadini e non sulla base delle esigenze delle organizzazioni che li erogano

Trasparenza e collaborazione I servizi pubblici devono seguire i principi della trasparenza, fin dalle fasi iniziali. I progetti devono essere documentati in modo chiaro e aperto, per far capire gli obiettivi, favorire la collaborazione a tutti i livelli e costruire una base di conoscenze comune all’interno della Pubblica Amministrazione e tra la Pubblica Amministrazione e i cittadini. I servizi offerti devono essere semplici e chiari, in modo che il cittadino riesca a orientarsi e sia autonomo nel comprendere cosa deve fare per raggiungere lo scopo o per fare quanto gli viene richiesto. Le informazioni che supportano questo processo devono essere puntuali, non ridondanti e aggiornate. I cittadini, infine, devono avere la possibilità di esprimere feedback sull’efficacia del servizio offerto.

Tra standard e personalizzazione La progettazione dei servizi deve utilizzare al meglio metodologie, tecnologie, componenti standard indicate nel Piano per l’informatica nella pubblica amministrazione, nelle linee guida tecniche di attuazione del Piano e in particolare in queste linee guida per il design dei servizi pubblici. La standardizzazione è fondamentale per favorire la sostenibilità e l’efficacia, consentendo di progettare ogni nuovo servizio partendo da componenti già esistenti e concentrare le risorse disponibili sugli elementi di unicità del servizio, senza dover «reinventare ogni volta la ruota».

Dal digitale alla multicanalità Sempre più spesso, il digitale è il più importante punto di contatto e di erogazione del servizio. Secondo il principio della UE “digitale by default” il servizio deve essere organizzato in forma digitale, e a partire da questo bisogna progettare altri punti di contatto con il cittadino in modo da abbracciare un’ottica multicanale, che consideri in modo integrato ogni modalità di erogazione del servizio, digitale e fisica.

Semplificare È fondamentale progettare servizi concreti, creare un rapporto di fiducia tra cittadino e Pubblica Amministrazione. Il design è punto di incontro tra tecnologie e persone: semplificare e sottrarre ogni volta che è possibile, ridurre la complessità e concentrarsi sui bisogni effettivi degli utenti.

Misurare i risultati È necessario individuare gli obiettivi da raggiungere, in termini di funzionalità e processi, insieme alle metriche in grado di valutare il successo e il gradimento del progetto. I sistemi di misurazione devono essere sintetici (pochi indicatori chiave) e specifici (cioè strettamente legati al servizio che si intende misurare).

Il processo di design dei servizi si basa sull’idea che tutte le fasi – dall’ideazione alla realizzazione di un servizio – debbano essere costruite sui bisogni degli utenti. Per lo stesso motivo, le principali metriche di valutazione della efficacia di un servizio sono il livello di adozione, che si esprime in termini di copertura del servizio (quanti lo usano) e frequenza d’uso, e il gradimento da parte degli utenti.

La creazione di un sistema di valutazione misurabile è fondamentale per avviare un sostenere un percorso di miglioramento continuo.

Esempi di indicatori

La frequenza di utilizzo di un servizio digitale, la sua diffusione nella popolazione, il costo di erogazione di una singola prestazione. È possibile anche monitorare il livello di soddisfazione degli utenti, per esempio effettuando periodicamente test di usabilità che consentano di valutare la facilità d’uso di un servizio e contestualmente intraprendere azioni di miglioramento continuo.

Per esempio, in un sistema di fatturazione elettronica, un obiettivo potrebbe essere quello di “avere un processo per cui non è mai necessario stampare fatture”. Quando possibile, si raccomanda di usare metriche oggettive piuttosto che dati ricavati da questionari o rilevazioni. Per esempio, considerando il “numero di fatture stampate tradizionalmente” come un indicatore di inadeguatezza del sistema o il “numero di fatture inviate elettronicamente” come fattore di successo.

Miglioramento continuo Il progetto parte dai bisogni degli utenti e prevede di usare i prototipi per esplorare rapidamente alcune possibili risposte a questi bisogni. Una volta identificata una strada, si comincia rilasciando una prima versione e gradualmente attivando nuove funzionalità derivate dai feedback degli utenti e dalla comprensione di cosa serva veramente. L’utilizzo di un approccio di data-driven design è funzionale a capire cosa serva veramente alle persone, evitare di creare servizi e funzionalità inutili, concentrarsi sull’essenziale e migliorarlo progressivamente.

Principi generali per l’e-government

Il piano di azione della UE per l’e-government ha varato un piano di azione 2016-2020 che riporta i seguenti principi generali, coerenti con i principi di service design e con le linee guida di design dei servizi pubblici italiani

Digitale per definizione: le pubbliche amministrazioni dovrebbero fornire servizi digitali (comprese informazioni leggibili dalle macchine) come opzione preferita (pur mantenendo aperti altri canali per chi non dispone di una connessione a internet per scelta o per necessità). Inoltre i servizi pubblici dovrebbero essere forniti tramite un unico punto di contatto o uno sportello unico e attraverso diversi canali.

Principio «una tantum»: le pubbliche amministrazioni dovrebbero evitare di chiedere ai cittadini e alle imprese informazioni già fornite. Nei casi in cui sia consentito, gli uffici della pubblica amministrazione dovrebbero adoperarsi per riutilizzare internamente tali informazioni, nel rispetto delle norme in materia di protezione dei dati, in modo che sui cittadini e sulle imprese non ricadano oneri aggiuntivi.

Inclusione e accessibilità: le pubbliche amministrazioni dovrebbero progettare servizi pubblici digitali che siano per definizione inclusivi e che vengano incontro alle diverse esigenze delle persone, ad esempio degli anziani e delle persone con disabilità.

Apertura e trasparenza: le pubbliche amministrazioni dovrebbero scambiarsi le informazioni e i dati e permettere a cittadini e imprese di accedere ai propri dati, di controllarli e di correggerli; permettere agli utenti di sorvegliare i processi amministrativi che li vedono coinvolti; coinvolgere e aprirsi alle parti interessate (ad esempio imprese, ricercatori e organizzazioni senza scopo di lucro) nella progettazione e nella prestazione dei servizi.

Transfrontaliero per definizione: le pubbliche amministrazioni dovrebbero rendere disponibili a livello transfrontaliero i servizi pubblici digitali rilevanti e impedire un’ulteriore frammentazione, facilitando in tal modo la mobilità all’interno del mercato unico.

Interoperabile per definizione: i servizi pubblici dovrebbero essere progettati in modo da funzionare senza problemi e senza soluzione di continuità in tutto il mercato unico e al di là dei confini organizzativi, grazie alla libera circolazione dei dati e dei servizi digitali nell’Unione Europea.

Fiducia e sicurezza: tutte le iniziative dovrebbero andare oltre la semplice conformità con il quadro normativo in materia di protezione dei dati personali, tutela della vita privata e sicurezza informatica, integrando questi elementi sin dalla fase di progettazione. Si tratta di presupposti importanti per rafforzare la fiducia nei servizi digitali e favorirne la diffusione.

Gestione dei progetti

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Per mettere in pratica i principi di service design all’interno di un percorso di progettazione è necessario organizzare le attività in modo da guidare il processo in modo solido, coinvolgendo gli utenti e allineando fase per fase il punto di vista di tutti i soggetti della Pubblica Amministrazione coinvolti.

Ecco alcuni aspetti di cui è necessario prendersi cura per impostare al meglio il progetto, e portarlo a termine con efficacia in corerenza rispetto ai principi di sviluppo dei progetti digitali previsti dal Piano Triennale per l’informatica.

Project management

Ogni progetto di design deve prevedere determinati elementi per svilupparsi con efficienza.

  • Una chiara identificazione degli obiettivi, che devono essere pochi, specifici, espressi in modo chiaro e misurabili.

DA NON FARE —> rifacimento design del sito web

DA FARE —> analisi e ridefinizione delle modalità di fruizione dei servizi x e y del servizio z

  • L’identificazione di un product owner, una persona interna alla Pubblica Amministrazione che sappia rappresentare gli obiettivi dell’Amministrazione – incluso quello di mettere gli utenti al centro del processo di progettazione – e che abbia una chiara competenza sul servizio che si vuole digitalizzare e una chiara idea del risultato che si vuole ottenere. Per esempio, in un progetto di fatturazione elettronica, il product owner sarà una persona che conosce bene i processi di fatturazione e sarà in grado di guidare gli esecutori del progetto fornendo consigli e indicazioni su come inviare e processare tali fatture, i dati che queste devono contenere, ecc.
  • L’identificazione di un project manager e la creazione di un team interdisciplinare dedicato al progetto, con competenze di ricerca, prototipazione e sviluppo di servizi. La composizione del team varia in relazione all’ampiezza del progetto e alle sue caratteristiche di base (nuovo servizio, redesign di servizio esistente, ottimizzazione di un servizio esistente).
  • La definizione degli strumenti e ambienti di gestione del progetto, privilegiando strumenti di lavoro open source, aperti e collaborativi, ispirati a una metodologia agile. Per essere efficaci non basta che un team sia affiatato e comunichi, è necessario costruire un ambiente di lavoro aperto, in cui sia possibile produrre e sviluppare prodotti in modo collaborativo. I team di lavoro devono sentirsi parte di un network più ampio fondato sulle competenze e sul riconoscimento delle best practice internazionali. La Pubblica Amministrazione si è dotata di alcuni spazi di lavoro con queste caratteristiche, da Docs Italia (documenti di progetto) a Forum Italia (forum di discussione) fino a GitHub Italia (condivisione codice sorgente). All’interno di Designers Italia tutti i progetti possono contribuire concretamente ad alimentare il design system centrale, costruendo valore attraverso la collaborazione tra tutte le parti che compongono la Pubblica Amministrazione.
Metodo di lavoro

In termini generali il design dei servizi richiede un percorso basato sull’analisi dei bisogni degli utenti, l’esplorazione di soluzioni attraverso la prototipazione rapida, l’esecuzione di una soluzione attraverso componenti di design e sviluppo tecnico, e infine un percorso di miglioramento continuo basato sulla misurazione dell’efficacia.

Un processo di design adeguato deve essere orientato ai risultati e deve quindi contemporaneamente:

  • saper esplorare il problema;
  • assicurarsi di ideare e costruire cose che servono;
  • costruirle bene;
  • avviare un percorso di miglioramento continuo.

Esistono diverse modalità pratiche “per fare design” e per organizzare i processi di progettazione, a partire dalle competenze chiave dei membri del gruppo di lavoro. Da questo punto di vista il processo di service design è perfettamente compatibile con modalità di lavoro lean e agile, tipiche dei processi di produzione di tecnologie digitali così importanti nello sviluppo dei servizi digitali. È possibile strutturare il percorso di progettazione per sprint di lavoro successivi, svolgendo dei cicli rapidi di ascolto dell’utente, ideazione di soluzioni, prototipazione, e continuare a iterare in questo modo facendo evolvere man mano il prototipo in una soluzione solida, da rendere disponibile a tutti.

Tipologie di progetti

Per favorire la nascita di una nuova generazione di servizi digitali, le Pubbliche Amministrazioni devono attivare percorsi di design dei servizi che possiamo classificare in tre aree.

Ottimizzazione di servizi esistenti Nel caso di ottimizzazione di servizi esistenti è necessario prima di tutto raccogliere tutti i dati disponibili relativi al loro utilizzo attuale (tramite web analytics, interviste utente oppure usability test) e analizzarli per capire quali sono le maggiori criticità e opportunità di miglioramento. Sulla base di questi elementi sarà possibile mappare l’attuale esperienza utente dei diversi profili coinvolti (user journey), evidenziare le criticità e immaginare quali percorsi è necessario migliorare (user stories). Le user stories sono il punto di partenza per riprogettare i flussi di interazione e le interfacce del servizio, effettuando interventi mirati.

Riprogettazione di servizi esistenti in chiave digitale Nel caso di processi di digitalizzazione di servizi esistenti bisognerà adottare una prospettiva più ampia in fase iniziale, per capire al meglio le necessità degli utenti coinvolti (personas) e le potenzialità delle piattaforme digitali nel migliorare la loro esperienza d’uso. In questa fase sarà necessario capire l’intero sistema che supporta l’erogazione del servizio (system map) e verificare quali aspetti possono essere digitalizzati e quali no, e capire come le due dimensioni si integrano. Terminati questi passaggi sarà possibile identificare le funzionalità chiave del servizio digitale e iniziare l’attività di progettazione, sempre attraverso la creazione di storie (user stories) che possono guidare l’attività di design e sviluppo in parallelo. In corso di sviluppo del prototipo, sarà bene verificare con gli utenti l’avanzamento in modo da validare la direzione progettuale e l’usabilità del servizio (test di usabilità).

Ogni volta che si progetta un servizio digitale bisogna analizzare e riprogettare anche le altre forme di interazione con il cittadino relative a quel servizio (per esempio attraverso uffici aperti al pubblico). Possiamo distinguere diverse forme di relazione tra canali digitali e canali tradizionali di offerta di un servizio. In alcuni casi, i servizi digitali arricchiscono e supportano servizi che utilizzano canali fisici (ad esempio, il servizio digitale che permette di prendere un appuntamento per il rinnovo della carta d’identità in Comune); in altri casi, offrono soluzioni alternative al cittadino (per esempio il servizio che permette di ottenere un certificato on line e in alternativa andare a richiederlo allo sportello di un Comune). In casi ulteriori, infine, l’attivazione di un servizio digitale può produrre lo “spegnimento” delle modalità tradizionali di offerta del servizio (per esempio una procedura on line di partecipazione ai bandi che sostituisce la consegna di un modulo cartaceo): in questi casi si parla di “switch off” di un servizio.

Creazione di nuovi servizi L’attività di creazione di nuovi servizi necessita uno sguardo ancora più ampio, partendo dalla mappatura di tutti gli stakeholder coinvolti e delle loro reciproche relazioni La comprensione dell’ecosistema aiuta a identificare quali attori è necessario coinvolgere o attivare, e quali dinamiche possono facilitare (o rendere molto difficile) la costruzione e l’implementazione del progetto. Sempre in questa fase, sarà necessario raccogliere il punto di vista degli utenti tramite attività di ricerca sul campo (intervista in contesto e osservazione), per capire al meglio le loro attuali criticità e necessità. I risultati della fase di analisi dell’ecosistema e di ricerca possono essere utilizzati per facilitare una o più sessioni di co-progettazione (co-design workshop) dove stakeholder, progettisti e utenti vengono invitati a dialogare e svolgere una serie di esercizi di ideazione insieme, in modo da dare forma a delle proposte di soluzioni. I risultati delle fase di ideazione possono essere a loro volta formalizzati in una serie di proposte di design (information architecture, flussi di esperienza e storie), da prototipare e validare prima di procedere all’esecuzione finale del progetto.

Il punto di riferimento per la costruzione di un percorso di design dei servizi è il sito Designers Italia che, oltre alle presenti linee guida offre kit e case histories.

Le competenze per il design dei servizi

I processi sono importanti, ma lo sono ancora di più le competenze. Il design è un insieme di competenze funzionali e manageriali.

Le competenze funzionali vanno dalla conduzione di attività di ricerca con gli utenti alla prototipazione, fino alla capacità di progettazione e realizzazione di interfacce e contenuti. Queste competenze generano dei ruoli che possono variare in funzione delle caratteristiche del progetto e dell’assetto di un team. Questi ruoli possono richiedere specializzazioni verticali su temi specifici (es. visual design) o trasversali in grado di coprire diversi aspetti all’interno del processo progettuale (dalla ricerca alla prototipazione).

Le competenze manageriali includono la capacità di lavorare in team in modo collaborativo, gestire le relazioni con tutti gli attori coinvolti nel percorso di innovazione, avere un forte orientamente al raggiungimento degli obiettivi e misurare costantemente l’andamento dei progetti. Competenze essenziali riguardano aspetti come l’empatia e la comunicazione, la capacità di inquadrare i problemi e gestire l’incertezza, quella di passare rapidamente dalla teoria alla pratica e saper risolvere i problemi.

Designers Italia incoraggia e indirizza verso l’acquisizione di competenze di design, offrendo kit, guide e storie (case histories) e partecipando direttamente ad alcuni progetti della Pubblica Amministrazione.

Design dei servizi: verso una mappa delle competenze
Competenze funzionali Perché
Ricerca con gli utenti Comprendere il bisogno
Prototipazione Esplorare rapidamente soluzioni alternative
Realizzazione e gestione di un prodotto Realizzare servizi efficaci per le persone
Competenze manageriali  
Orientamento ai risultati Gestire l’incertezza, arrivare al risultato
Capacità di ascolto e di di sintesi Saper ascoltare gli altri e tradurre in elementi di valore per il progetto
Curiosità e apprendimento continuo Ricercare e trovare nuove soluzioni ai bisogni
Teamwork Favorire lo scambio di idee e la trasversalità
Problem solving Inquadrare i problemi e produrre soluzioni, con concretezza

E-Procurement

Le attività di design dei servizi pubblici sono in carico alle Pubbliche Amministrazioni che possono accedere a competenze esterne secondo i classici strumenti di e-procurement disponibili. Designers Italia ha tra i suoi obiettivi quello di raccogliere e mette a disposizione informazioni documenti costruiti allo scopo di facilitare le Amministrazioni nella stesura dei capitolati tecnici.

Identificazione delle priorità

Le Pubbliche Amministrazioni, a tutti i livelli, devono esprimere una migliore capacità di identificare le priorità e concentrarsi sulle cose importanti, costruirle bene e continuare a migliorarle nel tempo senza dispersione di energie, tempo e risorse. Lo strumento di coordinamento previsto dal Piano Triennale per la definizione delle priorità è quello della definizione degli ecosistemi. La comprensione delle priorità deve essere effettuata:

  • attraverso l’analisi e la gestione degli stakeholder;
  • attivando una buona conoscenza dei bisogni degli utenti.

Il ruolo degli stakeholder

Il service design mette a disposizioni dei progettisti e dei funzionari della Pubblica Amministrazione una serie di strumenti utili all’analisi delle necessità di tutti gli attori coinvolti, che aiutano a mettere a fuoco tutte le variabili necessarie e quindi gestire la complessità del progetto, strutturando il servizio in modo che sia usabile ed efficace per l’utente, e allo stesso tempo efficiente per gli operatori della Pubblica Amministrazione.

È fondamentale che tutte le persone che sono coinvolte a vario titolo nella ideazione e nella realizzazione di un servizio, a partire dai più alti livelli dell’Amministrazione che ne è responsabile, siano direttamente chiamate a provare direttamente il servizio e a valutarlo in tutti i suoi aspetti di funzionamento pratico, prima della sua effettiva uscita.

System maps

Le mappature del sistema sono delle rappresentazioni sintetiche di tutti gli attori coinvolti nell’erogazione del servizio, e dei flussi di motivazioni e valori che scambiano. La mappatura del sistema guarda al servizio dall’alto, e cerca di rispondere alle seguenti domande:

  • quali sono i soggetti coinvolti;
  • quali interessi li motivano a partecipare al servizio;
  • che cosa offre e riceve ciascun soggetto.

Le mappe di sistema hanno il vantaggio di descrivere in modo visivo e sintetico una serie di contenuti che diversamente andrebbero descritti in modo testuale o verbale. Il vantaggio della rappresentazione visiva è quello di semplificare la complessità, portando alla luce i tratti salienti del sistema. Le mappe di sistema aiutano a chiarire le idee all’interno di gruppi di lavoro estesi, allineando il punto di vista su come è strutturato il sistema e quali sono gli scambi di valori in corso. Le mappature aiutano a focalizzare la discussione, ragionando in modo partecipato rispetto agli elementi che funzionano o non funzionano di un sistema e come potrebbero essere migliorati. La mappatura del sistema può assumere diverse strutture a seconda delle esigenze del gruppo di lavoro:

Stakeholder Map: si tratta di un diagramma a due assi che permette di mappare i diversi stakeholder coinvolti interrogandosi sulla loro partecipazione al progetto in questione. La mappa si costruisce partendo da due assi, relativi al livello di interesse e al tipo di influenza. Incrociando queste due variabili si ottengono quattro quadranti, che suggeriscono diverse tipologie di comportamento: per esempio se uno stakeholder è molto interessato ma poco influente sarà necessario tenerlo informato sugli avanzamenti del progetto ma nulla di più, mentre se uno stakeholder è molto influente ma poco interessato sarà necessario prestare attenzione alle sue esigenze e cercare di anticiparle. La matrice aiuta ad assumere il punto di vista di ciascun soggetto, capire gli interessi in gioco e agire di conseguenza.

Ecosystem Map: se prendiamo in considerazione un servizio e tutti i soggetti coinvolti nella sua erogazione (dall’utente finale all’operatore della Pubblica Amministrazione) possiamo descrivere le loro relazioni evidenziando i passaggi di informazioni, documenti, denaro o altro valore, che intercorrono tra l’uno e l’altro. Le mappe di sistema vengono costruite mettendo al centro il cittadino, e disponendo attorno a lui tutti i soggetti interessati: più vicino quelli maggiormente a contatto con l’utente e mano a mano più lontano quelli con le relazioni più deboli o nascoste. In un secondo momento, vengono tracciate delle linee di collegamento che forniscono l’informazione relativa allo scambio che avviene tra ciascun soggetto e soggetti vicini, costruendo man mano un’immagine completa della struttura su cui si basa il servizio.

Coinvolgere gli stakeholder

I processi di design dei servizi richiedono il coinvolgimento di tutti gli stakeholder il cui ruolo è collegato all’attività progettuale. Questo permette di capire le loro prospettive e motivazioni, allineare diversi punti di vista attorno ad una soluzione unica, creare consenso e prendere le decisioni necessarie più rapidamente. Il coinvolgimento dei dirigenti della Pubblica Amministrazione e degli addetti ai lavori dei vari Ministeri è necessario fin dalle fasi di definizione dei requisiti progettuali e del concept di servizio, per arrivare ai momenti di validazione e test del prodotto. La loro partecipazione può avvenire durante incontri di avanzamento lavori sul progetto o in sede di workshop progettuali, in cui si lavora in modo collaborativo attorno ad alcuni temi chiave del servizio in corso di definizione.

Conoscere gli utenti

Avere un’idea chiara delle necessità delle persone che utilizzano i servizi che progettiamo, e conoscere nel dettaglio la loro esperienza di interazione con i canali digitali o fisici che rappresentano il servizio, è fondamentale per costruire una base solida su cui strutturare il progetto o da cui partire per migliorarlo. In particolare ci sono due strumenti chiave che facilitano la comprensione degli utenti:

  • i personas (o profili utente) come metodo di analisi e racconto delle diverse tipologie di utenti di un servizio;
  • le user journey (o mappature dell’esperienza) come metodo di analisi e progettazione dell’interazione con il servizio.

Questi strumenti possono essere utilizzati dal gruppo di lavoro per ragionare sui vari aspetti che compongono il servizio e individuare funzionalità e flussi di interazione, oppure possono essere utilizzati per coinvolgere gli utenti all’interno del percorso di progettazione tramite delle sessioni di lavoro partecipato (co-design). In generale, si alimentano dei risultati di attività di ricerca quantitativa e qualitativa volta a comprendere i bisogni degli utenti

Personas e profili utente

I personas sono delle rappresentazioni astratte degli utenti che aiutano il team di progetto ad analizzare i loro bisogni e immaginare soluzioni concrete che rispondono ai loro problemi. Partendo dai risultati della ricerca qualitativa (interviste individuali) si creano dei raggruppamenti che poi vengono raccontati sotto forma di personaggi-tipo, ovvero personas. La costruzione dei personas può essere anche elaborata sulla base di ipotesi condivise da un gruppo di professionisti della Pubblica Amministrazione o cittadini che prendono parte ad attività di co-progettazione. In questo caso viene fornito un foglio di lavoro che aiuta il gruppo di partecipanti a ragionare sulle variabili chiave di quel personaggio, e immaginarsi la sua vita, le sue abitudini, le sue esigenze. La narrazione dei personas può coinvolgere una serie diversa di variabili a seconda del contesto di progettazione, e di cosa è effettivamente utile al progettista. In generale, contengono:

  • nome, età, professione: dati anagrafici che aiutano a capire la tipologia di utente;
  • un motto: una frase esemplificativa che rappresenta la sua attitudine
  • bisogni, attività, sfide: le necessità e criticità collegate al servizio analizzato;
  • utilizzo della tecnologia: quali dispositivi e con quale frequenza;
  • strumenti di riferimento: applicazioni o servizi che utilizza spesso.

Vai al Kit Personas

User Journey

Lo strumento di user journey (detto anche customer journey o experience map) viene utilizzato per descrivere in modo sintetico l’esperienza d’uso di un determinato servizio. La rappresentazione sintetica permette di condensare in poco spazio un grande quantitativo di informazioni legate al processo, che richiederebbe diversamente lunghi paragrafi di descrizione senza di fatto facilitare la comprensione dei diversi passaggi e la riflessioni sugli aspetti migliorabili.

La mappa dell’esperienza viene costruita mettendo sull’asse orizzontale tutte le fasi in cui si svolge l’interazione con un servizio seguendo una sequenza logica-temporale. Per ogni fase vengono poi elencate le attività e i touchpoint con cui l’utente interagisce, costruendo una rappresentazione sintetica della sua esperienza, attraverso tutto ciò che avviene prima, durante e dopo. La mappatura può essere infine completata evidenziando la reazione emotiva che caratterizza l’esperienza dell’utente nelle varie fasi, che può essere caratterizzata da soddisfazioni o frustrazioni.

Lo strumento di mappatura della user journey permette di analizzare tutti i flussi dell’esperienza di un servizio esistente o di un servizio in corso di definizioni, evidenziando le criticità su cui intervenire e le differenze tra le modalità di interazione dei diversi possibili utenti.

Il workshop di co-design

I workshop di co-design sono dei momenti di progettazione in cui un gruppo eterogeneo di partecipanti (progettisti, utenti, stakeholder della Pubblica Amministrazione e rappresentanti di aziende private) si ritrovano con l’obiettivo di ragionare insieme su alcuni aspetti chiave di un servizio. Queste sessioni di lavoro collaborativo hanno la capacità di allineare il punto di vista dei diversi attori coinvolti nell’esecuzione di un servizio, sollevando i problemi chiave e allo stesso tempo accelerando il processo di identificazione di soluzioni promettenti.

I workshop risultano in particolare molto utili quando al termine di un’attività preliminare di ricerca si inizia la definizione di storie e requisiti per la progettazione del servizio, ovvero nel momento di passaggio tra la fase di analisi e quella di design e sviluppo della soluzione individuata. I workshop hanno anche il beneficio di radunare ruoli che altrimenti rischiano di non incontrarsi mai, e avvicinare gli operatori della Pubblica Amministrazioni ai cittadini che utilizzano i propri servizi.

Organizzare dei workshop di co-progettazione richiede di svolgere i seguenti passaggi.

  1. Identificazione di un obiettivo chiaro, raggiungibile mediante la sessione di lavoro collaborativo, assicurandosi quindi di aver già raccolto tutte le informazioni necessarie per impostare al meglio l’attività di co-progettazione e non farla diventare una perdita di tempo per mancanza di dati o lacune nella preparazione.
  2. Compilazione di una lista di partecipanti da invitare al workshop, cercando di raccogliere l’adesione di tutti gli stakeholder coinvolti sul progetto e di coinvolgere una piccola rappresentanza per tutti gli attori rilevanti (utenti, operatori del servizio, soggetti privati, altri esperti o progettisti). Gli inviti dovranno dichiarare l’obiettivo della sessione e dare un’idea chiara del risultato atteso.
  3. Scelta di luogo, data e durata della sessione. La durata consigliata è di circa mezza giornata (4 ore), in modo da avere tempo per introdurre al meglio le attività, svolgere gli esercizi programmati e discutere i risultati. Il workshop può quindi iniziare o concludersi con un momento di ristoro, che permette ai partecipanti di stabilire un contatto tra di loro e approfondire alcune discussioni in modo più informale.
  4. Definizione nel dettaglio dell’agenda per la sessione di workshop, identificando una serie di esercizi da svolgere insieme e assegnando una durata a ogni esercizio. Se l’obiettivo è quello di generare insieme idee relative al servizio in questione, ci possono essere diverse strategie di impostazione della sessione. In alcuni casi si può ad esempio partire dai bisogni dell’utente, mappando i personas e le loro user journey per individuare le criticità attuali e utilizzarle come ispirazione per generare idee. In altri casi si può invece partire da una mappa di sistema, riflettendo su tutte le criticità legate ai diversi ruoli e all’insieme di relazioni necessarie per abilitare il servizio e utilizzando il metodo del card sorting per discutere quali opportunità prioritizzare nel dare forma ad un nuovo servizio o nel migliorare il servizio esistente. Le scalette e strumenti citati sono solo esempi, ciascun gruppo di lavoro dovrà pensare una propria agenda per il workshop e ad un mix di esercizi adatti rispetto allo specifico contesto ed obiettivo progettuale.

Durante il workshop è importante fin da subito chiarire lo spirito di una sessione di lavoro collaborativo e invitare i partecipanti a ricordare che non ci sono idee giuste o idee sbagliate: l’importante è riuscire a costruire l’uno sulle idee e il contributo dell’altro in modo propositivo. Bisogna riuscire a mettere da parte per un momento le gerarchie, i vincoli, le leggi, e pensare fuori dagli schemi, esplorando soluzioni mai pensate fino a quel momento in totale libertà. Solo in un secondo momento, guidati dal moderatore, si passerà ad analizzare ogni idea emersa in modo più attento, per capire se è (o non è) attuabile e in caso negativo cosa possiamo conservare di quell’idea per migliorare ciò che abbiamo.

Vai al Kit di Designers Italia per i Co-Design Workshop

I Kit di Designers Italia

Un aspetto rilevante del processo di design di servizi pubblici è la possibilità di fare riferimento al design systems creato all’interno di Designers Italia, utilizzando kit di design. I kit di design accompagnano i diversi aspetti di creazione di un servizio. Una delle caratteristiche dei kit è quella di favorire la collaborazione, suggerendo modalità di lavoro di team come i workshop e proponendo l’utilizzo di strumenti digitale di collaborazione (cosiddetti collaboration tool). I kit sono accompagnati da case studies e approfondimenti che ne mostrano la facilità di utilizzo.

Designers Italia offre modalità concrete attraverso cui qualsiasi progetto digitale della Pubblica Amministrazione può contribuire ad arricchire il design systems mettendo a disposizione: componenti ed elementi di interfaccia; prototipi ben documentati; case histories; risultati di ricerca o altro.

Accessibilità

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

SI DEVE

I soggetti destinatari della legge n. 4/2004 (definiti “soggetti erogatori”), tra cui le Pubbliche amministrazioni, hanno l’obbligo di garantire l’accesso universale ai propri servizi informatici e telematici.

I soggetti erogatori di soluzioni ICT devono rendere i propri strumenti informatici accessibili e usabili, compresi i siti web e le applicazioni mobili, in particolare devono:

  • valutare la conformità ai requisiti di accessibilità degli strumenti informatici (siti web e applicazioni mobili; - compilare una dichiarazione di accessibilità e pubblicarla sul sito web o nello store dell’applicazione mobile;
  • predisporre un meccanismo di feedback per ricevere le segnalazioni dagli utenti.

Tali disposizioni sono aggiornate nella legge n. 4/2004 che recepisce la Direttiva Europea n. 2016/2102 e regolamentate dalle “Linee guida sull’accessibilità degli strumenti informatici”.

Definizione

Per accessibilità si intende la capacità dei sistemi informatici, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari.

Nessun utente deve essere discriminato e deve quindi poter accedere alle informazioni e ai servizi digitali erogati dalla Pubblica amministrazione.

Principi per l’accessibilità

L’accessibilità è caratterizzata da quattro solidi principi:

Sono quindi conformi i servizi realizzati tramite sistemi informatici, inclusi i siti web e le applicazioni mobili, che presentano le caratteristiche di accessibilità al contenuto e fruibilità delle informazioni.

Linee guida e criteri di successo

Le linee guida sull’accessibilità degli strumenti informatici riportano quanto descritto nell’articolo 11 della legge n. 4/2004 e referenziano la norma UNI EN 301549:2018 che stabilisce uno standard europeo per garantire il rispetto dei principi e dei requisiti di accessibilità per prodotti e servizi ICT, quali:

  • hardware
  • web
  • documenti non web
  • software
  • applicazioni Mobili
  • documentazione e servizi di supporto
  • postazioni di lavoro a disposizione del dipendente con disabilità

La norma armonizzata riflette lo standard W3C Web Content Accessibility Guidelines (WCAG) 2.1

Un sito conforme alle specifiche delle WCAG 2.1 è conforme alle WCAG 2.0 ma non viceversa, in quanto la versione aggiornata aggiunge nuovi criteri di successo obbligatori (di livello “A” e “AA”), ovvero:

Come le PA possono valutare la conformità di un sito web o un’applicazione mobile

La conformità alle WCAG 2.1 deve essere rispettata come requisito minimo per i siti web in fase di sviluppo o in esercizio dopo la data di entrata in vigore delle Linee Guida. A partire dal 23 settembre 2020, tale conformità dovrà essere rispettata anche per tutti gli altri siti web sviluppati in precedenza, in sintesi:

  • entro il 23 settembre 2019, per un sito web pubblicato dal 23 settembre 2018;
  • entro il 23 settembre 2020, per un sito web pubblicato prima del 23 settembre 2018;
  • a decorrere dal 23 giugno 2021, per le applicazioni mobili.

Come rilasciare una dichiarazione

Le PA hanno l’obbligo di pubblicare una dichiarazione di accessibilità per ciascun sito e applicazione mobile. A tale scopo, l’Agenzia per l’Italia Digitale ha predisposto una procedura online conforme all’Allegato 1 delle Linee Guida.

Le informazioni presenti nella dichiarazione devono essere ricavate da:

  • un’autovalutazione effettuata direttamente dal soggetto erogatore;
  • una valutazione effettuata da terzi;
  • una valutazione effettuata con il “Modello di autovalutazione”, Allegato 2 delle Linee Guida.

Il Responsabile della Transizione Digitale del soggetto erogatore, riceve il link che deve essere esposto con la dicitura “Dichiarazione di accessibilità”:

  • nel footer, per quanto riguarda i siti web;
  • nella sezione dedicata alle informazioni generali riportate nello store, per quanto riguarda l’applicazione mobile.

L’accesso alla piattaforma è possibile solo se la mail istituzionale del Responsabile della Transizione Digitale è correttamente indicizzata sul catalogo IPA.

Meccanismo di feedback e procedura di attuazione

Le PA devono rendere disponibile un meccanismo che consenta a chiunque di segnalare i problemi di accessibilità e richiedere un intervento tempestivo da parte dell’amministrazione.

In caso di assenza del meccanismo di feedback, di soluzione insoddisfacente o mancata risposta entro 30 giorni dalla segnalazione, l’utente può far ricorso al Difensore Civico per il Digitale tramite la procedura di attuazione presente sulla dichiarazione pubblicata dall’ente erogatore.

Obiettivi accessibilità

Entro il 31 marzo di ogni anno le PA devono pubblicare nei propri siti web gli “Obiettivi di accessibilità per l’anno corrente”. Per tale scopo, l’Agenzia per l’Italia Digitale ha predisposto un’applicazione online per ricevere dalle amministrazioni gli obiettivi.

Gli obiettivi vanno pubblicati sui siti delle PA nella sezione “amministrazione trasparente/Altri contenuti/Accessibilità e Catalogo di dati, metadati e banche dati”.

Normativa

La normativa completa e aggiornata sull’accessibilità è disponibile sul sito dell’Agenzia per l’Italia digitale.

FAQ

Sono disponibili ulteriori approfondimenti sull’accessibilità nella sezione FAQ predisposta sul sito dell’Agenzia per l’Italia digitale.

Normativa

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Codice dell’amministrazione digitale

Decreto legislativo 7 marzo 2005, n.82 da ultimo integrato e modificato dal Decreto Legislativo 13 dicembre 2017, n. 217

  1. Pagamenti elettronici (art.5): In questo articolo è sancito l’obbligo, per le PA e i soggetti a cui si applica il CAD, di accettare pagamenti sia attraverso la piattaforma di pagamento elettronico, messa a disposizione dall’AGID, che attraverso altre forme di pagamento elettronico, inclusi i micro-pagamenti (basato sull’uso del credito telefonico). Nell’articolo sono sanciti gli obblighi di pubblicazione di dati e le informazioni strumentali all’utilizzo degli strumenti di pagamento elettronico.
  2. Comunicazioni tra imprese e amministrazioni (art. 5 bis): la presentazione di istanze, dichiarazioni, dati e lo scambio di informazioni e documenti (anche a fini statistici) tra imprese e PA (e viceversa) avviene solo utilizzando tecnologie ICT.
  3. Utilizzo del Domicilio digitale (art.6 , 6-bis, 6-ter, 6-quater, 6-quinquies).
  4. Diritto a servizi on-line semplici e integrati (art. 7): i soggetti rientranti nell’ambito di applicazione del CAD consentono agli utenti di esprimere la soddisfazione rispetto alla qualità, anche in termini di fruibilità, accessibilità e tempestività, del servizio reso all’utente stesso e pubblicano sui propri siti i dati risultanti, ivi incluse le statistiche di utilizzo. In caso di violazione di questi obblighi, gli utenti, fermo restando il diritto di rivolgersi al difensore civico digitale di cui all’articolo 17, possono agire in giudizio.
  5. Partecipazione democratica elettronica viene favorita anche attraverso l’utilizzo di forme di consultazione preventiva per via telematica sugli schemi di atto da adottare (art.9).
  6. Difensore civico digitale e responsabile transizione digitale (art.17): l’articolo stabilisce che ogni pubblica amministrazione affidi ad un ufficio dirigenziale l’attuazione delle linee strategiche per la riorganizzazione e la digitalizzazione dell’amministrazione. Viene inoltre istituito presso l’AGID l’ufficio del difensore civico per il digitale a cui chiunque può presentare segnalazioni relative a presunte violazioni del CAD e di ogni altra norma in materia di digitalizzazione ed innovazione della pubblica amministrazione.
  7. Siti Internet delle pubbliche amministrazioni (art. 53): individuazione dei principi secondo cui devono essere costruiti.
  8. Siti pubblici e trasparenza (art. 54): obblighi di pubblicazione in “Amministrazione trasparente” (rinvio a d.lgs. 33/2013).
  9. Validità dei documenti informatici (artt. 22, 23, 23-bis, 23-ter): validità delle copie informatiche di documenti con riferimento preciso circa le diverse possibilità (copia digitale del documento cartaceo, duplicazione digitale, ecc.).
  10. Conservazione digitale dei documenti (artt. 43-44 ): gestione della conservazione dei documenti e del relativo processo da parte di un Responsabile della conservazione che si può avvalere di soggetti pubblici o privati che offrono idonee garanzie.
  11. Dati identificativi delle questioni pendenti dinanzi autorità giudiziaria di ogni ordine e grado (art.56): Inserimento dei dati identificativi delle questioni pendenti, nonché delle sentenze e delle altre decisioni del giudice amministrativo e contabile […], anche nel sistema informativo interno e sul sito istituzionale, osservando le cautele previste dalla normativa in materia di tutela dei dati personali.
  12. Sistema pubblico per la gestione delle identità digitali e modalità di accesso ai servizi erogati in rete dalle pubbliche amministrazioni (art.64): Istituzione del Sistema pubblico per la gestione delle identità digitali, SPID (comma 2- bis) e utilizzo di SPID per i servizi online della pubblica amministrazione (comma 2 - quater).
  13. Istanze e dichiarazioni presentate alle pubbliche amministrazioni per via telematica (art. 65).
  14. Open data (artt. 52 e 68): Responsabilità delle PA nell’aggiornare, divulgare e permettere la valorizzazione dei dati pubblici secondo principi di open government.
Decreti attuativi del CAD
  • Decreto del Presidente del Consiglio dei Ministri 3 dicembre 2013 Regole tecniche in materia di protocollo informatico ai sensi del CAD (particolare rilievo assumono gli obblighi di pubblicazione a carico delle P.A., di cui all’art. 5, comma 3, relativamente al manuale di gestione; da art. 18, commi 2 e 3, circa l’indirizzo della casella di posta elettronica certificata direttamente associata al registro di protocollo, da utilizzare per la protocollazione e gli altri indirizzi di posta elettronica istituiti).
  • Decreto del Presidente del Consiglio dei Ministri 13 novembre 2014 Regole tecniche in materia di formazione, trasmissione, copia, duplicazione, riproduzione e validazione temporale dei documenti informatici nonché di formazione e conservazione dei documenti informatici delle pubbliche amministrazioni ai sensi del CAD (particolare rilievo assume obbligo di pubblicazione a carico delle P.A. di cui all’art. 10 per cui, ai fini della trasmissione telematica di documenti amministrativi informatici, le PA pubblicano sui loro siti gli standard tecnici di riferimento, le codifiche utilizzate e le specifiche per lo sviluppo degli applicativi software di colloquio).

Contenuti minimi dei siti della PA

La normativa italiana obbliga le PA a pubblicare determinate informazioni nei loro siti web.

Siti web istituzionali

Amministrazione trasparente

Inserire una sezione denominata «Amministrazione trasparente», contenente una struttura prevista dall’allegato A del decreto. E’ necessario inserire la voce «Amministrazione trasparente», preferibilmente in una posizione che ne garantisca il raggiungimento da tutte le pagine interne del sito (es: nel footer).

Pubblicità legale

Posizionare nella home page un collegamento all’area in cui si effettua la pubblicità legale, identificandola con la dicitura «Pubblicità legale» oppure, ove previsto dalle specifiche normative, «Albo pretorio» (es: amministrazioni locali) o semplicemente «Albo» (es: istituzioni scolastiche).

Partita IVA

La partita IVA deve essere pubblicata in home page per tutti i soggetti titolari di partita IVA. Si consiglia di inserire tale informazione all’interno del blocco di contenuti nel footer di pagina contenente i dati di contatto.

PEC

I siti web istituzionali delle PA sono tenute a pubblicare nella home page del sito un indirizzo di posta elettronica certificata a cui il cittadino possa rivolgersi per qualsiasi richiesta formale, come previsto dal Codice dell’Amministrazione Digitale (CAD). Inserire la mail nel footer di pagina contenente i dati di contatto.

Pubblicazione atti di carattere normativo e amministrativo generale

Le PA , “fermo restando quanto previsto per le pubblicazioni nella Gazzetta Ufficiale della Repubblica italiana dalla legge 11 dicembre 1984, n. 839, e dalle relative norme di attuazione,“pubblicano sui propri siti istituzionali i riferimenti normativi con i relativi link alle norme di legge statale pubblicate nella banca dati «Normattiva» che ne regolano l’istituzione, l’organizzazione e l’attività. Sono altresì pubblicati le direttive, le circolari, i programmi e le istruzioni emanati dall’amministrazione e ogni atto, previsto dalla legge o comunque adottato, che dispone in generale sulla organizzazione, sulle funzioni, sugli obiettivi, sui procedimenti […]”.

Trattamento dati personali

Individuazione delle modalità semplificate per l’informativa e l’acquisizione del consenso per l’uso dei cookie. Banner per la richiesta di consenso all’uso dei cookie e pagina per informazioni sui cookie.

  • Riferimento normativo: Garante per la protezione dei dati personali - Provvedimento dell’8 maggio 2014 - Gazzetta Ufficiale n. 126 del 3 giugno 2014
  • Riferimento UI: Homepage/footer

Informativa trattamento dati personali - Informativa sul trattamento dei dati personali mediante link «Privacy».

Riferimenti normativi tematici

Accessibilità
  1. Legge 9 gennaio 2004, n. 4, (aggiornata dal Decreto legislativo 10 agosto 2018, n.106) Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici.
  2. Decreto legislativo 10 agosto 2018, n.106, attuazione della direttiva (UE) 2016/2102 relativa all’accessibilità dei siti web e delle applicazioni mobili degli enti pubblici).
  3. Direttiva (UE) 2016/2021 del 26 ottobre 2016, relativa all’accessibilità dei siti web e delle applicazioni mobili degli enti pubblici.
  4. Decisione di esecuzione (UE) 2018/2048 della Commissione del 20 dicembre 2018, relativa alla norma armonizzata per i siti web e le applicazioni mobili elaborata a sostegno della direttiva (UE) 2016/2102 del Parlamento europeo e del Consiglio.
  5. Decisione di esecuzione (UE) 2018/1524 della Commissione dell’11 ottobre 2018, che stabilisce una metodologia di monitoraggio e definisce le disposizioni riguardanti la presentazione delle relazioni degli Stati membri conformemente alla direttiva (UE) 2016/2102 del Parlamento europeo e del Consiglio relativa all’accessibilità dei siti web e delle applicazioni mobili degli enti pubblici.
  6. Decisione di esecuzione (UE) 2018/1523 della Commissione dell’11 ottobre 2018, che istituisce un modello di dichiarazione di accessibilità conformemente alla direttiva (UE) 2016/2102 del Parlamento europeo e del Consiglio relativa all’accessibilità dei siti web e delle applicazioni mobili degli enti pubblici.
  7. Decreto Ministeriale 30 aprile 2008, regole tecniche disciplinanti l’accessibilità agli strumenti didattici e formativi a favore degli alunni disabili. (GU Serie Generale n.136 del 12-06-2008).
  1. allegato A linee guida editoriali per i libri di testo.
  2. allegato B linee guida per l’accessibilità e la fruibilità del software didattico da parte degli alunni disabili.
  1. Decreto-legge 18 ottobre 2012, n. 179, (convertito con modificazioni dalla L. 17 dicembre 2012, n. 221), all’art. 9 (Documenti informatici, dati di tipo aperto e inclusione digitale) è stato previsto, tra l’altro, l’obbligo per le amministrazioni pubbliche […] di pubblicare nel proprio sito web, gli obiettivi di accessibilità per l’anno corrente e lo stato di attuazione del «piano per l’utilizzo del telelavoro» nella propria organizzazione.
Trasparenza
  1. Legge 7 agosto 2015, n. 124 , recante: «Disposizioni per garantire ai cittadini di accedere a tutti i dati, i documenti ed i servizi in modalità digitale».
  2. Legge 7 agosto 1990, n. 241 «Nuove norme in materia di procedimento amministrativo e di diritto di accesso ai documenti amministrativi». L’art.2 stabilisce tra l’altro che: per ciascun procedimento, sul sito internet istituzionale dell’amministrazione è pubblicata, in formato tabellare e con collegamento ben visibile nella homepage, l’indicazione del soggetto a cui è attribuito il potere sostitutivo e a cui l’interessato può rivolgersi.
  3. Legge 18 giugno 2009, n. 69, «Disposizioni per lo sviluppo economico, la semplificazione, la competitività nonché in materia di processo civile» , in particolare l’articolo 21 «Trasparenza sulle retribuzioni dei dirigenti e sui tassi di assenza e di maggiore presenza del personale»
  4. Legge 6 novembre 2012, n. 190 «Disposizioni per la prevenzione e la repressione della corruzione e dell’illegalità nella Pubblica Amministrazione» incluse le «Specifiche tecniche per la pubblicazione dei dati ai sensi dell’art. 1 comma 32 Legge n. 190/2012» di ANAC - versione 1.2 di gennaio 2016
  5. Decreto legislativo 14 marzo 2013, n. 33 «Riordino della disciplina riguardante il diritto di accesso civico e gli obblighi di pubblicità, trasparenza e diffusione di informazioni da parte delle pubbliche amministrazioni».
  6. Determinazione ANAC n. 6/2015 Linee guida in materia di tutela del dipendente pubblico che segnala illeciti (c.d. whistleblower)
  7. Legge 7 agosto 2015, n. 124, recante: «Disposizioni per garantire ai cittadini di accedere a tutti i dati, i documenti ed i servizi in modalità digitale».
  8. Delibera ANAC n. 39 del 20 gennaio 2016 sull’assolvimento degli obblighi di pubblicazione e di trasmissione delle informazioni all’Autorità Nazionale Anticorruzione, ai sensi dell’art. 1, comma 32 della legge n. 190/2012.
  9. Decreto legislativo 18 aprile 2016, n. 50 «Codice dei contratti pubblici» (vigente): l’art. 29 reca la disciplina riguardante Principi in materia di trasparenza (perciò si coordina con Decreto legislativo n. 33/2013)
  10. Delibera ANAC n. 1309 del 28/12/2016 Linee guida operative sull’attuazione dell’accesso civico generalizzato (FOIA), Esclusioni e Limiti.
  11. Delibera ANAC n. 1310 del 28/12/2016 Prime linee guida recanti indicazioni sull’attuazione degli obblighi di pubblicità, trasparenza e diffusione di informazioni contenute nel d.lgs. 33/2013 come modificato dal d.lgs. 97/2016.
Privacy
  1. Decreto legislativo 30 giugno 2003, n. 196 e ss.mm.i. Codice in materia di protezione dei dati personali (c.d. Codice della Privacy).
  2. Deliberazione del 15 maggio 2014, n. 243 Linee guida in materia di trattamento di dati personali, contenuti anche in atti e documenti amministrativi, effettuato per finalità di pubblicità e trasparenza sul web da soggetti pubblici e da altri enti obbligati
  3. Individuazione delle modalità semplificate per l’informativa e l’acquisizione del consenso per l’uso dei cookie» dell’8 maggio 2014
  4. Decreto legislativo 10 agosto 2018, n. 101 Disposizioni per l’adeguamento della normativa nazionale alle disposizioni del regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati).
GDPR

Regolamento (UE) 2016/679 del Parlamento Europeo del Consiglio del 27 aprile 2016 relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati):

  1. Obbligatorietà della designazione del Responsabile della protezione dei dati (Data Protection Officer - DPO) per alcune tipologie di enti pubblici e privati (art.37)
  2. Diritto dell’interessato di richiedere, in qualunque momento e secondo le modalità e alle condizioni previste dal Regolamento, l’accesso ai dati personali e la rettifica o la limitazione del trattamento (artt. 15-16-18).
  3. Diritto alla cancellazione o diritto all’oblio (art. 17)
  4. Diritto alla portabilità dei dati (art. 20)
  5. Diritto di opposizione (art. 21)
  6. La liceità del trattamento è individuabile nella base giuridica (art. 6): il consenso dell’interessato, la necessità di eseguire un contratto o misure precontrattuali, la necessità di adempiere un obbligo legale, la salvaguardia di interessi vitali, l’esecuzione di un compito di interesse pubblico o connesso all’esercizio di pubblici poteri, il perseguimento di un legittimo interesse
  7. Obbligo del titolare di rendere un’informativa sul trattamento dei dati personali sia quando i dati sono raccolti con il consenso dell’interessato sia quando la raccolta prescinde dal consenso (artt. 13-14)
  8. Protezione dei dati fin dalla progettazione e per impostazione predefinita (art.25)
  9. Predisposizione e la tenuta dei Registri delle attività di trattamento (art. 30)
  10. Sicurezza dei dati personali e la notifica dell’eventuale violazione dei dati (artt. 32-33)
  11. Valutazione d’impatto sulla protezione dei dati e l’eventuale consultazione preventiva con il Garante (artt. 35-36)
Comunicazione pubblica
  1. Legge 7 giugno 2000, n. 150 Disciplina delle attività di informazione e di comunicazione delle pubbliche amministrazione.

Prototyping

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Introduzione

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

La progettazione di un ambiente digitale si basa sui risultati delle attività di user research e co-progettazione con gli utenti, usate per far emergere i bisogni effettivi delle persone per cui si sta progettando. Un buon metodo di lavoro può essere la stesura di liste di bisogni ordinate per priorità, ai quali affiancare la relativa funzione da progettare per soddisfarli. Tra gli strumenti a disposizione per affrontare questa fase, uno dei più utilizzati è quello delle user stories, che permette una rappresentazione ordinata delle azioni che il sistema dovrà realizzare per rispondere ai bisogni dei diversi utenti coinvolti.

La fase successiva del processo di progettazione è la creazione di prototipi che - dando forma al servizio - consentano al gruppo di lavoro di esplorare rapidamente una o più soluzioni alternative. È questo lo scopo della prototipazione: utilissima per verificare e comunicare le principali funzioni d’uso di un prodotto e offrire un’idea dell’ambiente informativo in cui l’utente si troverà a interagire per raggiungere il proprio scopo. Il prototipo permette infatti la simulazione di uno o più scenari d’uso del servizio, riproducendo l’esperienza che l’utente avrà con il servizio prima ancora di iniziare a svilupparlo.

In sintesi, progettare un servizio significa tradurre i bisogni degli utenti in funzioni e rappresentare queste funzioni all’interno di un ambiente informativo facile da comprendere per le persone che lo usano. Alla prototipazione di un servizio concorrono tutte le specializzazioni del design, che contribuiscono a delineare in modo più preciso questo ambiente, proponendo dei modelli di user interface e di content design che verranno consolidati attraverso una serie di iterazioni sul prototipo, fino a raggiungere una forma stabile. Una formalizzazione chiara dei bisogni degli utenti è anche funzionale a mettere a fuoco le funzionalità del software che dovrà realizzarli, per esempio per capire se questo software è già disponibile presso l’Amministrazione o altre Amministrazioni, oppure se e come deve essere sviluppato o modificato.

Dai bisogni degli utenti alle user stories

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

In particolare, i punti di partenza da cui avviare l’attività di progettazione possono essere sintetizzati in alcuni strumenti operativi che abbiamo affrontato nel capitolo delle Linee Guida dedicato al service design:

  • personas, ossia profili verosimili di utenti del servizio delineati in base ai risultati della ricerca, rappresentativi di un gruppo di utenti;
  • user journey, ossia la rappresentazione del percorso compiuto dall’utente interagendo con i touchpoint fisici o digitali del servizio, elaborata a partire dai personas e dalle loro esperienze d’uso del servizio in questione.

In questo capitolo faremo un passo in avanti, introducendo strumenti come le user stories e gli scenari d’uso. Questi elementi ci aiutano a concentrarci sulle persone che useranno il servizio, ad assumere il loro punto di vista e avere una lista chiara dei loro bisogni, evidenziando priorità e possibili criticità. Sulla base di user stories e scenari, procederemo poi alla fase di prototipazione vera e propria.

Storyboard e scenari d’uso, attraverso una sintesi dei dati di ricerca, permettono di definire soluzioni progettuali che tengono al centro le personas: descrivono in modo realistico la sequenza di azioni che queste compiono all’interno del servizio, identificando e mettendo in ordine di priorità le caratteristiche più importanti dal loro punto di vista. Si tratta di una narrazione macroscopica, non troppo dettagliata: una sorta di sceneggiatura all’interno della quale, con un approccio più analitico, si possono generare le user stories. All’interno di uno scenario possono esistere più user stories, che specificano con maggior dettaglio un preciso caso d’uso del servizio.

Scuola - Esempi di scenari d’uso del servizio  
Iscrizione all’asilo nido
  1. Arrivo sul sito dell’istituto scolastico
  2. Individuo la sezione dedicata alle iscrizioni
  3. Accedo al percorso di iscrizione con SPID
  4. Inserisco tutte le informazioni richieste
  5. Ricevo conferma dell’avvenuta iscrizione, e le indicazioni per contattare la scuola in cui ho iscritto mio figlio
Scelta dell’istituto scolastico
  1. Arrivo su un sito del Ministero dell’istruzione dedicato alle iscrizioni a scuola
  2. Inserisco parametri relativi al tipo di scuola che preferisco
  3. Ricevo in risposta una lista di scuole, filtrate e ordinate sulla base del grado di vicinanza rispetto alle mie preferenze
  4. Salvo le scuole più interessanti in un’area di preferiti
  5. Approfondisco una scuola in particolare leggendo maggiori dettagli e visitando il sito Internet
Pagamento servizi scolastici
  1. Ricevo un avviso on line che richiede il pagamento della mensa
  2. Clicco sul link e arrivo sul sito della scuola
  3. Accedo con SPID
  4. Inserisco le informazioni necessarie per il pagamento
  5. Scelgo il metodo di pagamento
  6. Ricevo una ricevuta di pagamento
   
Comuni - Esempi di scenari d’uso  
Archivio documenti personali (contravvenzioni)
  1. Entro nel sito del Comune
  2. Accedo con SPID a un’area riservata
  3. Vedo la lista delle contravvenzioni ricevute su tutto il territorio italiano
Rinnovo documenti
  1. Entro sul sito dedicato al rinnovo della carta d’identità
  2. Seleziono la richiesta di rinnovo
  3. Seleziono il Comune di appartenenza
  4. Scelgo una data e ora tra quelle disponibili nel calendario
  5. Ricevo conferma della prenotazione dell’appuntamento
Pagamento tributi
  1. Sul mio telefono ricevo una notifica che la scadenza per il pagamento della TARI è in arrivo
  2. Apro l’app dedicata al pagamento delle imposte e dei servizi pubblici per verificare la data di scadenza e l’importo
  3. Decido di effettuare il pagamento
  4. Inserisco le informazioni necessarie per il pagamento
  5. Ricevo una ricevuta del pagamento

Le user stories sono una descrizione informale delle funzioni di un servizio, espressa dal punto di vista dell’utente secondo una struttura che definisce il ruolo di chi la esprime, l’azione che vuole o deve compiere e l’obiettivo che muove all’azione:

Io come [personas] vorrei [funzione] per [bisogno].

Le user stories facilitano la comprensione delle caratteristiche richieste al servizio per tutti i membri del team al lavoro sul progetto. Per non perdere di vista il quadro generale possono essere organizzate per scenari d’uso (vedi sopra) o story map, ovvero mappe in cui raggruppare le user stories in base al tema o al tipo di attività, ordinandole per priorità.

I bisogni e le funzioni individuati grazie ai risultati della ricerca sugli utenti sono un’ottima base per definire le user stories.

Il kit per gli scenari e le user stories

Ecco una lista di esempi di alcune risposte (funzioni) ai bisogni degli utenti del sito di una scuola o di un comune, espressi in termini di user stories.

Scuola      
Personas Bisogni Funzioni User stories
Genitore Iscrivere mio figlio all’asilo nido Compilare online il modulo on line per l’iscrizione Io come genitore vorrei compilare on line il modulo per iscrivere mio figlio al nido
  Scegliere la scuola migliore per mio figlio Confrontare on line i diversi istituti scolastici Io come genitore vorrei confrontare online le scuole secondo parametri oggettivi, in modo da scegliere la scuola migliore per mio figlio
  Assicurare pasto e merenda ai propri figli mentre sono a scuola Attivare e pagare online del servizio mensa in modo rapido e sicuro Io come genitore vorrei poter attivare e pagare online l’iscrizione al servizio mensa, in modo da assicurare pasti a mio figlio quando è a scuola
Comune      
Personas Bisogni Funzioni User stories
Cittadino Controllare le contravvenzioni ricevute Visualizzare l’elenco delle multe in una pagina personale Io come cittadino vorrei accedere a una pagina web riservata dove controllare le contravvenzioni che ho ricevuto
  Rinnovare la carta di identità Prenotare on line l’appuntamento per il rinnovo nel Comune di residenza Io come cittadino vorrei prenotare online l’appuntamento all’ufficio comunale, in modo da rinnovare la mia carta d’identità
  Essere in regola con il pagamento della tassa sui rifiuti (TARI) Effettuare il pagamento on line della TARI in modo facile e sicuro. Io come cittadino vorrei poter pagare i servizi pubblici online in modo facile e sicuro, inclusa la TARI, in modo da essere in regola con i pagamenti

Un metodo simile al precedente prevede la mappatura delle funzioni del sistema concentrandosi sui due profili di utilizzatore - l’utente finale e il gestore del servizio - corrispondenti al front-end e al back-end del sistema. Questo approccio favorisce la creazione di una relazione chiara tra la progettazione dell’interfaccia utente e quella delle funzioni che permettono di abilitare il servizio.

BISOGNI FUNZIONI PER GLI UTENTI DI FRONTEND FUNZIONI PER GLI UTENTI DI BACKEND
Cambiare residenza Mostrare all’utente i contatti e gli orari di apertura dell’ufficio anagrafe del comune in cui l’utente si è trasferito e il sistema per prenotare un appuntamento
  • Permette di definire i contatti dell’ufficio

    Permette di definire gli orari di apertura del servizio

Permette di gestire il numero di prenotazioni disponibili per ciascuna fascia oraria

Dopo aver definito in modo chiaro bisogni e funzioni di un servizio, siamo in grado di avviare il processo di prototipazione.

Prototipare un servizio

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Un prototipo è un modello sperimentale che permette di testare un’idea in maniera rapida ed economica, permettendo al team di rifinire il progetto o di valutare cambiamenti di approccio, se si rivelano necessari, prima di investire tempo e denaro nello sviluppo vero e proprio. Uno dei principali vantaggi del processo di prototipazione consiste nella possibilità di effettuare delle sessioni di validazione dell’esperienza e del concept già nelle prime fasi della progettazione, mantenendo gli utenti al centro del processo di design. Allo stesso modo, un prototipo aiuta a coinvolgere gli stakeholder fin dalle prime fasi del progetto, mostrando loro le soluzioni che il team sta immaginando per rispondere ai bisogni degli utenti e agli obiettivi del progetto. Infine, grazie a un prototipo è più facile valutare l’impatto tecnologico di un progetto, e la presenza di limiti o opportunità tecnologiche è un fattore rilevante nella evoluzione o modifica del prototipo che si sta realizzando.

Nella prima fase il prototipo è low-fi (low fidelity), a bassa fedeltà. Questo tipo di manufatto ha diversi vantaggi:

  • aiuta il designer a elaborare il modello d’interazione a supporto dell’esperienza desiderata, verificando le proprie scelte direttamente “in pagina”;
  • favorisce l’iterazione, permettendo al designer di rielaborare in tempi ridotti i feedback ricevuti da altri membri del team o dagli stakeholder in tempi ridotti;
  • elimina potenziali distrazioni derivanti da elementi grafici e contenuti dettagliati, dando quindi la possibilità di concentrarsi solamente sulle funzionalità e i flussi.

La prototipazione hi-fi (high fidelity) interviene in un secondo momento, quando l’organizzazione semantica e i flussi d’interazione sono stati validati grazie al prototipo low-fi ed è possibile progredire nella progettazione delle schermate inserendo gli elementi d’interfaccia. Il prototipo hi-fi prevede la definizione precisa di tutti gli elementi di user interface e content design, lavorando in tre direzioni:

  • alimenta il processo di condivisione con gli stakeholder e gli altri membri della squadra di progetto;
  • consente di indirizzare e documentare il lavoro di sviluppo front-end del servizio digitale, facilitando la collaborazione di designer e developers;
  • permette di verificare il concept coinvolgendo gli utenti in sessione di validazione delle scelte progettuali.

Prototipi a bassa e media definizione

I wireframe

Un wireframe è l’illustrazione a due dimensioni dell’interfaccia di una pagina. Ha come priorità:

  • l’organizzazione degli elementi interattivi e dei blocchi di contenuto nello spazio disponibile sullo schermo;
  • evidenziare le funzionalità disponibili
  • mostrare la sequenza di passaggi (userflow) che l’utente deve fare per concludere un processo;

Date queste priorità, i wireframe non comprendono stili, colore o grafica: possiamo chiamare questo tipo di wireframe anche wireframe lo-fi o mid-fi, o a bassa o media definizione. Tra i suoi scopi, il wireframe ha quello di mostrare le relazioni tra i contenuti del sito e i flussi di interazione, e condurre progressivamente l’utente al raggiungimento dei propri obiettivi. Questa funzione è assolta dai wireframe interattivi (o user flow), sequenze di wireframe che permettono di simulare il percorso dell’utente attraverso link e menù di navigazione.

il wireframing fa largo utilizzo di pattern, ovvero di modelli di rappresentazione dei contenuti e forme di interazione standard nel mondo web. Il wireframe kit di Designers Italia presenta una serie di pattern che definiscono alcuni modelli di contenuto e forme di interazione tipiche dei siti e servizi della Pubblica Amministrazione Italiana e che facilitano il processo di prototipazione di un servizio offrendo una solida base da cui partire. Esempi di pattern sono il content type “scheda servizio”, che definisce il modello di presentazione di un servizio pubblico, oppure le modalità di interrogazione di un motore di ricerca.

I modelli di pagina e di interazione sono costruiti attraverso una libreria di componenti come bottoni, campi di input, blocchi di testo, ecc. I componenti sono “i mattoncini” attraverso cui si costruiscono le interfacce, gli elementi base della grammatica che regola l’interazione tra l’utente e il sistema. Nel wireframe kit il focus è sulle tipologie di componenti e non sulle loro caratteristiche specifiche, che sono oggetto di definizione nella successiva fase di prototipazione ad alta fedeltà.

Un esempio di “wireframe”, o prototipo a “bassa fedeltà”

Figura 1 - Un esempio di “wireframe”, o prototipo a “bassa fedeltà”.

Nella Figura 1 è mostrato un esempio di prototipo costruito con un programma di design, ma per costruire un wireframe si possono usare diversi metodi, dalla carta ai numerosi software specifici presenti sul mercato.

Wireframe interattivo (user flow) per il rinnovo della carta di identità:

Figura 2

Wireframe interattivo (user flow) per il rinnovo della carta di identità:

  1. Entro sul sito dedicato al rinnovo della carta d’identità
  2. Seleziono la richiesta di rinnovo
  3. Seleziono il Comune di appartenenza
  4. Scelgo una data e ora tra quelle disponibili nel calendario
  5. Ricevo conferma della prenotazione dell’appuntamento
Il wireframe kit

Il prototipo a bassa fedeltà può essere modellato utilizzando il Wireframe Kit messo a disposizione da Designers Italia che può agire in diversi ambiti nella fase di design.

Per creare l’architettura di un sito o di un’app utilizzando il Wireframe Kit, sarà quindi sufficiente scegliere e assemblare i componenti e i pattern di cui il kit è composto.

Il Wireframe Kit è pubblicato su Github, una piattaforma che permette di visionare tutte le fasi di progettazione e sviluppo grazie al controllo di versione. Il wireframe kit è realizzato con il software Sketch, ma può essere esportato per utilizzarlo con altri software di prototipazione, se necessario.

Un esempio dei componenti presenti nel Wireframe Kit.

Figura 2 - Un esempio dei componenti presenti nel Wireframe Kit.

Tipi di content  type presenti nel wireframe kit

Figura 3 - Tipi di content type presenti nel wireframe kit

Pattern di ricerca: user flow

Figura 4 - Pattern di ricerca: user flow

UI Wireframe kit Esempio animato

Figura 5 - Un esempio di composizione dei componenti del Wireframe Kit per creare o adattare un content type alle esigenze del prototipo. Il software scelto per costruire il Wireframe Kit èSketch, uno strumento che permette la gestione dinamica dei simboli e la condivisione della libreria in modo trasversale a tutti i file su cui si intende lavorare. Sketch permette di cambiare le caratteristiche dei singoli elementi e personalizzarli in modo rapido e intuitivo. Alternativamente, è possibile importare il file Sketch in altri programmi di prototipazione, comeAdobe XD,Studio, oFigma.

Dai wireframe ai prototipi in alta fedeltà (hi-fi)

Una volta costruito, testato e migliorato il wireframe a bassa fedeltà, possiamo passare alla realizzazione di un prototipo ad alta fedeltà (o hi-fi) per agevolare la comprensione e la condivisione del progetto, poter realizzare test e facilitare l’avvio della fase di sviluppo

A questo scopo potremo utilizzare

Content design

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

La sezione content design della guida affronta i temi legati agli ambienti informativi in cui si muove l’utente che fruisce servizi digitali. In particolare si occupa della search engine optimization, del linguaggio e della gestione dei contenuti e infine della loro organizzazione (architettura dell’informazione).

Architettura dell’informazione

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

L’architettura dell’informazione consiste nell’organizzazione semantica e logica di ambienti informativi, sia fisici sia digitali, e serve a rendere i servizi pubblici più facili da trovare, da capire e da usare. Una buona architettura dell’informazione aiuta le persone a comprendere ciò che le circonda e a trovare ciò che cercano, sia online che offline. Lavorare su questo ambito implica una riflessione sulla struttura dell’informazione e sul linguaggio. L’architettura dell’informazione è più efficace se è progettata intorno ai reali bisogni delle persone: per questo si parla di user-centered design.

Obiettivo del paragrafo è offrire indicazioni pratiche relative alla progettazione dei sistemi di navigazione, delle tipologie di contenuti (content type), dei flussi di interazione con l’utente e alla modellazione dei contenuti (per esempio attraverso ontologie e vocabolari controllati).

La progettazione di un ambiente informativo può partire dalla definizione delle funzioni di base svolte tipicamente dalla Pubblica Amministrazione nei confronti di cittadini e imprese. Possiamo elencarne alcune:

  • lo scambio di denaro (per esempio quando si deve pagare una multa o ricevere la pensione);
  • l’iscrizione a qualcosa (per esempio quando si deve scegliere la scuola per proprio figlio);
  • la prenotazione di un appuntamento (per esempio quando si deve prenotare una visita medica);
  • l’offerta di lavoro o di progetti (per esempio quando si partecipa a un concorso o a un bando);
  • l’informazione sull’attività amministrativa (ad esempio quando si pubblica una notizia o un evento);
  • la regolamentazione della vita dei cittadini (ad esempio attraverso leggi o decreti attuativi);
  • la certificazione di qualcosa o l’autorizzazione a fare qualcosa (come nel caso di un cambio di residenza o del rilascio di un passaporto).

Contenuti, persone e contesto

Progettare l’architettura dell’informazione significa soddisfare i bisogni degli utenti, creando e organizzando l’informazione per dare senso alle cose, nel rispetto del contesto organizzativo e di fruizione dei servizi.

Architettura dell’informazione

Architettura dell’informazione

L’analisi delle esigenze informative e dei comportamenti di navigazione degli utenti contribuisce alla progettazione di una efficace architettura dell’informazione. Per analizzare il tipo di pubblico del sito web è necessario definire: - i profili di utenti a cui si rivolge l’informazione o il servizio - i bisogni, ovvero le necessità informative e operative degli utenti

È bene prendere decisioni sulla base dell’analisi dei dati riferiti all’utente in particolare: - i dati statistici di navigazione sul sito per comprendere il comportamento dell’utente - la realizzazione di interviste e test di usabilità per comprendere l’esperienza e la competenza generale di navigazione dell’utente target.

Per un approfondimento sui metodi di ricerca sugli utenti vai alla sezione dedicata alla user research.

La seconda area rilevante per l’architettura dell’informazione è quella relativa ai contenuti. Per contenuto si intendono le informazioni di tipo non strutturato (testi, immagini, video) o strutturato (dati e metadati) veicolate da pagine web, documenti, applicazioni grazie alle quali la Pubblica Amministrazione offre i propri servizi ai cittadini. Il content journey è uno strumento adatto per fare una mappa preliminare dei bisogni informativi degli utenti: un modello è disponibile all’interno del kit per la progettazione dei contenuti. La mappatura delle informazioni esistenti e rilevanti per progettare un servizio può essere fatta attraverso un’attività di content inventory e la loro formalizzazione può avvenire attraverso ontologie e vocabolari controllati. Spesso l’esito di questa analisi determina quella che viene definita una gap analysis, che evidenzia i contenuti e i dati presenti attualmente sul sito e quelli che dovranno essere prodotti, modificati o eliminati nella nuova versione del servizio.

Per un approfondimento su dati e metadati vai alle linee guida per i cataloghi dati.

Per un approfondimento sui contenuti non strutturati vai alla sezione dedicata al linguaggio.

Nella progettazione di un sito web, l’architettura dell’informazione deve necessariamente adattarsi al contesto di riferimento, per essere coerente con gli obiettivi, la strategia e la cultura dell’organizzazione. Per analizzare il contesto è necessario quindi considerare e definire:

  • gli obiettivi strategici dell’Amministrazione
  • le risorse economiche disponibili
  • le direttive/norme vigenti che vincolano il progetto
  • la cultura dell’amministrazione, intesa anche come la propensione al cambiamento
  • l’ambito tecnologico e gli standard esistenti per la Pubblica Amministrazione
  • le risorse umane coinvolte nel progetto, e le loro competenze tecniche
  • i limiti operativi, relativi ad esempio alla logistica, alla sicurezza

Per approfondire, vai alla sezione dedicata al design di un servizio e utilizza la ecosystem map.

Definizione e organizzazione dei contenuti

Uno dei principi dell’architettura dell’informazione è tenere conto del contesto e delle funzioni delle organizzazioni e dei servizi che esprimono. Questo significa che è possibile definire, come vedremo, standard di architettura dell’informazione specifici per il mondo della Pubblica Amministrazione. In secondo luogo, sarà possibile avviare un’attività di modellazione più specifica, partendo da una segmentazione degli enti e delle funzioni ad esse associate. In pratica, l’organizzazione della conoscenza all’interno della Pubblica Amministrazione ha alcune regole generali che è bene conoscere e che devono essere utilizzate in ogni ambito; e alcune regole (standard) che si possono applicare all’interno di ambiti specifici. Per fare un esempio, è possibile definire uno standard per l’architettura dell’informazione dei Comuni italiani, senza che sia necessario affrontare il problema per ciascuno dei migliaia dei siti web dei Comuni italiani. L’utilizzo di standard nella definizione di contenuti, dati e nella loro classificazione è alla base di concetti come l’interoperabilità e in definitiva rappresenta la creazione di un linguaggio digitale comune alla Pubblica Amministrazione italiana. L’ architettura dell’informazione partecipa alla fase di progettazione e prototipazione di un sito o di un servizio digitale attraverso strumenti come il wireframe kit (che contiene modelli di content type e pattern di interazione) e il kit per la definizione dei sistemi di navigazione e dei modelli di contenuto di un sito

I content type

In fase di progettazione, i contenuti di un sito web devono essere organizzati in diverse tipologie, o content type. Esempi di content type sono una scheda di presentazione di un servizio, una form per inserire dati anagrafici, una notizia o una scheda di presentazione di un evento. Sulla base delle funzioni che deve svolgere un sito, è possibile definire una lista dei content type. Vediamone alcuni.

Esempi di content type Funzioni principali
Scheda unità organizzativa Descrive una unità organizzativa come un ufficio o una funzione politica, definendone le caratteristiche, gli obiettivi e le persone che ne fanno parte
Scheda luogo Descrive un luogo rilevante per la Pubblica Amministrazione e gli utenti a cui si rivolge, definendone le coordinate geografiche e altri aspetti come le modalità di accesso da parte dei cittadini
Evento Descrive un evento, definendone le caratteristiche, il luogo e le date e dando la possibilità di rappresentarlo attraverso una mappa e un calendario
Notizia Descrive un evento, definendone le caratteristiche, il luogo e le date e dando la possibilità di rappresentarlo attraverso una mappa e un calendario
Scheda servizio Descrive il servizio e fa capire all’utente come utilizzarlo, nella sua forma tradizionale e/o digitale

In una fase iniziale di progettazione, per ciascuno dei content type occorre riportare le caratteristiche essenziali ad avviare il processo di prototipazione. Successivamente si procederà a definire i dettagli della struttura dati e a una progressiva evoluzione del prototipo (comprensivo delle funzioni di front-end e di back-end) come riportato in figura.

Funzione informativa: presentare un servizio
I sistemi di navigazione

Un sito web presenta abitualmente un sistema di navigazione principale (menù di navigazione), che a sua volta può essere organizzato in uno o più livelli e che genera il menù di navigazione di un sito web. La struttura di navigazione può essere riprodotta anche attraverso la creazione di breadcrumb, normalmente posizionati nella parte alta di ciascuna delle pagine web di cui si compone il sito. Ad esempio, nella pagina dedicata all’ufficio anagrafe di un sito web di un Comune potremmo trovare il breadcrumb Amministrazione/Uffici/Ufficio anagrafe.

La struttura di navigazione di base aiuta l’utente ad orientarsi e a comprendere rapidamente l’organizzazione delle informazioni presenti sul sito.

Accanto al sistema di navigazione primario, esistono diversi altri sistemi per connettere contenuti, costruire percorsi di navigazione e permettere agli utenti di raggiungere i promo scopi. Ad esempio, in un sito che ha una sezione dedicata agli eventi gli eventi vengono classificati definendone le coordinate geografiche e il periodo temporale, e questo rende possibile offrire una rappresentazione mediante mappe e calendari. Allo stesso modo, se si definisce un vocabolario controllato di argomenti che interessano agli utenti di un Comune (es. casa) e si classificano tutti i contenuti usando questi argomenti, sarà possibile generare liste di contenuti che condividono questa proprietà e, in definitiva, facilitare la navigazione e la ricerca per gli utenti.

sito di un Comune

Pagina standard per il sito di un Comune che raggruppa tutti i contenuti del sito che condividono l’etichetta “Cantieri”

Un altro caso tipico di relazione tra contenuti è quella relativa ai flussi di fruizione di un servizio web. Prendiamo ad esempio il servizio che abilita il pagamento di una multa. Attraverso una serie di passaggi sequenziali l’utente sarà condotto dalla login a un documento (la multa) e da qui a una form che consente l’inserimento dei dati di pagamento.

flusso di fruizione di un servizio digitale

Rappresentazione del flusso di fruizione di un servizio digitale: percorso di navigazione e relazioni tra contenuti.

Home page, pagine di ricerca e aree personali

Home page, pagine di ricerca e aree personali sono tre punti di ingresso chiave per comprendere e accedere al sistema. La home page di un sito ha la funzione di punto di ingresso, ed è tipicamente il luogo in cui l’utente ottiene una visione chiara della missione di un sito e delle sue funzioni chiave. Un modo semplice per organizzare la home page è definire una struttura coerente rispetto al sistema di navigazione principale, per esempio attraverso un layout a fasce.

Header
Apertura (descrive la funzione principale del sito, o “missione”)

Sezione 1

Riporta contenuti rilevanti contenuti nella sezione e consente accesso agli altri

Sezione 2

Riporta contenuti rilevanti contenuti nella sezione e consente accesso agli altri

Sezione 3

Riporta contenuti rilevanti contenuti nella sezione e consente accesso agli altri

Footer

Modello di home page di un sito web organizzato in quattro sezioni principali e prototipo della home page di un sito scolastico che segue questo approccio

Homepage di una scuola

I siti web che offrono servizi digitali ai cittadini mettono a disposizione un’area personale dell’utente a cui si accede mediante credenziali di accesso (per esempio Spid) e che possiede un proprio sistema di navigazione contestuale. In termini generali, l’area personale serve a gestire l’interazione di un utente con il sistema. Un modo semplice per organizzare un’area personale è prevedere un’area messaggi, un’area che mostra la lista delle procedure in corso dei servizi attivati e un’area destinata ad archiviare l’esito delle azioni compiute in passato (es. lista dei pagamenti, dei documenti ricevuti, delle iscrizioni fatte).

messaggi

Servizi

  • disponibili
  • in corso di attivazione
  • attivi

Documenti e pagamenti

  • lista pagamenti
  • lista documenti e certificati ottenuti

Il motore di ricerca ha il compito di fornire liste di risultati corrispondenti alle ricerche formulate dall’utente cercando tra i testi del sito e/o utilizzando i sistemi di classificazione (come ad esempio categorie e tag) del sistema.

Partendo dal testo che l’utente ha iniziato a generare, la funzione di autocompletamento permette di indirizzare l’utente, suggerendo possibili ricerche. Il filtering è il processo di raggruppamento dei contenuti di un sito in sottoinsiemi più piccoli, lavorando su una o più dimensioni semantiche contemporaneamente (filtri multipli). Se abbiamo ben strutturato i contenuti, saremo in grado di proporre all’utente la possibilità di usare dei filtri (per categorie, per tipologia di contenuto, per autore, per data…) per raffinare progressivamente la ricerca e raggiungere il risultato. Se ben strutturati, i sistemi di filtering possono svolgere la funzione di un sistema di navigazione, aiutando l’utente a prendere consapevolezza dell’ambiente informativo in cui si muove, di ciò che può trovare e di quali sono le migliori strategie per trovarlo.

Il sorting è il criterio di ordinamento dei risultati di ricerca. Per esempio, un utente che intende trovare dei bandi pubblici potrebbe ricercare un argomento e successivamente voler ordinare i risultati sulla base della data, in modo da poter vedere tra i primi risultati quelli più recenti.

Ontologie e standard

L’emergere del web come ambiente aperto di comunicazione e condivisione di informazioni ha favorito la nascita di un approccio alla modellazione dell’informazione più astratto rispetto allo specifico sistema (o punto di contatto con l’utente) che si sta progettando. Pensare ai contenuti come indipendenti dalla piattaforma che li ospita permette di renderli disponibili, per esempio attraverso API, per l’utilizzo da parte di altri o per la progettazione di altri punti di contatto con il cittadino (per esempio una app) utilizzando quanto previsto nelle linee guida relative alla interoperabilità.

Per questo motivo è bene costruire content type e sistemi di classificazione sulla base di strutture formali di rappresentazione della realtà più astratte, che possiamo esprimere in termini di ontologie e di vocabolari controllati. Facciamo un esempio: un sito della Pubblica Amministrazione prevede normalmente content type per definire un ufficio (es. Ufficio anagrafe), un luogo (es. Palazzo Chigi) o un ruolo (es. direttore dipartimento). Queste informazioni possono essere modellate utilizzando le ontologie relative a persone, organizzazioni e luoghi ( vedi alcune ontologie già disponibili). L’ eventuale informazione relativa a un titolo di studio di una persona che lavora per la Pubblica Amministrazione può essere espressa attraverso un vocabolario controllato, e anche in questo caso ne esiste già uno.

Le ontologie

Come leggiamo nelle linee guida per i cataloghi dati della Pubblica Amministrazione: “Le ontologie si stanno sempre più sviluppando come strumento formale di rappresentazione, sulla base di specifici requisiti, di un dominio di conoscenza. In particolare, al fine di massimizzare la condivisione della conoscenza e garantire interoperabilità semantica, l’ontologia consente di descrivere la semantica dei dati con una terminologia concordata che può essere poi successivamente riusata anche in altri contesti con simili obiettivi. Tipicamente l’ontologia non è un obiettivo di per sé ma costituisce una base solida per poter sviluppare, al di sopra di essa, applicazioni e servizi avanzati semantici, sempre più diffusi con lo sviluppo dei Linked Data e in ambito World Wide Web”. E’ in corso un progetto di modellazione delle informazioni relative al settore pubblico. Il progetto mette a disposizione diverse ontologie e governa la standardizzazione di nuove ontologie.

Vai agli standard per il patrimonio informativo pubblico

Ontologie disponibili

Vocabolari controllati

Un vocabolario controllato è una lista ristretta di termini utilizzati per etichettare, indicizzare e categorizzare i contenuti di un ambiente. Se a un’area o a un intero ambiente è applicato un vocabolario controllato significa che:

  • solo i termini inclusi nella sua lista possono essere utilizzati in quello spazio;
  • se è utilizzato da più persone, si applicano regole precise su chi, quando e come può aggiungere nuovi termini alla lista;
  • la lista può crescere, ma solo sulla base di criteri ben precisi, stabiliti a priori.

Grazie a un vocabolario controllato è possibile eliminare la ridondanza e ridurre l’ambiguità del linguaggio. Per esempio: si può prevedere una lista di sinonimi che reindirizzi l’utente o il motore di ricerca da una variante inesatta del termine al termine preferito presente nel vocabolario controllato. Se l’utente cerca “ministero della pubblica istruzione” potrebbe venire reindirizzato a “Ministero dell’Istruzione, dell’Università e della Ricerca”.

Anche le tassonomie sono vocabolari controllati. Una tassonomia è un vocabolario controllato con una precisa struttura gerarchica: i termini della lista sono in relazione tra loro come genitore/figlio. La rappresentazione tipica della tassonomia è quella dell’albero con la radice in alto: i termini di una tassonomia sono definiti “nodi”. Seguendo la metafora dell’albero, un nodo senza successori è detto “foglia”: salendo dalle foglie verso l’alto si passa da una “classe” specifica a una più generale. La radice della tassonomia rappresenta la classe più generale in quella determinata classificazione.

Esiste un progetto della Pubblica Amministrazione per la creazione di vocabolari controllati da utilizzare nel settore pubblico.

Vai al repo GitHub per consultare i vocabolari disponibili o contribuire al progetto

SEO

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Premessa

Questa guida ha lo scopo di aiutare chi si occupa del sito web di una pubblica amministrazione a capire come ottimizzare i contenuti pubblicati e la struttura del sito nel suo complesso in ottica SEO, con l’obiettivo finale di rendere informazioni e servizi più idonei a soddisfare i bisogni degli utenti e più visibili sui motori di ricerca.

Introduzione

Con il termine search engine optimization (SEO) - o ottimizzazione per i motori di ricerca - si intende un insieme di tecniche iterative applicabili al contenuto delle pagine web e alla struttura dei siti che hanno lo scopo di migliorare il posizionamento di un contenuto web nel ranking dei risultati dei motori di ricerca.

I fattori di ottimizzazione vengono generalmente suddivisi in 2 categorie:

  • fattori on-page, cioè eseguibili all’interno del sito
  • fattori off-page, cioè eseguibili al di fuori del sito

I fattori on-page

Titolo del contenuto

Un titolo dovrebbe descrivere in modo semplice quanto esposto nella pagina, utilizzando di preferenza la terminologia più simile a quella che userebbero gli stessi utenti per descriverne il contenuto.

È consigliabile creare titoli univoci, il più possibile pertinenti rispetto al contenuto della pagina: un titolo dovrebbe essere composto da poche parole o una frase, evitando di superare i 60/70 caratteri (spazi inclusi).

Markup: Il metatag title deve essere posizionato all’interno del tag head nel codice HTML della pagina. Appare come prima linea testuale del risultato dei motori di ricerca:

  • aiuta gli utenti a comprendere con immediatezza se il risultato in questione sia pertinente al bisogno espresso durante la ricerca web;
  • e’ uno fra i principali elementi che i crawler dei motori analizzano per indicizzare un contenuto e assegnargli un rank nei risultati di ricerca.
Description del contenuto

È consigliabile la redazione di description univoche per ogni contenuto, che sintetizzino gli elementi salienti della pagina.

Markup: Il metatag description deve essere posizionato all’interno del tag head nel codice HTML della pagina. Appare come terza linea testuale (dopo la URL della pagina) del risultato dei motori di ricerca:

  • come il titolo aiuta gli utenti a comprendere con immediatezza se il risultato in questione sia pertinente al bisogno espresso durante la ricerca;
  • la description può essere di qualsiasi lunghezza, ma generalmente i motori di ricerca troncano testi più lunghi di 160 caratteri (spazi inclusi).
Le parole chiave

La scelta delle parole chiave più strategiche e salienti rispetto ai contenuti di un sito è uno fra i fattori che concorrono al buon posizionamento di un sito web fra i risultati dei motori di ricerca.

Il lavoro di identificazione delle keyword più idonee a rappresentare i contenuti di un servizio digitale è un lavoro iterativo che deve tenere conto di:

  • quali sono le parole che meglio potrebbero descrivere le informazioni presenti nel sito
  • quali sono i loro volumi di ricerca
  • in che maniera i concetti espressi nel sito potrebbero potenzialmente essere cercati dagli utenti sui motori di ricerca

Di seguito alcuni metodi per iniziare ad identificare un set di keywords salienti:

google suggest

Google suggest

google suggest

Google ricerche correlate

Originalità del contenuto

È sempre consigliabile redigere contenuti originali, possibilmente centrati sui bisogni dell’utente, con un linguaggio il più possibile chiaro.

Aggiornamento del contenuto

È necessario procedere regolarmente ad un aggiornamento dei contenuti pubblicati per evitare di fornire agli utenti informazioni obsolete. Gli algoritmi dei motori di ricerca considerano inoltre la data di aggiornamento di un contenuto web come fattore di rilevanza nel ranking dei risultati di ricerca.

Paragrafazione e paginazione

Per una maggiore leggibilità dei testi è consigliabile paragrafare i contenuti di una pagina, soprattutto se di lunghezza importante. È utile inoltre titolare gli eventuali sottoparagrafi secondo i medesimi principi applicabili al titolo principale della pagina.

Nel caso ci sia la necessità di suddividere il contenuto in più pagine, è consigliabile:

  • specificare quale sia la pagina principale di visualizzazione (visualizza tutto) attraverso l’attributo rel=»canonical»
  • utilizzare gli attributi HTML rel=»next» e rel=»prev», per specificare la relazione di consequenzialità fra URL

Ulteriori informazioni sulla paginazione

Grassetto

Può essere utile impiegare lo stile grassetto per evidenziare - senza esagerare - i termini salienti di un contenuto.

Immagini

È necessario nominare i file immagine in maniera pertinente al contenuto della pagina ove sono collocati.

Markup: Utilizzare il tag alt per fornire una descrizione testuale dell’immagine. Questo attributo è utile nel caso in cui questa non possa essere visualizzata nel browser per motivi legati ad esempio al mancato supporto di alcune tipologie di file da parte del browser o all’utilizzo di tecnologie assistive.

È possibile generare ed utilizzare una sitemap XML ad hoc per le immagini per fornire ai crawler maggiori informazioni rispetto all’organizzazione dei file immagini presenti nel sito.

Struttura logica dei contenuti

Una struttura dei contenuti semplice e “leggera” è necessaria per garantire una migliore esperienza utente sul sito e per agevolare il lavoro di scansione dei crawler dei motori di ricerca.

È consigliabile mantenere la struttura dei contenuti del sito gerarchica - dal generale al particolare - semplificandone il più possibile la struttura logica e utilizzando non più di tre livelli di profondità.

URL delle pagine

La URL di una pagina web appare come seconda linea testuale del risultato di ricerca (fra title e description). È buona regola semplificarne il più possibile la struttura:

  • impostare le URL in modo che contengano parole salienti e pertinenti rispetto ai contenuti della pagina che ospitano
  • utilizzare i trattini (-) invece che gli underscore (_) per la punteggiatura
  • cercare di ridurre il più possibile la lunghezza delle URL
  • valutare l’utilizzo del file robots.txt per bloccare la scansione da parte dei crawler dei motori di ricerca delle URL con parametri dinamici (referral, ordinamenti, calendari…)

Ulteriori informazioni sulla struttura delle URL

Duplicazione dei contenuti

È importante evitare la presenza di contenuti duplicati nel sito. Dal punto di vista SEO si intendono “contenuti duplicati” contenuti molto simili - o identici - nell’ambito dello stesso sito ma associati a URL differenti.

In alcuni casi la duplicazione di un contenuto è generata da situazioni particolari quali ad esempio:

  • la presenza di una pagina in versione web e versione per la stampa
  • la presenza di una tabella dinamica che genera viste dello stesso contenuto ma URL dinamiche diverse

In questi e altri casi è possibile inviare a Google l’informazione di quale sia la pagina “master”, o “canonica” da prendere in considerazione per l’indicizzazione. Questa tecnica è detta canonicalizzazione: per implementarla è necessario inserire un elemento link che contenga l’attributo rel=”canonical” (seguito dal link cui si vuole applicare la canonicalizzazione), nel tag head della pagina.

Approfondimenti sui contenuti duplicati

Approfondimenti sulla canonicalizzazione

Mappa del sito

Oltre ad una mappa del sito in HTML destinata agli utenti, è consigliabile creare un file sitemap XML destinato ai motori di ricerca.

Informazioni sulle sitemap

Una sitemap è un file che ha lo scopo di elencare le pagine web di un sito per comunicare a Google e altri motori di ricerca l’organizzazione dei contenuti. I crawler dei motori leggono questo file per eseguire una scansione più efficiente del sito. Una sitemap ha quindi l’obiettivo ultimo di migliorare la scansione di un sito da parte dei motori di ricerca.

All’interno di un file sitemap è possibile non soltanto elencare le URL di un sito web ma anche alcuni metadati più specifici rispetto all’organizzazione dei singoli nodi, ad esempio:

  • informazioni sull’aggiornamento della pagina
  • importanza della pagina rispetto ad altre URL dello stesso sito
  • informazioni relative a video e immagini
  • informazioni relative all’organizzazione dei documenti

Come generare e inviare una sitemap a Google

È possibile inviare una sitemap a Google anche tramite il tool Search Console È possibile inoltre generare sitemap XML per:

File robots.txt

Per ottimizzare i processi di scansione dei crawler dei motori di ricerca è possibile utilizzare il file robots.txt. Un file robots.txt è un file di testo memorizzato nella directory principale del sito che ha la finalità di indicare ai crawler dei motori di ricerca quali parti del sito non sono accessibili e quindi controllare il traffico di scansione.

Non si deve utilizzare il file robots.txt per nascondere le pagine web dai risultati di ricerca.

Informazioni sui file robots.txt

Come impedire la visualizzazione di una pagina del sito sui motori di ricerca

Tempi di caricamento delle pagine

La rapidità di caricamento di una pagina web è presa in considerazione dai crawler dei motori di ricerca come elemento che concorre ad un migliore posizionamento del contenuto nel ranking dei risultati di ricerca.

È consigliabile effettuare controlli periodici sulle velocità di caricamento delle pagine e i tempi di risposta del server, soprattutto da dispositivi mobili.

Risorse per lo sviluppo di pagine ottimizzate per i dispositivi mobili

Le pagine AMP per i contenuti di tipo “news”

Per determinate tipologie di contenuto - in particolare le news - è possibile implementare il formato AMP (Accelerated Mobile Pages) di Google. Il formato AMP è stato lanciato nel 2015 per migliorare le prestazioni del mobile web, riducendo la velocità di caricamento delle pagine.

Linee guida di Google Search per le pagine AMP

Il progetto AMP

Guida all’implementazione di pagine AMP

Dati strutturati

Il markup con dati strutturati è una tecnica che consente di personalizzare l’aspetto di un sito nella ricerca di Google o di altri motori di ricerca. Includendo dei dati strutturati all’interno dei contenuti è possibile inserire informazioni aggiuntive e/o strumenti di interazione con il sito nell’aspetto standard dei risultati di ricerca, ad esempio:

  • contatti e indirizzo dell’amministrazione
  • rating delle pagine
  • box di search in stile sitelink
  • breadcrumbs

Il markup con dati strutturati si basa sul vocabolario http://schema.org/

Guida di Google all’implementazione dei dati strutturati

Strumento per testare la corretta implementazione dei dati strutturati

Migrazione SEO di un sito

Quando si pianifica la migrazione di un sito è necessario fare in modo di non perdere la rilevanza acquisita sui motori di ricerca e di indirizzare gli utenti verso le nuove pagine nella maniera meno problematica possibile.

Si consiglia quindi di:

  • realizzare una mappatura di tutte le URL del sito, che includa anche il linking interno
  • associare alle vecchie URL le nuove URL, per poter in seguito preparare i redirect
  • per le URL alle quali non verrà associata alcuna nuova URL, preparare una pagina 404 personalizzata, che aiuti l’utente a proseguire la navigazione nel nuovo sito
  • configurare il server impostando dei redirect di tipo 301
  • modificare la sitemap XML del sito
  • laddove possibile, aggiornare i backlinks ricevuti dal sito
  • comunicare ai crawler di Google un eventuale cambiamento del dominio tramite la Search Console

Ulteriori informazioni sui redirect 301

I fattori off-page

Webmaster tools: Search Console di Google

Search Console è una risorsa online offerta gratuitamente da Google che consente di monitorare, gestire e ottimizzare la presenza di un sito o di un’applicazione mobile nei risultati di ricerca.

Search Console consente ad esempio di ottenere indicazioni sull’aspetto di un sito web nei risultati di ricerca Google o informazioni rispetto al traffico di ricerca; permette di verificare lo stato di indicizzazione delle pagine così come di monitorare e correggere problemi di varia natura legati al sito.

Con Search Console è possibile:

  • verificare lo stato di indicizzazione dei contenuti del sito
  • verificare lo stato della scansione dei crawler di Google sulle pagine del sito ed eventuali errori
  • testare i file robots.txt
  • testare la sitemap del sito, se presente
  • gestire i parametri URL durante la scansione dei crawler
  • rimuovere temporaneamente gli URL di un sito dai risultati di ricerca
  • informare Google rispetto al cambiamento di dominio di un sito
  • informare Google di un eventuale passaggio del sito da protocollo http a https
  • sapere per quali query è stato visualizzato il sito nei risultati di ricerca Google
  • conoscere i backlinks del sito e relativi anchor
  • monitorare i link interni
  • monitorare il corretto funzionamento del tag hreflang nel caso di siti multilingua
  • monitorare e correggere i problemi di usabilità del sito su dispositivi mobili
  • verificare la corretta implementazione di eventuali dati strutturati e schede informative (rich cards)
  • rilevare criticità nell’HTML per favorire e migliorare l’esperienza utente sul sito
  • rilevare e correggere eventuali criticità correlate alle pagine AMP (accelerated mobile pages)
  • monitorare e risolvere i problemi di malware o spam per tenere pulito il tuo sito
Utile da sapere

Una app Android deve essere pubblicata in Google Play per poter essere aggiunta a Search Console.

Come configurare una app in Search Console

Linguaggio

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Scrivere per le persone

Un linguaggio semplice è un ingrediente indispensabile per rendere i servizi della della Pubblica Amministrazione più efficaci e inclusivi

Ecco alcuni degli obiettivi da porsi quando si scrive per i cittadini:

  • scrivi documenti semplici e lineari, che tengano conto in primis dei bisogni del lettore
  • usa un linguaggio semplice e chiaro, seguendo le indicazioni della Guida al linguaggio della Pubblica Amministrazione su stile, tono di voce, uso delle parole
  • organizza contenuti e documenti in modo che siano facili da trovare durante la navigazione
  • presta particolare attenzione ai testi delle interfacce utente (definiti in gergo microcopy): la qualità e la pertinenza di label (etichette di navigazione), call to action (inviti all’azione) e altri testi che accompagnano e spiegano le interfacce grafiche, come ad esempio le tool tip o i testi che spiegano i contenuti da inserire all’interno di un form

Prima di creare un contenuto, devi avere ben chiaro:

  • chi sono gli utenti a cui ti rivolgi;
  • qual è lo scopo della loro visita, ovvero qual è il bisogno a cui il tuo contenuto deve rispondere.

Per individuare chi sono i tuoi utenti target (o categorie di utenti) e quali sono i loro bisogni, puoi utilizzare strumenti di user research, come ad esempio:

Puoi utilizzare le informazioni che raccogli per costruire delle personas (puoi usare il kit Personas per farlo), ovvero dei profili rappresentativi di categorie di utenti del tuo servizio, e ipotizzare delle user journey, cioè delle rappresentazioni sintetiche delle fasi che compongono l’interazione dell’utente con un servizio.

Definire chi sono gli utenti e quali sono i loro bisogni è necessario in tutte le fasi in cui lavori al contenuto, ovvero:

  • la progettazione/design;
  • la scrittura;
  • la gestione.

Contenuti efficaci dovrebbero essere immediatamente comprensibili e fruibili dagli utenti, a prescindere dall’età, le competenze e le abilità.

Utilizza strumenti, metodi di lavoro e modelli presenti nel kit di Designers Italia dedicato ai contenuti

Progettare i contenuti

La fase di progettazione dei contenuti contribuisce a modellare l’ambiente cognitivo nel quale gli utenti si muoveranno alla ricerca di informazioni.

Il linguaggio infatti:

  • dà forma all’ecosistema di informazioni dentro cui l’utente si muove (es. il nome delle voci del menu di navigazione e dei filtri di una sezione di ricerca);
  • guida l’utente che deve fare un’azione fornendogli le informazioni di cui ha bisogno (es. la scheda e/o guida introduttiva ad un servizio);
  • contribuisce, come parte dell’interfaccia utente, a dare forma al servizio (es. i testi che accompagnano l’utente che sta compilando un form on line);
  • è esso stesso un elemento chiave del servizio (es. Il documento “pagella” che viene letto da un genitore nel sito di una scuola).

Il punto di partenza per avviare il lavoro di progettazione dei contenuti può essere un workshop dedicato al linguaggio e ai contenuti (in cui coinvolgere stakeholder e utenti del servizio) e in particolare la realizzazione di una mappatura dei bisogni informativi dell’utente.

Le priorità sono le seguenti:

  • di cosa hanno bisogno le persone/gli utenti?
  • quali sono i contenuti e le informazioni, da mettere in rilievo?
  • che parole usano le persone per chiamare un servizio? che nome dare dunque ai contenuti e ai servizi?
  • che nome dare a contenuti e servizi?

Per dare risposta a questa domande devi entrare nel processo di prototipazione, dove il servizio prende forma (o viene ridefinito). La progettazione di un servizio beneficia della presenza di un design system di riferimento ovvero regole e componenti standard fanno sì che in fase di creazione di un nuovo servizio non sia necessario reinventare ogni volta la ruota.

Tra questi rientrano anche una serie di design pattern, ossia veri e propri modelli che offrono indicazioni su come strutturare e organizzare i contenuti (content type e content pattern).

deepening

Progettare i contenuti all’interno di un design system: content type e content pattern

In un sistema complesso come quello della Pubblica Amministrazione, è utile identificare dei modelli ricorrenti (che possiamo definire “pattern”) in grado di offrire risposte standard a classi di bisogni simili. I pattern relativi ai contenuti possono essere di due tipi:

  • stilistici e sintattici;
  • pagine web.

Per approfondire le regole stilistiche e sintattiche, puoi consultare la guida al linguaggio della Pubblica Amministrazione

Qui approfondiamo il tema della costruzione di pagine web che offrano una struttura standard per rispondere a specifici bisogni dell’utente. Solitamente si fa riferimento a queste tipologie di pagine come “content type”.

Questa “classificazione” permette di inquadrare meglio la funzione narrativa di ogni tipo di contenuto, per strutturarlo in modo tale da renderlo il più efficace possibile.

All’interno del design system di Designers Italia esiste un luogo in cui si sta progressivamente costruendo una libreria di content type: è il wireframe kit.

La diversa funzione che ha ogni content type è rilevante non solo per chi si occupa del design del sito, ma anche per chi si occupa di produrre contenuti.

Per esempio, è compito di chi scrive contenuti stabilire che in tutte le pagine di lista del sito potrebbe essere previsto un titolo, un sommario e un breve testo di introduzione, per spiegare in modo chiaro all’utente che tipo di informazioni, articoli o schede servizio sono elencate.

Alcuni esempi dei più comuni content type in un sito sono:

  • Search: la funzione principale di un motore di ricerca è permettere all’utente di trovare all’interno del sito o di una sezione le informazioni che sta cercando tramite parole chiave.
  • Scheda servizio: la funzione principale è descrivere all’utente un servizio, spiegandogli di cosa si tratta, chi ne ha diritto, come fruirne.
  • Liste: le pagine di lista permettono all’utente di orientarsi all’interno di alcune sezioni, organizzate per tag, per categoria, per argomento.
  • Homepage: l’homepage ha in genere la funzione principale di orientare l’utente all’interno dei contenuti del sito, per permettergli di raggiungere rapidamente le informazioni che sta cercando.
  • Form e wizard: questi content type accompagnano l’utente nell’esecuzione di un’azione, compilando alcuni campi o interagendo con elementi dell’interfaccia (etichette, bottoni).
  • Contenuti di servizio: queste pagine hanno la funzione di presentare informazioni (chi siamo, contatti, dicono di noi, ecc).
  • Carrello: permette all’utente di portare facilmente a termine un acquisto.
  • Articoli: in genere hanno la funzione di offrire all’utente un’informazione precisa, in modo chiaro e sintetico.
  • Area personale: la funzione tipica è quella di orientare l’utente tra alcune funzioni riservate, come le preferenze, la gestione delle notifiche, dei propri dati, ecc.

Anche nel modello di analisi dei contenuti che abbiamo pubblicato all’interno del Content kit, per ogni pagina presa in considerazione è necessario domandarsi di che tipo di content type si tratti. In questo modo è possibile assicurarsi:

  • che tutti i content type uguali siano trattati in maniera coerente all’interno del sito;
  • che le pagine rispondano effettivamente alla funzione narrativa che dovrebbero assolvere.

Scrivere e riscrivere

Le regole per un linguaggio semplice

Quando stai realizzando o revisionando dei contenuti di un sito o un servizio digitale, verifica che tutti gli elementi (testo, titoli, sommario, metadati, oggetti multimediali, interfacce) rispettino le indicazioni per un linguaggio semplice e efficace, che puoi trovare nella Guida al linguaggio della Pubblica Amministrazione.

Checklist per il contenuto: fai un check della qualità del contenuto basandoti sulle seguenti domande:

deepening

I testi come interfacce

LE ETICHETTE DI NAVIGAZIONE Una label (o etichetta) è un breve testo o un’icona che indica un insieme di contenuti con tratti in comune: attraverso le etichette l’utente si orienta nell’ambiente facendosi un’idea dell’organizzazione e del sistema di navigazione. Le label dovrebbero guidare gli utenti nei nuovi concetti e aiutarli a identificare quelli già familiari con facilità.

Le label sono un sistema che guadagna solidità dalla coerenza dei suoi elementi: per questo non si progettano singole label, ma sistemi di label. Nel progettare un labeling system è importante tenere conto:

Lavorare sulla coerenza del sistema richiede grande attenzione: alcuni elementi possono influenzarne la solidità. Di seguito trovi una checklist per verificare l’uniformità di alcuni elementi che – se incoerenti – possono rischiare di rendere ambiguo il labeling system.

  • Stile e ortografia: verifica, per esempio, l’uniformità delle varianti “CHI SIAMO”, “Chi siamo”, “Chi Siamo”.
  • Formattazione: dimensioni e colore dei caratteri, spaziature, sfondi possono rinforzare la coerenza di un labeling system.
  • Sintassi: evita di avere nello stesso sistema label a base verbale (“Scarica il documento”), nominale (“Documenti scaricabili”) e domande (“Devi scaricare il documento?”). Scegli un approccio sintattico e mantienilo.
  • Livello di granularità: all’interno del sistema è meglio avere label di pari livello di specificità. “Modulo per la richiesta di cambio di residenza” accanto ad “Anagrafe”, esposto nella stessa area del sito e allo stesso livello, genererebbe confusione.
  • Completezza: l’assenza evidente di una voce nel sistema di etichette potrebbe confondere l’utente. Per esempio: la mancanza della voce “Anagrafe” sul sito di un Comune potrebbe far pensare a un errore e di conseguenza l’incertezza per l’utente nel capire come muoversi nell’ambiente.
  • Utente di riferimento: tieni sempre presenti i bisogni emersi dalla ricerca sugli utenti, in modo che il sistema sia il meno ambiguo possibile.

La ricerca sugli utenti può fornire utili risposte per la progettazione del labeling system. I metodi diretti sono il card sorting e il free listing; quelli indiretti – che forniscono dati quantitativi più grezzi e da rielaborare – sono la ricerca interna ed esterna al sito, con strumenti come web analytics e Google Search Console.

IL MICROCOPY I microtesti che accompagnano e descrivono gli elementi grafici delle interfacce di un sistema web, sono definiti in gergo “microcopy”. L’armonia e la pertinenza fra elementi grafici delle interfacce e microcopy contribuisce a garantire all’utente un usabilità ottimale del sistema. Per questa ragione, è importante verificare periodicamente l’efficacia delle etichette di navigazione attraverso test di usabilità o mediante degli A/B test. Per esempio, un tema da gestire in modo corretto a livello di microcopy è quello dei messaggi di errore (o problematiche relative a un sistema). In questo ambito infatti, un buon uso dei testi consente all’utente di capire rapidamente la tipologia di errore, ridurre l’incertezza sull’affidabilità del sistema e in molti casi limitare la necessità di accesso ai canali di assistenza.

Revisione e miglioramento dei contenuti

La revisione dei tuoi contenuti va fatta tenendo conto dello scopo di ciascuna pagina e dei risultati che ci si aspetta, che possono essere misurati attraverso strumenti di ricerca come Google Analytics, da A/B test mirati, o anche attraverso attività di ricerca qualitativa (dei test di usabilità, per esempio).

I contenuti pubblicati su un sito devono essere pensati come un oggetto in continua evoluzione. Organizza un flusso di lavoro con il tuo team affinché tutti i contenuti del tuo sito siano:

  • realizzati con strumenti di scrittura e editing collaborativi;
  • periodicamente aggiornati e revisionati.

Queste due semplici accortezze possono aiutarti a fare in modo che:

  • lo scopo di ogni pagina del tuo sito sia chiaro e immediatamente comprensibile;
  • le informazioni siano efficaci e utili;
  • non ci siano pagine con informazioni obsolete, pagine vuote o incomplete.

All’interno del Content kit puoi trovare un modello di analisi dei contenuti pronto all’uso, per gestire l’attività di revisione di tutte le pagine del sito o di una specifica sezione, assegnando specifici task ai vari membri del tuo team. Utilizzando questo strumento, puoi individuare tutti i problemi di ogni pagina (dalla chiarezza delle informazioni all’efficacia dell’interfaccia, dai problemi di metadati a quelli di accessibilità), basandoti sulle indicazioni della Guida al linguaggio della Pubblica Amministrazione, per poi attivare un processo di riscrittura e miglioramento dei contenuti.

Se il tuo focus è fare in modo che il tuo servizio sia più facile da trovare attraverso i motori di ricerca (Google) nel kit dedicato alla SEO è disponibile un modello di analisi specifico (Vai al kit dedicato alla SEO).

deepening

Strumenti di editing collaborativo

Gli strumenti di editing collaborativo ti permettono di creare nuovi contenuti o di fare dei processi di revisione di contenuti già esistenti con altri membri del tuo team. In questo modo puoi avere più punti di vista sui contenuti, per verificare la chiarezza e l’efficacia delle informazioni e ottenere il miglior risultato possibile.

All’interno del Content kit puoi trovare un esercizio di editing collaborativo “Prima e dopo” che ti mostra in che modo utilizzare:

  • degli strumenti come InVision e Hypothes.is, che ti permettono di fare una revisione dei contenuti direttamente nel loro contesto d’uso, online (nel caso di contenuti già pubblicati) oppure in un prototipo (nel caso di nuovi contenuti). Questo approccio è particolarmente utile per analizzare e migliorare label, voci di menu e testi che accompagnanano le interfacce grafiche attraverso cui si fruisce un servizio
  • degli strumenti di scrittura collaborativa come Google Docs, che ti permettono di fare interventi condivisi sulle parti testuali del tuo contenuto.

Gestire i contenuti

Gestire i contenuti significa tenere aggiornati e migliorare i propri contenuti per:

  • rispondere in modo più efficace ai bisogni degli utenti;
  • evitare refusi, errori o incongruenze;
  • rispondere a nuovi bisogni informativi di cui non si era tenuto conto;
  • gestire i processi di pubblicazione ed evitare le duplicazioni.

In genere questa attività richiede:

  • la capacità di tenere un inventario di contenuti;
  • la capacità di organizzare un processo di produzione di nuovi contenuti o di revisione di contenuti esistenti.

Una corretta gestione dei contenuti è fondamentale anche per la gestione di attività «straordinarie», come la migrazione dei contenuti ad un nuovo sito web, o la traduzione di una parte dei contenuti del proprio sito.

L’inventario dei contenuti (content inventory)

Il primo passo consiste nella gestione ordinata dei contenuti (pagine, immagini, documenti o altro) spesso possibile attraverso il backend del proprio content management system (CMS) e la loro classificazione in content type e la loro organizzazione secondo un sistema di categorie o tag.

Ci sono situazioni particolari in cui può essere opportuno trasferire l’inventario dei contenuti (o una sua porzione) all’interno di uno spreadsheet (si può usare questo modello e modificarlo secondo necessità). Per esempio in vista di una ottimizzazione SEO o di un redesign del servizio, che potrebbe comportare la necessità di riclassificare i contenuti o introdurre nuovi criteri di classificazione. Un caso specifico è il processo di migrazione dei contenuti da un’infrastruttura tecnologica all’altra.

deepening

Gestire un processo di migrazione dei contenuti

La migrazione dei contenuti di un sito web è un’operazione che spesso prevede:

  • cambiamento della tecnologia
  • riclassificazione dei contenuti
  • cambio di dominio

Obiettivi:

  • gestire correttamente i contenuti esistenti e non perderli nel passaggio al nuovo sito;
  • evitare che gli utenti trovino online dei link non funzionanti;
  • mantenere tutti i contenuti ben indicizzati e quindi facilmente reperibili.

In vista di una migrazione, bisogna fare un inventario dei contenuti e lavorare alla riclassificazione delle singole pagine, se necessaria (content type e tag corrispondenti a ciascuna pagina). A volte la migrazione può richiedere la riscrittura di alcune pagine del sito (per esempio scrivere una descrizione prima non prevista) o la creazione dei contenuti di nuove pagine che non esistevano nel precedente sito. Questo processo può richiedere tempo, ma è funzionale alla migrazione automatica dei contenuti da un vecchio a un nuovo sito. Un altro aspetto di grande impatto è la gestione in ottica SEO

La gestione SEO di una migrazione

Le attività da fare per gestire una corretta migrazione riguardano la corretta gestione SEO, con strumenti come il modello per l’ottimizzazione SEO del SEO kit o la Search Console di Google.

Durante un processo di migrazione, oltre ai contenuti è necessario mappare tutti i link (puoi usare il modello per l’ottimizzazione SEO del SEO kit). Quando fai una migrazione, devi mappare anche i link delle foto, dei documenti o di altri oggetti multimediali, che potrebbero essere linkati o indicizzati autonomamente.

Prima della migrazione del tuo sito, utilizza la Search Console di Google per ottenere degli elenchi di:

  • tutte le pagine e gli oggetti multimediali che appaiono nei risultati di ricerca;
  • i backlink che puntano al tuo vecchio sito.

La mappatura di tutti i link del vecchio sito ti permette di creare dei redirect, dai vecchi url ai nuovi, facendo attenzione che:

  • il redirect di ogni contenuto rimandi allo stesso contenuto nel nuovo sito (e non ad esempio alla homepage);
  • se non ci sono contenuti corrispondenti, il redirect rimandi in ogni caso ad un contenuto analogo, che risponde allo stesso scopo informativo.

Ricorda di tenere online il vecchio dominio (e il vecchio server) per più tempo possibile, per garantire il corretto funzionamento dei redirect.

Una volta online il nuovo sito, monitora attentamente:

  • il traffico, attraverso strumenti di analytics, per vedere se ci sono criticità sulle quali intervenire (ad esempio un calo rilevante di traffico su un determinato contenuto);
  • l’indicizzazione con la Search Console di Google, per verificare se il sito ha perso traffico in relazione ad alcune parole chiavi strategiche o molto utilizzate nella precedente versione.

Per approfondire:

Checklist per il SEO

Modello per l’ottimizzazione SEO

Linee guida per i servizi digitali della Pubblica Amministrazione

Analizzare i contenuti

L’attività più frequente per la gestione dei contenuti è il monitoraggio e l’ottimizzazione dei contenuti già esistenti. All’interno del Content kit puoi trovare un modello di analisi di contenuti da cui puoi prendere spunto per gestire la tua attività di revisione e monitoraggio dei contenuti.

L’analisi serve a:

  • individuare pagine o contenuti da rimuovere;
  • individuare contenuti da aggiornare;
  • individuare contenuti assenti e che vanno realizzati;
  • individuare la posizione di contenuti che devono migrare altrove;

L’analisi può prendere in esame, in diversi momenti e secondo gli obiettivi specifici, le seguenti dimensioni:

  • tutte le pagine hanno uno scopo chiaro e definito?
  • le informazioni sono immediatamente comprensibili?
  • il linguaggio è semplice, chiaro, senza tecnicismi? Prova a leggere ad alta voce l’introduzione, per capire se il tuo testo è davvero efficace.
  • Il testo è adatto alla lettura su dispositivi mobile?
  • le informazioni sono organizzate bene all’interno della pagina?
  • le informazioni sono aggiornate?
  • i tag e i metadati sono trattati correttamente?
  • ci sono titolo e sommario? Al loro interno trovi le giuste parole chiave? Introducono bene il contenuto della pagina?
  • i documenti e le note sono trattati nel modo giusto?
  • ci sono refusi o errori grammaticali?
  • le etichette di navigazione nella pagina sono chiare? Riesci a capire dove ti porteranno?
  • ci sono acronimi o delle maiuscole “di troppo”, che rendono meno chiaro il testo?
  • sarebbe utile dividere le parti testuali in paragrafi o elenchi puntati?

In molti casi, il miglior modo di avviare l’analisi dei contenuti è fare dei test di usabilità con gli utenti di tipo “task based”, cioè concentrandosi sulla capacità dell’utente di raggiungere il risultato che si era prefisso. Questo tipo di analisi può far emergere problemi nella gestione delle informazioni. Per approfondire, vai alla sezione sui test di usabilità usability test.

Una seconda modalità di lavoro è quella degli A/B test, molto utile per avviare processi di miglioramento continuo delle interfacce utente (comprensive di label, microcopy e altri contenuti).

Come organizzare il lavoro

L’attività di gestione dei contenuti va definita in un flusso di lavoro che richiede una definizione delle attività e l’utilizzo di strumenti di project management . All’interno del kit sui contenuti è presente un esempio di gestione della produzione di contenuti utilizzando una board di Trello. All’interno del kit per la SEO è presente un esempio di board per gestire gli aspetti SEO di un progetto digitale. I processi di audit dei contenuti richiedono la capacità di identificare ruoli e scadenze e coordinare il processo in modo da garantire il raggiungimento dei risultati nei tempi stabiliti. Tutti questi strumenti favoriscono la collaborazione e lo scambio di opinioni tra i membri del team.

Per valutare i progressi nel processo di semplificazione dei contenuti è opportuno organizzare ogni anno dei test di usabilità.

Come pubblicare

Il più delle volte la gestione dei contenuti avviene tramite sistemi di pubblicazione basati su Content management system (CMS), come ad esempio Wordpress o Drupal. Ma è possibile utilizzare altre modalità di pubblicazione e gestione dei contenuti. Ad esempio, la piattaforma dove sono ospitate queste linee guida utilizza GitHub come content management system e benefica del suo version control system.

È bene conoscere in modo approfondito gli strumenti di gestione dei contenuti, in modo da governare i processi di aggiornamento, classificazione e riclassificazione dei contenuti, e seguire le regole per una buona indicizzazione dei contenuti sui motori di ricerca.

deepening

Molti CMS hanno delle funzioni in comune, il cui utilizzo va definito in fase di design (o redesign) del sito, per creare un sistema coerente e funzionale. Ad esempio:

  • Gli articoli: sono generalmente utilizzati per produrre news o blog post, precisando la data di pubblicazione e in alcuni casi l’autore. Essendo spesso organizzati attraverso delle categorie, possono essere adatti anche per la pubblicazione e la gestione di schede servizio. Anche quando il CMS non lo prevede, è bene prevedere un sommario oltre al titolo, che spieghi il contenuto della pagina, mentre è sempre necessario curare i metadati per l’indicizzazione;
  • Le pagine: strumenti più versatili, possono contenere informazioni testuali, gallery, liste, wizard e form, e quindi sono adatte a qualsiasi tipo di content type. Per ogni pagina valuta con attenzione il titolo, che deve essere pertinente, indicizzato e può divenire un bottone di navigazione. In base all’utilizzo delle pagine per i content type, definisci quando prevedere anche un sommario e/o un testo introduttivo, per indicare all’utente che contenuti trova nella pagina.
  • I tag e le categorie: sono due “modi” per catalogare e correlare i contenuti all’interno dei CMS. È opportuno pianificare in un file condiviso quali tag e quali categorie utilizzare, in base alle scelte di correlazione dei contenuti all’interno del sito. Pianifica in che modo le categorie e i tag saranno utilizzati dagli utenti durante la navigazione (potrai mostrare contenuti correlati, oppure creare dei menu partendo dalle categorie, ecc.).
  • I menu: quando crei un menu con un CMS, ricorda che tutte le voci sono di fatto delle etichette di navigazione che vanno trattate coerentemente alla strategia adottata per il labeling system.
  • I widget sono oggetti molto versatili, da utilizzare all’interno delle pagine o di altre parti del sito (footer, sidebar) per inserire elementi come contenuti multimediali, widget, form, ecc. Anche nel gestire i widget ricorda di rispettare la corretta gestione delle etichette di navigazione, del microcopy, dei metadati, dei tag e delle categorie.
Gestire un sito multilingua

Localizzare il proprio sito o servizio digitale può essere molto importante per renderlo più efficace per tutti gli utenti, anche quelli che non conoscono o non hanno dimestichezza con la lingua e la cultura italiane, attraverso contenuti:

  • accessibili e inclusivi;
  • facili da trovare;
  • chiari e comprensibili.

Questo passaggio può essere particolarmente importante per i servizi pubblici, che si rivolgono spesso anche a cittadini di altre nazionalità o a cittadini italiani ma che hanno diversi riferimenti linguistici o culturali.

Se ritieni utile realizzare una traduzione del tuo sito, la prima scelta da fare è se:

  • tradurre l’intero sito (o l’intera applicazione);
  • tradurne solo una parte, dove l’utilizzo di altre lingue è particolarmente rilevante (es. la sezione “visti” del sito del Ministero degli esteri; la sezione dedicata alle emergenze del sito di un ospedale; ecc).

La scelta va fatta in considerazione:

  • di una ricerca sugli utenti del sito o del servizio, che ne indaghi la lingua e i riferimenti culturali attraverso strumenti quantitativi (web analytics) e qualitativi (user interviews, ad esempio);
  • degli obiettivi che si vogliono perseguire con i propri contenuti (inclusione; efficienza del servizio; accessibilità; ecc).
Tradurre i contenuti

Per la creazione e la gestione di una versione multilingua di un sito è necessario organizzare un flusso di lavoro che preveda:

  • la mappatura di tutti i contenuti;
  • la scelta dei contenuti da tradurre, in base agli utenti e agli obiettivi da raggiungere;
  • l’organizzazione all’interno del team del lavoro di traduzione e localizzazione dei contenuti;
  • il test dell’efficacia dei contenuti tradotti (tramite A/B test, usability test).

Se traduci solo alcune parti del tuo sito:

  • mostra in modo evidente l’interfaccia per scegliere la lingua alternativa;
  • assicurati di tradurre anche il contesto, aggiungendo dei chiarimenti quando necessario, per non lasciare le informazioni isolate o dare per scontate altre informazioni che non sono tradotte.

“Tradurre” i contenuti di un sito o di una sezione di un sito non significa limitarsi a cambiare il testo dall’italiano alla lingua di destinazione, ma anche “localizzare” i contenuti, rendendoli comprensibili ed efficaci anche da chi parla un’altra lingua o ha una diversa cultura. Ad esempio:

  • alcuni concetti o nomi possono non essere immediatamente comprensibili per un turista o un cittadino di altra nazionalità e vanno spiegati, oltre che tradotti (es. “il medico di base”; “gli esami di stato”; “l’Inps”, “l’Agenzia delle entrate”, ecc);
  • alcune espressioni possono avere un significato diverso se semplicemente tradotte in un’altra lingua (ad esempio, “timbra il biglietto” si potrebbe tradurre con “validate your ticket by stamping it at the machines” invece che con un semplice “stamp your ticket”);
  • può essere necessario adattare alcuni contenuti in base alla cultura di chi legge (i concetti di “famiglia” e “congiunti”, ad esempio, potrebbero avere significati diversi e quindi in alcuni casi andare chiariti in base ai riferimenti culturali degli utenti a cui ci si rivolge).

Se hai un sito multilingue, ricordati che quando aggiorni o cambi i contenuti dovrai farlo contemporaneamente su più lingue, mantenendo aggiornata la versione italiana con le altre lingue.

Proprietà intellettuale: testi, immagini, dati. Le liberatorie e i tipi di licenze

Tutti i contenuti pubblicati dalla Pubblica Amministrazione sono rilasciati per legge con una licenza open source, che ne permette l’utilizzo da parte di chiunque, anche per finalità commerciali.

Esistono molti tipi di licenze aperte che possono essere utilizzati per i contenuti della Pubblica Amministrazione. Per rendere più semplice l’utilizzo dei dati pubblicati da parte delle altre Pubbliche Amministrazioni e degli utenti, suggeriamo di indicare esplicitamente l’utilizzo della licenza Creative Commons Attribution 4.0 (codice SPDX: CC-BY-4.0).

Questa licenza riconosce la libertà di:

  • condividere, ovvero riprodurre, distribuire, comunicare al pubblico, esporre in pubblico, rappresentare, eseguire e recitare questo materiale con qualsiasi mezzo e formato;
  • modificare, ovvero fondere, trasformare il materiale e basarsi su di esso per le proprie opere per qualsiasi fine, anche commerciale.

Queste libertà sono subordinate al rispetto delle seguenti condizioni:

  • attribuzione, ovvero dovere di riconoscere e menzionare la paternità dell’opera, di, fornire un link alla licenza e di indicare se ha subito delle modifiche;

Come seconda scelta, è anche utilizzabile la licenza Creative Commons Attribution-ShareAlike 4.0 (codice SPDX: CC-BY-SA-4.0), che introduce alla licenza precedente la cosiddetta clausola “share alike”:

  • divieto di restrizioni aggiuntive, ovvero divieto di applicare termini legali o misure tecnologiche che impongano ad altri soggetti, ulteriori licenziatari dei medesimi dati o contenuti, dei vincoli giuridici su quanto la licenza consente loro di fare.

Quando i contenuti sono pubblicati all’interno di un sito web pubblico, le licenze di utilizzo possono essere indicate scrivendo nel footer:

“Tutti i contenuti presenti su questo sito web, salvo diversa specifica, si intendono rilasciati con licenza Creative Commons Attribution 4.0. I testi degli atti ufficiali sono, invece, in pubblico dominio (Creative Commons Zero).”

Nel caso della pubblicazione di documenti, si può fare una distinzione:

  • Gli atti ufficiali della Pubblica Amministrazione non possono essere coperti da diritto d’autore. Per questi contenuti utilizza una dichiarazione esplicita di rilascio in pubblico dominio, applicando la dichiarazione presente nella licenza Creative Commons Zero, ovvero di chiarire che su di essi non insistono diritti d’autore di nessuno. In questo caso puoi scrivere:

    “Il presente contenuto è reso disponibile in pubblico dominio (licenza Creative Commons Zero).”

  • Per tutti gli altri documenti è possibile adottare la licenza di Creative Commons Attiribution. In questo caso puoi scrivere:

    “Il presente contenuto è reso disponibile al pubblico nei termini di cui alla licenza Creative Commons Attribution 4.0. Il relativo contratto di licenza si intende concluso a seguito del semplice utilizzo del contenuto.”

  • Sebbene sia sempre preferibile l’adozione di Creative Commons Attiribution, per motivate e comprovate ragioni in alcuni casi è possibile utilizzare altri tipi di licenze aperte. In questi casi si può precisare in calce l’indicazione:

    “Il presente contenuto è reso disponibile al pubblico nei termini di cui alla Licenza XXXX disponibile al seguente link: INSERIRE link al contenuto esteso della licenza. Il relativo contratto di licenza si intende concluso a seguito del semplice utilizzo del contenuto.”

Nota che le uniche licenze Creative Commons di tipo aperto sono la Creative Commons Zero, Creative Commons Attiribution e Creative Commons Attiribution-ShareAlike.

Pubblicazione di contenuti non prodotti dalla Pubblica Amministrazione

Quando pubblichi qualsiasi tipo di contenuto su un sito, un canale social, una newsletter, devi accertarti di averne il diritto. Per questo considera che:

  • Tutte le immagini, i video e i file audio, salvo diversa indicazione, sono coperti da copyright, ovvero da diritto d’autore sulle immagini (inclusi i contenuti su canali come Youtube, Facebook, Twitter, Instagram etc.). Se intendi utilizzare contenuti protetti da copyright e rilasciati con una licenza non aperta devi richiedere l’autorizzazione al proprietario e conoscere i termini d’uso concessi. In questo caso l’attribuzione del copyright sotto il contenuto pubblicato dipende dal tipo di licenza acquisita.
  • Alcuni contenuti sono pubblicati online con licenza Creative Commons (CC), un modo standardizzato per definire a quali diritti l’autore rinuncia e quali si riserva. I contenuti con licenza CC possono essere utilizzati liberamente a seconda del tipo di licenza espressa (utilizzo commerciale o non commerciale, possibilità di modifica del contenuto, ecc.), purché ci sia l’attribuzione al proprietario dei diritti.

Scrivi ad esempio: [Contenuto] di [nome autore], pubblicato sotto licenza [indicare licenza Creative Commons]

Per approfondire: Qual è il modo giusto di attribuire un’opera rilasciata con Creative Commons?

deepening

Archivi di contenuti multimediali online

Per quanto riguarda i contenuti multimediali, ovvero le immagini, i video, e gli audio, è possibile utilizzare archivi online con licenze di utilizzo aperte:

  • Per le immagini alcuni archivi non richiedono alcuna attribuzione (es. Unsplash e le relative informazioni sul tipo di licenza offerta). Tra le fonti di immagini con licenze aperte, segnaliamo Google Images, Flickr e Getty Images in cui usando la ricerca avanzata è possibile filtrare le ricerche in base alla licenza. CC search, infine, è un motore di ricerca di immagini, con la possibilità di cercare solo contenuti Creative Commons.
  • Sebbene sia meno frequente farne uso, esistono anche degli archivi di video con licenze di utilizzo aperte. Su YouTube si possono trovare video Creative Commons utilizzando i filtri del motore di ricerca.
  • Esistono diversi archivi di audio e musica utilizzabili con licenze Creative Commons (es. Free Music Archive, Jamendo, NoiseTrade). Applicando i filtri Creative Commons, è possibile trovare una vasta scelta di brani anche su SoundCloud.
Consenso dei soggetti ritratti

Un altro tema da tenere in considerazione quando si pubblicano immagini o video all’interno di un sito o di un canale social è il diritto a pubblicare immagini che raffigurano dei soggetti riconoscibili. Queste immagini sono considerate dati personali e quindi regolate dalla normativa sulla privacy, che prevede che i soggetti pubblici ne possano fare uso soltanto per lo svolgimento delle proprie funzioni istituzionali.

  • In caso di fotografie provenienti da archivi online, verifica attentamente cosa prevede la licenza di utilizzo. Nel caso della licenza Creative Commons Attribution 4.0, ad esempio, l’utilizzo delle immagini è vincolato al rispetto del diritto della riservatezza, dei diritti di immagine, dei diritti morali dei soggetti raffigurati.
  • Nel caso di fotografie o video realizzati autonomamente, uno specifico consenso scritto è necessario nella maggior parte dei casi. La legge sul diritto d’autore prevede espressamente alcune eccezioni sul consenso, come le persone ritratte in eventi di pubblico interesse (una conferenza stampa, una manifestazione in piazza, un concerto), le persone famose (in base al pubblico interesse, come esponenti delle istituzioni, attori, personaggi pubblici), purché in contesti pubblici. Altre eccezioni riguardano “scopi di polizia, di giustizia, didattici o scientifici”.

In tutti gli altri casi la pubblicazione di fotografie o video in un sito deve essere sempre autorizzata dai soggetti ritratti con una lettera liberatoria (qui trovi un modello pronto per l’utilizzo) in cui puoi specificare la destinazione del contenuto.

I documenti

Scrivere e pubblicare i documenti amministrativi e tecnici della Pubblica Amministrazione

La dematerializzazione dei documenti, ovvero l’uso di documenti elettronici al posto di quelli cartacei, è un punto cardine della trasformazione digitale della Pubblica Amministrazione. I documenti elettronici sono destinati a diventare il principale mezzo per veicolare informazioni, sia all’interno della PA che verso i cittadini.

I contenuti - e quindi anche i documenti - sono una delle componenti che concorrono a definire la qualità dell’esperienza di fruizione dei servizi digitali da parte del cittadino. Per questo motivo devono essere prodotti secondo criteri di semplicità, devono essere facili da trovare e da leggere e usare un linguaggio comprensibile per il cittadino. La qualità e la semplicità dei contenuti deve essere periodicamente verificata con attività di user research come A/B test e test di usabilità da parte degli utenti - cittadini, imprese e dipendenti della Pubblica Amministrazione.

I documenti vanno sul web

Principi come la trasparenza e l’open government fanno sì che qualsiasi testo, documento o legge della Pubblica Amministrazione sia considerato pubblico e di potenziale interesse per i cittadini.

Per questo motivo quasi tutti i contenuti della Pubblica Amministrazione già oggi vengono pubblicati sul web. Questo, però, non basta per informare i cittadini, per realizzare il concetto di trasparenza o per mettere in pratica una filosofia di open government: i contenuti ci sono ma sono troppo complessi, disorganizzati e difficili da trovare. Gran parte dei contenuti e dei documenti vengono scritti come se fossero a uso interno, senza impegno verso la semplificazione, l’accessibilità, l’inclusione.

La Pubblica Amministrazione deve iniziare a scrivere in modo semplice tutti i tipi di contenuto (compresi atti, norme, circolari), utilizzando come buone pratiche le regole di scrittura tipiche del web: questo, infatti, è il luogo dove i documenti verranno letti.

I contenuti di un buon documento dovrebbero essere:

  • utili;
  • comprensibili;
  • ben organizzati;
  • leggibili;
  • accessibili.

Per approfondire: Guida al linguaggio della Pubblica Amministrazione

Tipi di documenti

Le pubbliche amministrazioni scrivono quotidianamente vari tipi di documenti, con scopi e destinatari diversi. La struttura e il modo in cui vengono presentate le informazioni determinano l’efficacia o meno del contenuto.

Per alcuni tipi di documento, è possibile individuare degli schemi fissi che è possibile sfruttare per creare nuovi testi. Il Content kit di Designers Italia individua alcuni modelli che sono spesso usati dalla Pubblica Amministrazione:

Tipo di documento Scopo Caratteristiche
Documenti di progetto Descrive il piano di sviluppo di un progetto. Serve a pianificare operazioni e risorse e a stabilire gli obiettivi.
  • descrizione del progetto
  • benefici
  • roadmap di sviluppo
  • risorse necessarie
Documenti tecnici e specifiche Descrive le caratteristiche tecniche di un prodotto o servizio per un pubblico di tecnici.
  • molti dettagli tecnici
  • linguaggio semplice
Documenti amministrativi Offre alcuni consigli su come strutturare i contenuti di linee guida, circolari e altri documenti amministrativi.
  • generalità degli argomenti
  • attenzione a titolo, sommario e riferimenti normativi
Email e newsletter per i cittadini Aggiorna e coinvolge gli utenti sulle novità e le iniziative che si vogliono comunicare.
  • scopo ben preciso di ogni invio
  • contenuto chiaro e sintetico

Usa i suggerimenti e la struttura dei contenuti presenti in questi modelli per semplificare la scrittura di nuovi documenti.

Formato di lettura dei documenti elettronici

Prima di pubblicare un documento, le amministrazioni dovrebbero fare una riflessione sulla funzione che svolge e sulle esigenze degli utenti:

  • Il documento verrà letto direttamente online?
  • Deve poter essere scaricato?
  • Deve poter essere modificato dagli utenti oppure no?

Partendo dall’idea che i documenti della Pubblica Amministrazione verranno letti online e, sempre più spesso, anche attraverso dispositivi mobili, il modo più naturale per rappresentarli è la forma di una pagina web. L’uso del formato Html presenta diversi vantaggi per l’utente, tra cui la possibilità di avere una pagina responsive (quindi leggibile anche sugli smartphone), consentire una buona indicizzazione del contenuto e dare la possibilità di condividere un punto specifico del documento tramite link interni.

Siccome le persone possono avere la necessità di salvare sul proprio dispositivo il contenuto e poi eventualmente stamparlo, è opportuno creare la funzione “Salva/stampa come Pdf” che consentirà di salvare documenti o form costruiti online.

L’idea di base è che tutta l’esperienza dell’utente avviene sul web, e la conversione in Pdf viene utilizzata solamente per una funzione specifica, che è quella di conservare sul proprio dispositivo il documento e stamparlo, se necessario.

In poche occasioni, l’amministrazione potrebbe avere la necessità di mettere a disposizione dell’utente dei documenti in formato aperto. In questo caso, per i formati di tipo documentale suggeriamo di condividere i documenti in formato Odt, mentre per i fogli di calcolo suggeriamo di utilizzare il formato Ods.

Quando per qualche motivo non è possibile mostrare il contenuto del documento in Html ma solo in formato Pdf (o in un altro formato di tipo documentale, come un Odt), è bene in ogni caso creare una pagina web che riporti almeno il titolo e la descrizione del documento Pdf che si intende pubblicare per favorire l’indicizzazione dei contenuti sul web.

Importante

La soluzione più adatta è mostrare il contenuto in formato Html. Se ciò non è possibile, si possono usare altri formati, ma si deve sempre creare una pagina web corrispondente al documento che riporti titolo e descrizione del contenuto.

deepening

Maggiori informazioni sui principali formati documentali.

Modalità di produzione dei documenti

Le pubbliche amministrazioni hanno l’obbligo di conservare i documenti elettronici che producono o che ricevono, attraverso risorse interne o avvalendosi di soggetti esterni accreditati. Il processo di conservazione serve a garantire “autenticità, integrità, affidabilità, leggibilità, reperibilità” del documento stesso. Ma l’obiettivo principale di un documento è e resta quello di rispondere in modo semplice ai bisogni degli utenti per i quali è stato scritto, rispondendo a criteri di efficacia e inclusione. Dato che tutti i documenti della PA vengono pubblicati sul web, anche la modalità di creazione dei contenuti deve tener conto di questo fatto. Come abbiamo visto in precedenza, esistono essenzialmente due strade.

Creazione di un contenuto in formato Html in modo nativo

Con questo approccio, è possibile per esempio:

  • creare una form online per raccogliere i dati altrimenti richiesti attraverso un documento Odt;
  • creare una circolare online e poi dare all’utente la possibilità di convertirla in Pdf.

Questa strada è quella consigliata a tutti i livelli. Di seguito trovi l’approccio seguito dal progetto Docs Italia che, in modo coerente rispetto a questa impostazione, rappresenta una piattaforma a disposizione di tutte le amministrazioni per creare documenti e gestire i processi di consultazione come previsto dal CAD, art. 18.

deepening

La piattaforma di Docs Italia è a disposizione per le pubbliche amministrazioni che intendono pubblicare documenti tecnici e amministrativi sul web, in un formato Html responsive adatto per essere visualizzato su qualsiasi dispositivo.

Il documento viene presentato in maniera nativa come pagina Html, ma in ogni momento è possibile scaricare una versione Pdf o ePub. Il contenuto, infatti, viene scritto su file di testo che vengono compilati e trasformati in pagina web, proprio come avviene con molti sistemi di gestione dei contenuti.

È un progetto che si basa sull’approccio alla creazione della documentazione chiamato docs as code, ovvero “documenti come codice”.

Per approfondire: L’approccio docs as code di Gov.uk (in inglese)

Tutto il codice sorgente dei documenti di Docs Italia è ospitato su repository pubblici di GitHub, ai quali chiunque può contribuire con suggerimenti e modifiche. L’uso di un sistema di controllo delle versioni consente, inoltre, di memorizzare tutte le precedenti versioni di un documento e di ripristinarle in qualsiasi momento, se necessario.

Per approfondire: Breve descrizione di Docs Italia e Guida alla pubblicazione.

Pubblicare sul web documenti di vario formato (Pdf, Odt e Ods)

In questo caso, è necessario accompagnare sempre i documenti con una pagina web che li descriva, con un titolo e una descrizione breve, in modo da favorire la fruibilità e l’indicizzazione del contenuto.

Di seguito trovi un approfondimento sulle buone pratiche per la gestione dei Pdf.

deepening

Oltre che essere accompagnati da una pagina Html di descrizione, i file dei documenti di testo allegati dovrebbero essere creati rispettando alcune buone pratiche.

Rendi il documento accessibile

  • Il documento Pdf deve essere creato digitalmente, non deve essere una scansione di un documento cartaceo.
  • Quando scrivi il documento in un editor di testo, usa le opzioni di titolo, sottotitolo e corpo del testo per creare una gerarchia delle informazioni.
  • Inserisci all’inizio del documento un indice navigabile per permettere a chi legge di raggiungere facilmente le varie sezioni.
  • Usa le opzioni di elenco puntato e numerato, invece di indicare gli elenchi con un trattino o un numero.
  • Accompagna ogni immagine con un testo alternativo (alt text).
  • Verifica l’accessibilità del documento Pdf prima di pubblicarlo.
  • Mantieni ridotte le dimensioni del file, dividendo, se necessario, i file troppo grossi in capitoli.

Inserisci i metadati

I metadati sono informazioni aggiuntive che vengono associate al documento automaticamente in fase di creazione, oppure manualmente. Aggiungi dei metadati al documento Pdf per aiutare gli utenti a trovare più facilmente il documento.

I principali metadati che possono essere associati a un documento sono:

  • titolo;
  • autore;
  • descrizione;
  • parole chiave.

Naturalmente, più sono specifiche e dettagliate le informazioni che fornisci, più il documento risulterà rilevante nelle ricerche degli utenti.

User research

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

La User Research (Ricerca sull’Utente) pone le basi fondanti per la progettazione di un servizio web che si focalizzi sull’utente Cittadino e i suoi bisogni. Il primo capitolo della guida è dedicato all’usabilità, la cui importanza e centralità nel design di un servizio web sta nel suo essere in grado di influenzare in maniera determinante l’effettiva resa del servizio. A seguire il capitolo dedicato alla ricerche qualitative fa una rassegna delle tecniche e degli strumenti che, in diversi step della progettazione, risultano utili per un focus qualitativo sulle motivazioni sottese ai bisogni dell’utente. Chiude la sezione il capitolo sulla web analytics, attività che - grazie all’analisi puntuale dei dati di performance di un ambiente web - permette di comprendere se e come un servizio digitale risponde in maniera adeguata ai bisogni degli utenti e ne coadiuva l’avvio di azioni migliorative.

Usabilità

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Definizione

Per usabilità si intende «il grado in cui un prodotto può essere usato da particolari utenti per raggiungere certi obiettivi con efficacia, efficienza, soddisfazione in uno specifico contesto d’uso» (ISO 9241-210:2010). L’usabilità focalizza la dimensione funzionale dell’interazione tra un sistema (ad es. un sito web) e l’utente, in relazione a precisi obiettivi e contesti d’uso. Non una caratteristica del sistema, ma una proprietà risultante (dall’interazione tra sistema e persona). In questo senso è fondamentale utilizzare un approccio human/user centered per cui la progettazione, del sistema sia guidata dall’analisi e dalla conoscenza articolata dei bisogni, delle caratteristiche degli utilizzatori e dei contesti d’uso. Nella progettazione è necessario pensare a chi utilizzerà realmente il servizio, e il modello di riferimento del progettista deve coincidere con quello dell’effettivo utilizzatore.

User-centered design

Lo user centered design è un insieme di tecniche usate per far emergere i bisogni effettivi delle persone per cui si sta progettando un contenuto, coinvolgendo le persone stesse nel processo di progettazione. Per «persone» si intendono tutti i portatori di interesse (stakeholder) del progetto. Nel caso della pubblica amministrazione:

  • Cittadini
  • Aziende
  • Dipendenti di altre amministrazioni o istituzioni
  • Committenti

I vantaggi dell’usabilità

L’aderenza in fase progettuale e implementativa ai criteri di usabilità consente al cittadino di:

  • esercitare i propri diritti
  • ridurre gli errori e aumentare la soddisfazione di fruizione

Inoltre l’usabilità consente alle PA di:

  • evitare la produzione di servizi inadeguati
  • incentivare i cittadini a ritornare sul sito
  • aumentare la fiducia dei cittadini nei confronti dell’amministrazione

SI DOVREBBE

Data l’importanza che l’usabilità riveste nell’interazione tra utente e applicazione web, è necessario riservare la massima attenzione alla progettazione orientata all’usabilità e alla relativa misurazione, mediante un processo di inclusione degli utenti sin dalla fase di progettazione dei servizi, secondo un modello centrato sulla persona (human-centered).

Criteri di valutazione

Per garantire la fruibilità delle informazioni e contribuire a migliorare l’usabilità dei siti e delle applicazioni, le pubbliche amministrazioni sono tenute a rispettare i criteri qui elencati:

Percezione
Le informazioni e i comandi necessari per l’esecuzione delle attività devono essere sempre disponibili e percettibili.
Comprensibilità
Le informazioni e i comandi necessari per l’esecuzione delle attività devono essere facili da capire e da usare.
Operabilità
Le informazioni e i comandi devono consentire una scelta immediata delle azioni necessarie al raggiungimento dell’obiettivo.
Coerenza
I simboli, i messaggi e le azioni devono avere lo stesso significato in tutto il sito.
Tutela della salute
Il sito deve possedere caratteristiche idonee a salvaguardare il benessere psicofisico dell’utente.
Sicurezza
Il sito deve possedere caratteristiche idonee a fornire transazioni e dati affidabili, gestiti con adeguati livelli di sicurezza.
Trasparenza
Il sito deve comunicare all’utente lo stato, gli effetti delle azioni compiute e le informazioni necessarie per la corretta valutazione delle modifiche effettuate sul sito stesso.
Facilità di apprendimento
Il sito deve possedere caratteristiche di utilizzo di facile e rapido apprendimento.
Aiuto e documentazione
Le funzionalità di aiuto, quali le guide in linea e la documentazione sul funzionamento del sito devono essere di facile reperimento e collegate alle azioni svolte dall’utente.
Tolleranza agli errori
Il sito deve essere configurato in modo da prevenire gli errori; ove questi, comunque, si manifestino, occorre segnalarli chiaramente e indicare le azioni necessarie per porvi rimedio.
Gradevolezza
Il sito deve possedere caratteristiche idonee a favorire e a mantenere l’interesse dell’utente.
Flessibilità
Il sito deve tener conto delle preferenze individuali e dei contesti.

Usabilità come costrutto misurabile

Efficacia, efficienza e soddisfazione dell’utente sono proprietà misurabili e osservabili attraverso questionari, interviste e scale di misurazione, una volta stabilite le tipologie di utenti e gli obiettivi che essi devono raggiungere. Gli standard definiscono come segue i fattori misurabili:

  • l’efficacia: è il grado in cui una persona riesce a completare le operazioni richieste per raggiungere il proprio obiettivo in modo corretto e completo
  • l’efficienza: corrisponde alla quantità di risorse che la persona spende nelle operazioni richieste per raggiungere un dato obiettivo
  • la soddisfazione soggettiva: è la dimensione più complessa da valutare e da raggiungere, poiché riguarda il livello di gratificazione che l’esperienza d’uso offre. Un sistema può funzionare molto bene ma può non bastare a rendere l’interazione confortevole e piacevole. Rientrano in questa dimensione aspetti come l’estetica, la qualità relazionale

La misurazione del livello di usabilità dei siti web dovrebbe essere effettuata a partire dalla fase di prototipazione dell’interfaccia grafica.

Le statistiche d’uso di siti già online forniscono indicazioni utili, seppur parziali, sull’efficacia dei contenuti. È essenziale anche consentire agli utenti di poter inviare facilmente, e in via informale, commenti e opinioni sul sito dell’amministrazione.

Protocollo eGLU LG per la realizzazione di test di usabilità

Quest’opera è distribuita con licenza Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).

Realizzato dal gruppo di lavoro per la revisione del protocollo eGLU del Gruppo di Lavoro per l’Usabilità (GLU).

Coordinatori del gruppo di lavoro: Simone Borsci, Maurizio Boscarol.

Gruppo di lavoro: Stefano Federici, Jacopo Deyla, Domenico Polimeno, Josè Compagnone, Marco Ranaldo, Maria Laura Mele.

A cura di: Alessandra Cornero.

Il Gruppo di Lavoro per l’Usabilità (GLU) è coordinato da: Emilio Simonetti.

Introduzione alla procedura

Il Protocollo eGLU LG, versione 2018.1, è uno strumento pensato per coloro che lavorano nella gestione dei siti istituzionali e tematici di tutte le pubbliche amministrazioni e che può essere utilmente adottato anche da chi, nelle PA; realizza servizi online, siti web, software.

Questo protocollo ha due obiettivi:

  • descrivere una procedura per incoraggiare il coinvolgimento diretto e l’osservazione di utenti nella valutazione dei siti e dei servizi online. In tal modo si potranno raccogliere evidenze sulle criticità, senza necessariamente far ricorso a risorse esterne. Tali evidenze potranno dar luogo a modifiche immediate delle criticità più evidenti e a investimenti successivi in redesign e valutazioni effettuate tramite esperti.
  • favorire una maggiore attenzione da parte degli operatori pubblici sul tema dell’usabilità, anche in riferimento a disposizioni esistenti (si vedano i criteri di valutazione di cui all’allegato B del Decreto Ministeriale 8 luglio 2005, in attuazione della Legge 9 gennaio 2004, n. 4., criteri illustrati in questa sezione delle Linee Guida).

Poiché nata dalla fusione delle procedure 2.1 (generalista) e M (mobile), la procedura eGLU LG, versione 2018.1, qui delineata è, nelle sue linee generali, indipendente dalla tecnologia e dal mezzo. Ciò significa che è pronta per essere applicata, eventualmente con minimi aggiustamenti, a una varietà di prodotti e servizi su diversi canali distributivi e con diverse tecnologie: siti web informativi, servizi online erogati attraverso tecnologie web, documenti cartacei e modulistica finalizzati alla comprensione e all’utilizzo da parte di un ampio pubblico, applicazioni multipiattaforma (applicazioni software che possono essere usate in un ambiente web-based da desktop e da tablet, o in concorso con un’apposita App), App specifiche per tablet o smartphone.

La procedura eGLU, di seguito descritta, per brevità fa più spesso riferimento ai siti. Ma può allo stesso modo essere adattata alla più ampia varietà di dispositivi, situazioni, canali e materiali.

La procedura di osservazione degli utenti si svolge con le seguenti modalità:

  • il conduttore dell’osservazione stila dei compiti da sottoporre ad alcuni partecipanti. I compiti, chiamati task dagli esperti, possono riguardare, per esempio, la ricerca di specifiche informazioni, la compilazione di moduli online, lo scaricamento di documenti;
  • alcuni utenti vengono selezionati e invitati a partecipare;
  • si chiede a ciascun utente di eseguire i task assegnati. Durante l’osservazione non si pongono domande dirette, ma si osservano le persone interagire col sito e le eventuali difficoltà che incontrano. I task possono essere eseguiti con successo o meno. Al termine dell’esecuzione si usano dei questionari per raccogliere informazioni sul gradimento e sulla facilità d’uso percepita;
  • sulla base dei dati raccolti si può avere un’idea dei punti di forza del sito e delle sue criticità. Questo consente di apportare da subito modifiche in base ai problemi riscontrati, di approfondire le criticità con test avanzati condotti da esperti o di confrontare fra loro le criticità di versioni successive del medesimo prodotto.

La procedura contempla l’uso di 9 allegati, disponibili nel Kit Usability Test.

L’intera procedura, se condotta correttamente, può essere considerata un test minimo di usabilità, benché semplificato e di primo livello (esplorativo), e può essere svolta anche da non esperti.

Per raccogliere e analizzare dati in modo più approfondito o per svolgere test con obiettivi più complessi è opportuno, nonché necessario, rivolgersi a un esperto di usabilità.

Il protocollo eGLU LG, versione 2018.1, serve così anche a dare al personale delle PA una visione più realistica dei problemi di interazione presenti in un sito web o in un servizio online. Tale consapevolezza, fondata su una cultura centrata sull’utente, è il perno principale utile a riferire poi, a chi deve decidere del redesign, dove e come dovranno operare gli esperti.

Le fasi della procedura

Di seguito vengono descritte le diverse fasi nelle quali si articola la procedura:

  1. Preparazione;
  2. Esecuzione;
  3. Analisi dei risultati.
4. Preparazione

Questa fase prevede i seguenti aspetti:

  • analisi preliminari del sito e dei destinatari;
  • quanti utenti selezionare;
  • quali tipologie di utenti scegliere;
  • quali e quanti task preparare;
  • come preparare i moduli per la raccolta dati;
  • cosa fare prima dell’osservazione: il test pilota;
  • prendere appuntamento con i partecipanti.
Analisi preliminari del sito e dei destinatari

I test di usabilità, come quello che si può realizzare con la procedura eGLU, si applicano a una grande varietà di situazioni e di progetti, e in momenti diversi del ciclo di progetto. La procedura è comune, ma alcuni controlli possono cambiare a seconda del tipo di progetto.

Questa analisi preliminare va attuata ogni volta che si deve testare un sito online e funzionante (e non, ad esempio, se si intende testare un semplice prototipo semifunzionante), e serve a verificare che si visualizzi correttamente su tutti i dispositivi, in particolare quelli mobili, che si intendono utilizzare per i test. Come previsto da il “Piano Triennale per l’Informatica nella Pubblica Amministrazione 2017-2019”, tutti i progetti delle PA devono infatti essere realizzati secondo una strategia mobile-first.

Analisi tramite strumenti online per il mobile

Un buon punto di partenza è condurre un’analisi attenta di come il sito si modifica in base ai diversi dispositivi. Per fare questo è possibile utilizzare un insieme di strumenti disponibili online che vi permettono di vedere come il sito sarà visualizzato tramite diversi dispositivi e di fare una valutazione preliminare di cosa funziona e cosa può essere migliorato dal punto di vista del codice di programmazione.

Strumenti di supporto validi per quest’analisi preliminare sono:

  • Mobiletester.it: permette la simulazione su telefoni e tablet ed anche un test minimo di quanto la versione mobile sia funzionale;

  • Developers tools di Google:

    • Mobile-Friendly Test di Google: offre un veloce test che certifica che la versione mobile del sito è rilevabile online;
    • PageSpeed Insights: offre un test abbastanza dettagliato con una valutazione da 0 a 100 della velocità del sito mobile (Speed) e della esperienza utente (UX) garantita dal sito in termini strutturali;
    • Google Chrome, inoltre, offre un set di strumenti per emulare sul proprio computer l’utilizzo di un dispositivo mobile;
  • Firefox offre una versione del proprio browser per lo sviluppo, anch’essa dotata di molti strumenti per simulazione e testing;

  • Anche il W3C offre un validatore con molti test utili.

Dopo essersi accertati che l’interfaccia mobile del sito risponda adeguatamente ai diversi dispositivi e aver risolto eventuali problemi individuati tramite i vari strumenti, occorre assicurarsi che l’interfaccia mobile funzioni adeguatamente, cioè che le funzioni progettate (bottoni, link, form, ecc.) siano eseguibili da mobile (dispositivi mobili) e che l’architettura dell’informazione del sito mobile sia adeguata.

Analisi ispettive da svolgersi prima del test con metodologia eGLU

I test di usabilità, come quello della procedura eGLU, si applicano a una grande varietà di situazioni e di progetti, e in momenti diversi del ciclo di progetto. Alcuni progetti con elevata complessità di programmazione e molte funzionalità, possono soffrire di alcuni bug in certi momenti del ciclo di sviluppo. Per questo genere di progetti è spesso consigliabile svolgere, prima del test, un’analisi preliminare secondo varie possibili modalità, ma che comprenda almeno una prova passo passo dei task prima di sottoporli ai partecipanti.

L’analisi ha dei precisi vantaggi:

  • si identificano errori di funzionamento che potrebbero rendere impossibile l’esecuzione del test con i partecipanti e si può passare alla loro immediata risoluzione;
  • si evita di far perdere tempo ai partecipanti per scoprire bug e problemi funzionali che possono essere identificati con metodologie di ispezione svolte prima del coinvolgimento degli utenti. Questo consente di utilizzare il test per identificare problemi di usabilità e di interazione, anziché funzionali;
  • consente di adattare i task ai limiti di funzionamento che il prodotto ha in quel determinato momento; per esempio, se sappiamo che una procedura non esegue un controllo di congruità sui dati inseriti dall’utente, possiamo tenerne conto sia nel task che durante l’esecuzione.
Analytics per l’analisi dell’audience

Un ultimo tipo di analisi che può essere effettuata è quella degli Analytics. Questa analisi può darci informazioni importanti sulle modalità di fruizione degli utenti, sulle sezioni più navigate, sulle eventuali criticità del sito, sulle chiavi di ricerca utilizzate più spesso. Per approfondimenti si rimanda al capitolo sui Web Analytics delle Linee Guida.

Quanti e quali tipologie di partecipanti selezionare
Quanti partecipanti

Con 5 partecipanti appartenenti alla stessa tipologia di utenti, è possibile far emergere circa l’85% dei problemi più frequenti di un sito, per quella tipologia di utenti. In particolare, i problemi che si presentano con una frequenza almeno del 31%. Aumentando il numero dei partecipanti, la percentuale di problemi con quella frequenza si incrementa di poco, perché ogni nuovo partecipante identifica sempre più problemi già incontrati dai partecipanti precedenti.

Si consideri però che l’aggiunta di nuovi partecipanti aumenta la probabilità di rilevare problemi con frequenza inferiore, il che in certe situazioni può essere desiderabile o addirittura importante. Un problema poco frequente non è necessariamente poco grave, se è in grado di invalidare l’esecuzione di alcuni compiti cruciali in alcune situazioni particolari. Si valuti dunque, caso per caso, in base all’importanza di identificare:

  1. una quota più alta, rispetto al teorico 85%, di problemi frequenti;
  2. un certo numero di problemi più rari.
Quali tipologie di partecipanti

Oltre al numero, è bene preoccuparsi della tipologia di partecipanti da invitare. È importante che questi siano rappresentativi del bacino di utenza del sito.

Se il nostro bacino di utenti ha conoscenze o caratteristiche differenziate (ad esempio, se ci rivolgiamo in parte ad un pubblico indistinto di cittadini, ma in parte anche ad uno specifico settore professionale, come consulenti del lavoro, o commercialisti, o avvocati, ecc.), sarà bene rappresentare, nel nostro piccolo campione di partecipanti, queste diverse categorie. Così, il nostro gruppo potrebbe essere composto, ad esempio, da tre partecipanti che rappresentino il pubblico più ampio e tre che rappresentino i consulenti del lavoro.

Più è differenziato il nostro bacino di utenza, più difficile sarà rappresentare in un piccolo campione tutte le tipologie di utenti. In tal caso possiamo condurre l’osservazione con la consapevolezza che i risultati non possono coprire tutti i possibili usi del sito e rimandare ad un’osservazione successiva eventuali verifiche sulle tipologie di utenti che non siamo riusciti ad includere nel nostro campione.

In sintesi:

  1. Se ci si rivolge a una sola tipologia di utenti, è consigliato avere almeno 5 partecipanti;
  2. Se ci si rivolge a più tipologie di utenti, è utile avere almeno 3-5 partecipanti in rappresentanza di ciascuna tipologia;
  3. Se tuttavia il reperimento di partecipanti appartenenti a tutte le tipologie non è possibile o non è economico, si terrà conto di questa impossibilità nella valutazione dei risultati (che evidenzieranno quindi solo i problemi comuni alle tipologie di utenti che sono state rappresentate) e ci si limiterà ad un numero maneggevole di utenti, comunque complessivamente non inferiore a 5.
Controlli preliminari sui partecipanti

Oltre alle caratteristiche del bacino d’utenza del sito, è bene accertarsi che gli utenti invitati abbiano capacità e abitudine ad utilizzare il computer e a navigare in internet. Nella Scheda Partecipanti è presente un questionario da somministrare in fase di selezione o comunque prima di iniziare il test, utile per scegliere i possibili partecipanti. Se dalle risposte si evidenziano differenze tra un certo utente e gli altri, è bene scartare quell’utente e sostituirlo con un altro che abbia lo stesso livello di competenze di base della maggioranza, e che appartenga al medesimo bacino d’utenza.

Quali e quanti task preparare

Il conduttore deve preparare le descrizioni dei task da assegnare ai partecipanti. Ogni task deve descrivere degli obiettivi che i partecipanti devono cercare di raggiungere utilizzando l’interfaccia. Non c’è una regola assoluta, ma un numero di task tra 4 e 8 offre una buona copertura delle possibili attività sul sito e un numero di dati sufficienti per valutare la facilità d’uso dello stesso.

Il conduttore sceglie e descrive i task cercando di individuare e rappresentare una situazione il più possibile concreta. Nella formulazione bisogna essere chiari e usare sempre espressioni comuni, evitando di utilizzare parole chiave che potrebbero facilitare il partecipante nel raggiungimento dell’obiettivo e falsare, quindi, il risultato del test: ad esempio, vanno evitati il nome del link corrispondente, o richiami al testo del link o di qualunque altro link nei menu, il formato del file da trovare. Se il task contiene la parola “imposte” e c’è un link “imposte” sul sito, è molto probabile che anche chi non capisce cosa voglia dire il task scelga il link “imposte” per semplice riconoscimento. In tal caso usare una parafrasi.

È importante che tutti i partecipanti eseguano gli stessi task, uno alla volta, ciascuno per conto proprio. Ma affinché il test dia qualche indicazione utile, è necessario che i task siano significativi, scelti cioè fra le attività che plausibilmente gli utenti reali svolgerebbero sul sito.

Per capire quali attività gli utenti svolgono effettivamente sul sito - attività questa preliminare alla identificazione e formulazione dei task - ci sono diversi metodi:

  • parlare con utenti reali conosciuti e chiedere loro per cosa usano più spesso il sito;
  • raccogliere informazioni con un questionario online che chieda la stessa cosa;
  • analizzare le pagine più viste;
  • analizzare le chiavi di ricerca utilizzate più spesso nel motore interno al sito;
  • formulare degli scenari d’uso.

La copertura delle tipologie di task è affidata comunque all’analisi del sito, delle sue necessità, dei suoi usi e delle sue statistiche.

Tipologie di task

Per ciascuna delle tipologie di attività che è possibile svolgere sul sito, è bene scegliere almeno uno o due task tra le seguenti tipologie:

  • trovare informazioni online;
  • scaricare e/o consultare documenti (diversi da contenuti html) disponibili per il download;
  • compilare moduli online.

I task possono riguardare anche altro, ad esempio l’uso del motore di ricerca, i pagamenti online, o l’iscrizione ad aree riservate, se presenti.

Uso del motore di ricerca interno

Se si è consapevoli del fatto che il motore non funziona adeguatamente, si può decidere di non consentire il suo utilizzo, oppure, al contrario, di farlo utilizzare per poterne avere o meno conferma. Se, invece, la maggior parte dei partecipanti ricorre sistematicamente alla ricerca tramite motore, si può eventualmente chiedere loro durante il test e dopo l’uso del motore di provare a raggiungere gli obiettivi proposti navigando nel sito. In ogni caso, non è da ammettere mai la ricerca tramite motori esterni al sito (per es. Google).

Criteri di successo per i task

Durante l’osservazione dei partecipanti bisogna essere sicuri di poter capire se un task è stato completato o fallito. Per far ciò, oltre a individuare, studiare e simulare bene il task, prima del test, è importante:

  • stilare un elenco degli indirizzi URL di ciascuna pagina del sito che consente di trovare le informazioni richieste;
  • identificare la pagina di destinazione di una procedura di registrazione/acquisto/ iscrizione/scaricamento. A volte i partecipanti possono trovare le informazioni anche in parti del sito che non erano state considerate, oppure seguendo percorsi di navigazione intricati o poco logici: bisognerà decidere prima, in tal caso, se il compito vada considerato superato. Specularmente, a volte gli utenti sono convinti di aver trovato l’informazione anche se non è quella corretta. In questo caso è importante indicare con chiarezza che il compito è fallito;
  • definire il tempo massimo entro il quale il compito si considera superato. Molti utenti infatti possono continuare a cercare l’informazione anche oltre un ragionevole tempo, per timore di far brutta figura. Questi casi vanno presi in considerazione: non è sempre possibile interrompere gli utenti per non creare loro l’impressione che non siano stati capaci di trovare l’informazione, dunque, è spesso consigliato lasciarli terminare. Tuttavia, se superano un certo limite temporale, anche qualora trovino le informazioni, il compito va considerato fallito. Un tempo congruo, per la maggior parte dei task, è da considerarsi dai 3 ai 5 minuti. Il tempo esatto va considerato sia in relazione alla complessità del compito stesso, che al tempo stimato durante la prova preliminare;
  • definire il numero di tentativi massimi entro il quale il compito si considera fallito. 3 o 4 tentativi falliti sono spesso sufficienti a definire il compito come fallito, anche se, proseguendo, l’utente alla fine lo supera.

Il focus del test è capire i problemi: task che richiedono molto tempo o molti tentativi per essere superati, segnalano un problema ed è dunque giusto considerarli dei fallimenti.

Si veda come esempio la Guida alla Conduzione del test.

Come preparare i moduli per la raccolta dei dati

Prima di eseguire la procedura, devono essere adattati e stampati tutti i documenti necessari:

  • un’introduzione scritta per spiegare gli scopi del test. Lo stesso foglio va bene per tutti perché non c’è necessità di firmarlo o annotarlo (Guida alla Conduzione del test);
  • un modulo di consenso alla eventuale registrazione audiovideo per ciascun utente (Liberatoria);
  • per ciascun utente, un foglio con i task, dove annotare se gli obiettivi sono raggiunti o meno e i comportamenti anomali (Guida alla Conduzione del test);
  • può risultare utile stampare un task per foglio e consegnare ogni volta il foglio corrispondente, poiché è importante che gli utenti, mentre eseguono un task, non abbiano conoscenza dei task futuri;
  • i fogli per il questionario di soddisfazione finale, in copie sufficienti per tutti gli utenti (a seconda delle scelte, uno o più fra il Net Promoter Score , il Questionario SUS e le Domande UMUX Lite ; N.B.: il Questionario SUS e le Domande UMUX Lite sono da considerarsi in alternativa).
Cosa fare prima dell’osservazione: il test pilota

Prima di iniziare l’osservazione con i partecipanti al test, è importante che il conduttore esegua i task e li faccia eseguire ad un collega, per realizzare quello che si chiama “test pilota”. Questo consente di verificare se ci sono problemi nell’esecuzione o altre problematiche che è bene risolvere, prima di coinvolgere i partecipanti. Il test pilota, inoltre, serve anche a:

  • accertarsi che siano ben chiari i criteri di successo per ogni task;
  • notare se il sito presenta malfunzionamenti o se la formulazione dei task debba essere migliorata;
  • apportare le eventuali necessarie modifiche ai criteri di successo o alla formulazione dei task.

Al fine di effettuare questi controlli è consigliabile utilizzare diversi dispositivi mobili, con differenti tipi di connessione internet e diversi tipi di browser. Una lista aggiornata di browser, con i quali è suggerita la compatibilità dei siti e applicazioni pubbliche, è disponibile nella sezione dedicata. Non è necessario che l’aspetto del sito sia identico sui diversi dispositivi; va tuttavia garantita un’esperienza utente equivalente.

Prendere appuntamento con i partecipanti

I partecipanti vanno contattati e con ciascuno di loro va preso un appuntamento. Se si intende procedere a più test nello stesso giorno, la distanza tra l’appuntamento di un partecipante e l’altro deve essere di almeno un’ora. Infatti, per ogni sessione di test bisogna calcolare il tempo per eseguire con calma l’osservazione, per effettuare la revisione degli appunti e, infine, per la preparazione della nuova sessione di test da parte del conduttore.

2. Esecuzione

Una volta effettuati i passi preparatori per una corretta osservazione, si passa alla fase di esecuzione vera e propria. Tale fase richiede:

  • la preparazione di un ambiente idoneo;
  • la corretta interazione con i partecipanti e conduzione dell’osservazione;
  • la raccolta dei dati;
  • il congedo dei partecipanti al termine del test.
Preparazione di un ambiente idoneo per test mobile e desktop

La caratteristica principale dei dispositivi mobile è la loro portabilità ovvero il fatto che permettono ad un utente di interagire ovunque tramite internet.

Per i dispositivi mobile quindi, al fine di controllare l’uso del servizio in contesti diversi, il conduttore può predisporre valutazioni al di fuori del classico ambiente chiuso che solitamente si utilizza nelle valutazioni con dispositivi desktop.

Definiamo quindi un ambiente di valutazione strutturato e non strutturato:

  • Ambiente strutturato: Ideale per valutazioni desktop, ma idoneo anche per quelle mobile. Questo è un ambiente chiuso ed organizzato per effettuare il test in modo da poter tenere sotto controllo fattori come il rumore di fondo o le interruzioni dovute ad agenti esterni.
  • Ambiente non strutturato: Ideale per valutazioni mobile, ma spesso non idoneo per test desktop. Questo è un ambiente di vita comune in cui si può decidere di effettuare il test per vedere come il prodotto viene utilizzato dall’utente in circostanze più vicine alla realtà. Esempi di ambienti non strutturati possono essere: ambienti comuni o di vita quotidiana in mobilità come un luogo pubblico, un bar, un ristorante, un autobus ecc. In questo tipo di ambienti risulta più difficile controllare interruzioni o altri fattori, per cui un ambiente non strutturato sarà anche meno controllato.

Di seguito sono descritte le fasi esecutive del test, distinte tra ambiente strutturato e non strutturato.

Ambiente strutturato (desktop e mobile)

L’ambiente strutturato è ottimale per lo svolgimento di un’approfondita analisi esplorativa, poiché l’accesso può essere controllato dal conduttore e garantire che l’analisi non sia interrotta da eventi esterni. La strutturazione dell’ambiente è consigliabile quando c’è la necessità di valutare prodotti in fase di sviluppo o di riprogettazione.

Al fine di procedere al test è necessario:

  • un tavolo su cui l’utente possa utilizzare un dispositivo mobile con connessione a Internet (smartphone o tablet) o il computer desktop con cui navigare il sito web;
  • una sedia per il partecipante e una per il conduttore, che sarà seduto di lato, in posizione leggermente arretrata;
  • cancellare la cronologia del browser prima e dopo ciascun test, per evitare che i link già visitati possano costituire un suggerimento.

Al fine di procedere al test inoltre e soprattutto nel caso di test complessi, è consigliabile, benché non sempre indispensabile, utilizzare strumenti di videoregistrazione poiché consentono di verificare, in un momento successivo, l’effettivo andamento della navigazione e l’interazione dell’utente con l’interfaccia.

Strumenti gratuiti utili per la registrazione desktop possono essere:

  • la funzione “registra schermo” offerta da Apple Quick Time in ambiente Macintosh, per la registrazione dello schermo e del partecipante tramite webcam;
  • Screencast-O-Matic (per Windows, Macintosh e Linux).

Esistono, inoltre, vari software che permettono di registrare le sessioni direttamente su dispositivi mobile. Tali software permettono di registrare sia la sessione d’utilizzo che in taluni casi, attraverso la camera frontale del device, anche il volto della persona. Essendo i dispositivi molto vari consigliamo di effettuare una ricerca sui relativi app store per cercare le soluzioni migliori negli specifici casi.

Registrando le azioni e gli eventuali commenti del partecipante è necessario che questo firmi una liberatoria sulla privacy e sul consenso all’utilizzo dei dati (Liberatoria). In mancanza di sistemi di registrazione, si consiglia al conduttore di effettuare il test insieme a un assistente che, in qualità di osservatore, possa impegnarsi nella compilazione delle schede e riscontrare l’andamento delle prove. Anche in caso di registrazione, l’eventuale assistente annoterà comunque l’andamento delle prove, per mettere a confronto in seguito le sue annotazioni con quelle del conduttore.

Ambiente non strutturato (solo mobile)

La valutazione in un contesto non strutturato è consigliabile quando il prodotto da valutare è in fase avanzata di sviluppo o è già online. Questo tipo di valutazione permette di raccogliere velocemente l’opinione degli utenti sul prodotto, tramite NPS (Net Promoter Score ), e tramite un questionario breve di usabilità UMUX o UMUX-LITE (Domande UMUX Lite ).

L’obiettivo è osservare le reazioni, le modalità di interazioni con un prodotto, i comportamenti e le reazioni ai problemi degli utenti in un contesto di vita quotidiana. Si tratta di una valutazione in cui il conduttore ha poco o scarso controllo dell’ambiente. E’ quindi molto più agevole dal punto di vista organizzativo, ma i dati raccolti sono di solito minimali e non generalizzabili.

Per fare un esempio di test in ambiente non strutturato: il conduttore può portare un partecipante in un luogo pubblico e chiedergli di svolgere, seduti a un tavolino e con il proprio smartphone (o con uno messo a disposizione dal conduttore), da uno fino a un massimo di tre task. Il conduttore si siede accanto all’utente chiedendogli di svolgere i task e informandolo che, nell’eventualità lui riscontrasse dei problemi, sarà disposto a discuterne con lui ed eventualmente ad aiutarlo per risolverli. Terminati i task, il conduttore somministra i questionari e congeda l’utente. Il conduttore quindi riporta su un foglio, da allegare ai questionari compilati dall’utente, una breve descrizione delle problematiche più importanti che ha avuto l’utente nell’interazione nonché gli eventuali suggerimenti proposti dall’utente per migliorare l’interfaccia.

Interazione con i partecipanti e conduzione del test
Accoglienza

Al momento dell’arrivo, il partecipante viene accolto e fatto accomodare alla sua postazione nella stanza predisposta.

Prima di avviare il test, è necessario instaurare un’atmosfera amichevole, rilassata e informale; il test deve essere condotto in modo da minimizzare l’effetto inquisitorio che il partecipante potrebbe percepire.

Al partecipante deve essere spiegato chiaramente che può interrompere la sessione di test in qualsiasi momento. Se per il disturbo è previsto di offrire un gadget, va consegnato in questo momento, spiegando che è un segno di ringraziamento per il tempo messo a disposizione.

Istruzioni

Il conduttore chiarisce al partecipante che la sua opinione è importante per migliorare il servizio e che verrà tenuta in grande considerazione; gli spiega cosa fare e come farlo. A tal fine il conduttore può utilizzare come traccia il testo presente nella Scheda Partecipanti. È fondamentale insistere sul fatto che non è il partecipante ad essere sottoposto a test, ma lo è l’interfaccia e che gli errori sono per il conduttore più interessanti dei task portati a termine con successo.

In questa fase, se l’uso del motore di ricerca interno è stato escluso dal piano di test, il conduttore chiarisce che non è possibile utilizzarlo. Inoltre, informa che non si possono utilizzare motori di ricerca esterni per trovare informazioni sul sito, né uscire dal sito per rivolgersi a siti esterni.

Il conduttore, applicando il protocollo del Thinking Aloud (o TA, pensare ad alta voce) chiede ai partecipanti, man mano che questi eseguono i task, di esprimere a voce alta dubbi e problematiche legate alle azioni necessarie per raggiungere lo scopo. L’obiettivo è quello di indurre il partecipante a verbalizzare le difficoltà dovute all’interfaccia, offrendo così al conduttore di raccogliere informazioni rispetto ad eventuali problematiche d’uso del prodotto. In questo modo è più facile capire quali parti di un’interfaccia o di un processo d’uso generino problemi, dubbi e fraintendimenti. Il conduttore dovrà evitare domande dirette che possono guidare il partecipante al raggiungimento dei loro obiettivi, oltre che astenersi da esprimere sorpresa, delusione o gioia per i comportamenti del partecipante, in modo da non influenzarne aspettative e comportamenti. L’indicazione di pensare a voce alta va fornita prima dell’esecuzione dei task ed eventualmente ripetuta un paio di volte, se il partecipante se ne dimenticasse. Se il partecipante avesse difficoltà a pensare a voce alta, è bene non insistere nell’incoraggiamento diretto e porre domande per incoraggiarlo a verbalizzare, per esempio: “Stai avendo delle difficoltà di cui vuoi parlarci?”.

Nei prossimi mesi pubblicheremo un approfondimento su come comportarsi durante i test.

Avvio del test

A questo punto viene letto il primo task, si avvia la registrazione e si inizia l’osservazione del partecipante mentre esegue il compito. Si continua, poi, leggendo via via i task successivi.

È importante ricordarsi di non far trasparire soddisfazione o frustrazione in seguito a successi o fallimenti del partecipante. La reazione del conduttore dovrebbe essere naturale e non trasmettere segnali che facciano capire se il compito è fallito o superato.

Relazionarsi con i partecipanti durante il test

Se un partecipante commette un qualsiasi errore questo non deve mai essere attribuito a lui, ma sempre a un problema del sistema. Occorre quindi fare attenzione a non dire mai al partecipante che ha sbagliato, ma piuttosto utilizzare frasi come: “l’interfaccia non è chiara”, “l’obiettivo è nascosto”, “il percorso da fare è confuso”.

Durante il test il conduttore deve saper gestire la propria presenza in modo da non disturbare il partecipante e, allo stesso tempo, deve alleggerire la tensione di silenzi prolungati, intervenendo se nota che il partecipante si blocca troppo a lungo, ad esempio oltre qualche minuto.

Nota: se il partecipante spende più di due minuti per cercare un’informazione che un buon conoscitore del sito raggiunge in pochi secondi, allora, solo in questo caso, il conduttore può chiedere al partecipante: “Come sta andando la tua ricerca?” oppure “Pensi che sia possibile raggiungere questo obiettivo?” o anche “Ricorda che devi essere tu a decidere e che non c’è un modo giusto o sbagliato: se per te non si può raggiungere l’obiettivo, basta che tu me lo dica”. Inoltre, è possibile congedare, ringraziandolo, un partecipante che è chiaramente annoiato o nervoso, senza però far trasparire l’idea che il partecipante stesso non abbia adeguatamente risposto alle nostre aspettative.

Nei prossimi mesi pubblicheremo un approfondimento su come comportarsi con i partecipanti durante i test.

Dati da raccogliere

Durante la conduzione è necessario che il conduttore del test (preferibilmente con l’aiuto di un assistente) raccolga i seguenti dati:

  • prima di iniziare, una scheda personale anagrafica, se la stessa non è stata già compilata nella fase di reclutamento. Si veda nel kit Usability Test la Scheda Partecipanti;
  • per ogni partecipante e per ogni task, il dato relativo al superamento o meno del task. Si suggerisce, per semplicità, di stabilire un criterio dicotomico, sì o no. In caso di task parzialmente superati, è necessario definire in maniera univoca il successo parziale come un successo o come un fallimento;
  • per ogni partecipante, un questionario generale, fatto compilare al termine di tutti i task (ma prima di svolgere un’eventuale intervista di approfondimento con il partecipante): si consiglia per la sua rapidità di utilizzare almeno uno fra il System Usability Scale (Questionario SUS ) e lo Usability Metric for User Experience (Domande UMUX-LITE). Tali questionari servono per avere indicazioni sulla percezione di facilità d’uso da parte dei partecipanti, un aspetto che va analizzato assieme alla capacità di portare a termine i task;
  • accanto ai predetti questionari di usabilità, vista la facilità di somministrazione, è possibile utilizzare anche il Net Promoter Score (NPS), che mostra elevata correlazione con il SUS;
  • durante l’esecuzione dei task, schede per annotare eventuali difficoltà o successi del partecipante (nello spazio apposito previsto dopo ogni task, come indicato nel Kit nella Guida alla Conduzione del test);
  • al termine del test e dopo la compilazione dei questionari, si può richiedere al partecipante di raccontare eventuali difficoltà e problemi incontrati (che vanno anche essi annotati) ed eventualmente chiedere chiarimenti su alcune difficoltà che l’osservatore potrebbe aver notato.

Prevediamo nei prossimi mesi di pubblicare degli approfondimenti sui questionari.

Proprio perché potrebbe essere difficile annotare tutti i dati e contemporaneamente effettuare altre operazioni come, ad esempio, avviare e fermare la registrazione o svuotare la cache al termine di ogni sessione, è consigliabile che siano almeno 2 persone a condurre il test, con ruoli complementari definiti a priori. È auspicabile che l’annotazione dei comportamenti e delle verbalizzazioni del partecipante venga svolta, per quanto possibile, sia dal conduttore che dall’eventuale assistente.

Osservare e annotare i problemi

Durante il test è molto importante, oltre a interagire in modo corretto con il partecipante (evitando di influenzarlo), annotare i problemi che questo incontra o le sue reazioni positive rispetto a funzionalità o contenuti del prodotto. Potrebbe, ad esempio, non essere sempre semplice identificare un problema, se il partecipante non lo esprime direttamente. Si indicano perciò, di seguito, alcune categorie di eventi che si possono classificare come problemi o difficoltà del partecipante, oppure come apprezzamenti del partecipante:

  • problemi
    • il partecipante si blocca;
    • il partecipante dichiara di essere confuso da elementi di layout, immagini, video, ecc.;
    • il partecipante dichiara di essere confuso dalla sovrabbondanza di opzioni;
    • il partecipante sceglie un percorso del tutto errato;
    • il partecipante non riconosce la funzione di testi, bottoni;
    • il partecipante travisa il significato di testi, bottoni;
  • apprezzamenti
    • il partecipante esprime di sua iniziativa apprezzamenti su un contenuto/servizio specifico;
    • il partecipante esprime di sua iniziativa un apprezzamento rispetto alla ricchezza/completezza/utilità di un contenuto/servizio;
    • il partecipante esprime di sua iniziativa la soddisfazione rispetto a un task completato con successo e facilità.

Si veda anche il paragrafo a seguire «Elenco dei problemi osservati».

Congedare i partecipanti al termine del test

Terminata la navigazione, il conduttore ringrazia il partecipante per la sua disponibilità, sottolineando quanto sia stato prezioso il suo aiuto e risponde a tutte le eventuali domande e curiosità riguardo alla valutazione. Il conduttore fornisce inoltre al partecipante i propri contatti invitandolo a segnalargli, anche successivamente, le sue ulteriori impressioni sull’utilizzo del sito.

Prima del partecipante successivo: note sulla temporizzazione

Prima di accogliere il partecipante successivo, il conduttore e il suo eventuale assistente salvano la registrazione eventualmente acquisita; quindi rivedono e riordinano gli appunti e le note raccolte, relative al partecipante appena congedato. Ciò serve a rafforzare le osservazioni evitando di dimenticarne alcuni aspetti, ma anche alla disambiguazione e alla interpretazione condivisa dei fatti osservati, nel caso sia presente un assistente. A questo punto viene preparata la sessione successiva, predisponendo di nuovo il browser, di cui si consiglia di cancellare la cache. Vengono preparati i documenti per il partecipante successivo, vengono riavviati e preparati i programmi o l’hardware per la video o audio registrazione.

È consigliabile una pausa tra un partecipante ed un altro. In questo modo il conduttore potrà riorganizzare le idee, riposarsi e effettuare una sorta di “reset mentale” in vista del successivo partecipante. Si consiglia perciò di prevedere tra ogni partecipante una finestra temporale di almeno 15 minuti. Tuttavia, partecipanti differenti potrebbero impiegare tempi anche sensibilmente differenti a eseguire il test. Dunque, si consiglia di prevedere un tempo congruo per ogni partecipante (che includa accoglienza, esecuzione e riorganizzazione-preparazione del successivo), in ogni caso non inferiore a un’ora. Prendendo fin da subito appuntamenti con i partecipanti a distanza di almeno un’ora tra di loro, si eviterà l’arrivo del successivo partecipante quando non si sono ancora sbrigate tutte le pratiche del precedente. La temporizzazione qui indicata è quella minima e potrebbe essere modificata verso l’alto in caso di test più impegnativi.

3. Analisi dei risultati

In questa sezione si spiega come riassumere i dati raccolti e stilare un report.

Dati di prestazione e questionari di valutazione

I dati di successo nei task, raccolti durante l’osservazione, vanno inseriti nella Tabella dei Risultati dopo la fine dell’esecuzione della procedura.

Questo kit serve:

  • a calcolare il tasso di successo complessivo del sito (calcolato su K task x N utenti totali);
  • a dare un dettaglio anche di quale task abbia avuto il tasso di successo più alto.

Inoltre, i dati soggettivi di intenzione d’uso (NPS), o di usabilità percepita (SUS e UMUX-LITE), espressi attraverso i questionari post-test, vanno elaborati manualmente utilizzando le formule fornite o automaticamente con le tabelle di calcolo presenti nel kit:

Prevediamo nei prossimi mesi di pubblicare degli approfondimenti in merito.

Circa i criteri di valutazione del punteggio nei questionari, si consideri quanto segue:

  • il punteggio NPS (che può distribuirsi fra -100 e 100) dovrebbe essere almeno positivo, e quanto più possibile vicino al 100;
  • il punteggio del SUS (che va da 0 a 100) dovrebbe essere almeno maggiore di 68, e idealmente più alto;
  • il criterio per valutare il punteggio UMUX-LITE è al momento il medesimo adottato per il SUS (>68).
Elenco dei problemi osservati

Bisogna stilare un elenco dei problemi osservati, sulla base dell’elenco visto nella Fase 2. Esecuzione, paragrafo «Osservare e annotare i problemi». Per ogni problema è utile indicare il numero di partecipanti che lo ha incontrato. In questo modo è possibile avere una stima dei problemi più frequenti. Pur se esula dallo scopo del protocollo, può essere utile provare ad assegnare, ove possibile, un giudizio di gravità o di impatto per ciascun problema, a discrezione del conduttore e dell’eventuale assistente.

I problemi osservati andrebbero tutti affrontati e discussi dai responsabili del sito, che sono i principali candidati a indicare le modifiche da effettuare.

Se necessario, bisogna avvalersi della consulenza di un esperto per l’interpretazione dei problemi o per l’identificazione delle migliori soluzioni.

Stesura di un report

Il report conterrà i seguenti dati minimi:

  • Il numero di partecipanti e di task;
  • la descrizione dei task e pagine di completamento (o criterio di successo) del task;
  • il tasso di successo del sito;
  • il tasso di successo per ciascun task e per ciascun partecipante;
  • il SUS o lo UMUX-LITE - Misure dirette dell’usabilità percepita;
  • il NPS - Misura di intenzione d’uso del sito web;
  • un elenco dei problemi riscontrati.

Un ulteriore livello di approfondimento del report può prevedere:

  • una valutazione dei problemi per numero di partecipanti e gravità;
  • dei suggerimenti per la risoluzione dei problemi;
  • una connessione dei problemi riscontrati ai principi euristici violati dall’interfaccia.

Si può fare riferimento all’allegato Report dei risultati presente nel Kit per un semplice modello di report da utilizzare.

Check-list di riepilogo per l’organizzazione del test
Fase 1
  1. Effettuare prove preliminari sul sito mobile con alcuni tool per verificarne le funzionalità di base;
  2. effettuare delle verifiche con metodi euristici per verificare lo stato attuale;
  3. utilizzare i dati degli Analytics del sito per ottenere utili indicazioni sulla popolazione di riferimento e sui browser e dispositivi più utilizzati;
  4. identificare la popolazione fra cui scegliere i partecipanti;
  5. identificare un numero minimo di 5 partecipanti e massimo di 8, se presente un’unica tipologia di utenti e di 3 partecipanti per ogni tipologia, se presenti da 2 a 3 tipologie distinte;
  6. definire i task (gli stessi per tutti i partecipanti) da far svolgere ai partecipanti;
  7. per ciascun task definire i criteri di successo o di fallimento, nonché un tempo limite oltre il quale considerare il task fallito, anche se il partecipante continua e alla fine riesce a raggiungere il successo;
  8. prendere appuntamento con i partecipanti. Nel caso di un ambiente strutturato organizzare una stanza dedicata dove approntare browser e software di registrazione;
  9. svolgere un test pilota con un collega.
Fase 2
  1. Ricevere uno a uno i partecipanti, somministrando i task, mentre un assistente si occupa della registrazione;
  2. interagire con i partecipanti, influenzandoli il meno possibile;
  3. annotare i task riusciti e quelli falliti;
  4. annotare ogni problema, apparentemente incontrato dal partecipante, che si riesca a identificare;
  5. al termine dell’esecuzione dei task somministrare il System Usability Scale (Questionario SUS) o lo Usability Metric for User Experience (Domande UMUX-LITE) per ottenere dati sull’usabilità percepita;
  6. somministrare inoltre il Net Promoter Score (NPS) per ottenere dati sull’intenzione d’uso;
  7. dopo i questionari, chiacchierare con il partecipante, anche ritornando su punti critici ed errori incontrati, per valutare se a posteriori offra indicazioni utili;
  8. interrompere la registrazione, salvarla, congedare il partecipante, quindi azzerare la cache del browser, ripuntare il browser alla pagina iniziale e preparare una nuova registrazione. Si precisa che la registrazione può essere interrotta anche prima della somministrazione dei questionari, per ridurre il peso del file, ma può essere utile includere nella registrazione anche l’intervista;
  9. per il successivo partecipante, ripartire dal punto 8 e così fino all’ultimo partecipante;
  10. al termine di tutte le attività, raccogliere tutti i dati, per ciascun task e per ciascun partecipante nella Tabella dei risultati.
Fase 3
  1. Riunire tutti i problemi annotati con tutti i partecipanti in un unico elenco, indicando quali e quanti partecipanti hanno incontrato ciascuno degli specifici problemi;
  2. produrre il report riepilogativo, usando il Report dei risultati;
  3. discutere in équipe risultati e singoli problemi incontrati, per valutare possibili azioni correttive. Se necessario, approfondire con un esperto.

Ricerche qualitative e quantitative

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

La User Research (ricerca sugli utenti) ha come fine ultimo quello di studiare gli utenti per progettare servizi quanto più rispondenti alle loro effettive esigenze. Questo obiettivo si raggiunge attraverso approcci di ricerca di tipo qualitativo e/o quantitativo, che si differenziano per le caratteristiche del dato che si può ricavare e per l’analisi che se ne può fare. La ricerca qualitativa, in genere, ha come obiettivo cercare di comprendere le motivazioni sottese ad attitudini, comportamenti e atteggiamenti dell’utente, studiandone le attività, i contesti d’uso, le necessità ma anche gli errori e le frustrazioni. A differenza della ricerca quantitativa, non si basa solamente su quello che le persone dicono, ma cerca di guardare più in profondità, mappando quello che le persone dicono, fanno e pensano. La ricerca qualitativa:

  • si fonda su campioni non numerosi;
  • genera dati qualitativi e non validi a fini statistici;
  • non analizza i dati in modo statistico/matematico, ma interpreta informazioni e ispirazioni raccolte rispetto agli obiettivi di progetto e alla sensibilità del ricercatore.

Nella progettazione di servizi digitali la ricerca qualitativa può essere utilizzata in diverse fasi del progetto: dalla fase di osservazione e ideazione a quella di progettazione e validazione. Gli strumenti e le tecniche sono molte e differenti fra loro per il tipo di dato che permettono di raccogliere: per ogni progetto, quindi, è necessaria una valutazione ad hoc per definire gli strumenti e le tecniche più adeguate e le fasi in cui si utilizzeranno.

Le ricerche quantitative si basano invece sulla raccolta di grandi quantità di dati e fanno un largo uso della statistica. Temi estremamente rilevanti per la ricerca quantitativa sono l’idonea impostazione del livello di significatività statistica dei risultati e l’applicazione di una corretta tecnica di campionamento: la prima è imprescindibile per confermare la validità probabilistica di un’ipotesi, la seconda influenza la possibilità di estendere i risultati provenienti dal campione all’intera popolazione oggetto di analisi. Entrambi questi temi - se non correttamente gestiti - generano il rischio di falsare la bontà dei risultati di ricerca.

Introduzione ai metodi

Possiamo distinguere tre tipi di ricerca qualitativa, a cui si associano diversi tipi di strumenti e tecniche:

  • la ricerca esplorativa (o fondativa) si svolge in genere all’inizio di un progetto e permette di analizzare un tema o un problema che non si conosce a fondo. Prevede l’utilizzo di interviste individuali e osservazioni in contesto, orientate alla comprensione delle motivazioni, necessità ed esperienze attuali degli utenti di un servizio.
  • la ricerca generativa si usa in genere per coinvolgere gli utenti in sessioni di discussione e generazione di idee, in una fase del progetto in cui si hanno già sufficienti informazioni sul contesto per poter focalizzare l’attenzione sull’individuazione delle soluzioni. Utilizza tecniche come il focus group e sessioni di co-design, orientate al lavoro collaborativo.
  • la ricerca valutativa infine si svolge quando sono già disponibili i primi prototipi della soluzione progettata e si vuole raccogliere il feedback degli utenti nello sperimentare l’interazione con il servizio digitale in questione. Prevede strumenti come il test di usabilità o il cognitive walkthrough.

Esistono diverse metodologie di ricerca quantitativa. Il progetto per il design dei siti scolastici in Italia offre un caso pratico di ricerca quantitativa basata sulla somministrazione di un questionario. In questo caso, la ricerca quantitativa aveva l’obiettivo di confermare o mettere in discussione alcune delle prospettive emerse da una precedente fase qualitativa basata su interviste. Vai alla ricerca. Nel paragrafo dedicato ai web analytics sono descritte le modalità di analisi del comportamento degli utenti di un sito web, una delle fonti primarie di informazioni nei progetti digitali. Nel paragrafo dedicato agli A/B test illustreremo invece un metodo di ricerca quantitativa funzionale a supportare processi di miglioramento continuo di un servizio digitale.

Le interviste individuali

La ricerca esplorativa si ispira ai metodi dell’etnografia applicata, per la necessità di entrare in contatto con le persone nel loro contesto abituale di vita, e di capire i loro comportamenti in profondità. La tecnica principale è quella dell’intervista individuale: il ricercatore incontra ciascun partecipante di persona e raccoglie una serie di spunti ponendo domande, costruendo un dialogo, e ascoltando con attenzione ciò che il partecipante racconta. Ecco alcuni consigli per organizzare al meglio le sessioni di intervista individuale.

Vai al Kit di Designers Italia sulle User Interviews

Costruire un piano di ricerca

Il primo passo per impostare le interviste è pianificare l’attività nel dettaglio, riflettendo sull’obiettivo della ricerca e su chi ha senso incontrare (e dove) per raggiungere quell’obiettivo. Il piano di ricerca include:

  • la dichiarazione di un tema di investigazione chiaro e analizzabile tramite una ricerca qualitativa (es. “l’obiettivo della ricerca è capire a quali servizi i cittadini vorrebbero poter accedere tramite il sito del proprio Comune”).
  • la definizione delle specificità del metodo di intervista, ovvero la sua durata (può variare da 1 a 2 ore a seconda della complessità dell’argomento di discussione), il numero di ricercatori coinvolti (minimo 2, massimo 3 persone), il contesto in cui avranno luogo le sessioni (si tenderà a privilegiare l’ambiente domestico, ma possono anche essere svolte nello spazio di lavoro o in altri luoghi neutrali).
  • la definizione di un campione di ricerca che tiene conto delle diverse tipologie di utenti coinvolti nell’utilizzo del servizio (quali variabili, e quali quantità). Un buon campione per una ricerca qualitativa prevede il coinvolgimento di un numero di circa 6-8 persone della stessa tipologia.
  • la definizione delle aree geografiche in cui la ricerca avrà luogo, considerando le diversità tra Nord, Centro e Sud Italia, ma anche tra centri urbani di grande, media e piccola dimensione. Talvolta è utile anche riflettere sulle differenze all’interno di una specifica area urbana, tra zone di periferia e centro città.
  • la definizione di una scaletta temporale delle varie attività, che includa eventuali spostamenti da una città all’altra e tenga conto dei tragitti necessari per raggiungere le diverse case (o luoghi di riferimento) dove incontrare i partecipanti. La buona pratica è di svolgere 2 (massimo 3) sessioni nell’arco di una giornata, per avere tempo di metabolizzare le informazioni raccolte di volta in volta, e mantenere il livello di energia necessario per condurre questo tipo di attività.

Preparare la guida alla discussione

La guida alla discussione è un documento che raccoglie una serie di spunti relativi alle domande da svolgere durante l’intervista. La guida viene costruita individuando in primo luogo le aree tematiche da affrontare durante l’intervista, come se fossero dei capitoli della conversazione. Ciascun capitolo contiene una serie di domande, che il ricercatore prepara in anticipo in modo da raccogliere tutti i punti che sarà necessario trattare e prepararsi agli incontri. Durante l’intervista il ricercatore porta con sé la guida alla discussione per assicurarsi di non dimenticare nessun punto: anche se la conversazione può prendere varie direzioni e non seguire il flusso logico ipotizzato all’inizio, l’importante è coprire tutti i temi, in modo da avere una base dati completa al termine delle interviste.

La guida alla discussione può essere accompagnata da una serie di materiali visivi che possono essere un utile stimolo per trattare alcuni punti della discussione, rendendo la conversazione più interattiva e in alcuni casi più immediata. Questi materiali possono essere ad esempio delle card che mostrano diverse funzionalità di un servizio e aiutano a prioritizzare insieme i vari elementi, e vengono progettati di volta in volta a seconda del contenuto dell’intervista.

Stampare la modulistica

Il coinvolgimento degli utenti richiede sempre estrema attenzione nel modo in cui si gestiscono i dati personali. Per ogni attività di ricerca è necessario preparare e stampare delle liberatorie per il consenso al trattamento dei dati che vengono sottoposte all’attenzione di ciascun partecipante al termine dell’intervista, dando loro la possibilità di scegliere se acconsentire alla conservazione del materiale audio-video e/o fotografico raccolto durante la sessione oppure no. In caso positivo, il materiale potrà essere condiviso con il proprio team di lavoro e utilizzato per costruire dei report dell’attività. In caso negativo, il materiale relativo a quel partecipante dovrà essere cancellato, e verranno prese in considerazione per l’analisi solo le informazioni raccolte verbalmente.

Condurre le interviste

Le interviste sono un momento molto delicato, da gestire con estrema cautela per assicurarsi di raccogliere tutte le informazioni necessarie, creando una situazione che metta a proprio agio il partecipante e documentando attentamente tutte le osservazioni emerse. Ecco alcuni aspetti da considerare per preparare al meglio il momento dell’intervista:

  • definire dei ruoli chiari all’interno del gruppo che gestirà la ricerca sul campo è fondamentale per non incutere timore ai partecipanti, presentandosi come gruppi troppo numeroso o facendo piovere domande da ogni direzione. Il numero di ricercatori ideale per ogni sessione di intervista è due, di cui una persona intenta a moderare l’intervista e una persona dedita alla raccolta di note e alla documentazione fotografica. In caso di tre persone questi ultimi due compiti possono essere suddivisi, distinguendo il ruolo del trascrittore di note da quello del fotografo.
  • definire la strategia di documentazione dell’attività richiede di riflettere su come verranno raccolte e gestite le note e su quali strumenti verranno utilizzati per la documentazione audio-video e fotografica della sessione. Solitamente le note vengono raccolte in formato digitale, in spreadsheet che possono essere facilmente condivisi con gli altri partecipanti alla ricerca e raccogliere tutte le trascrizioni delle interviste in varie tab. Per la documentazione audio-video e fotografica si raccomandano strumenti di piccole dimensioni, non intrusivi, in modo da preservare per quanto possibile la naturalezza della conversazione.
  • è necessario infine ricordare l’importanza di alcune soft skills: la capacità di ascoltare in modo aperto, mettendo da parte le proprie idee, pregiudizi e assunzioni fatte in precedenza; la gestione della propria espressione e postura durante il dialogo in modo da mostrare interesse e partecipazione; la capacità di gestire la conversazione e stabilire una relazione empatica con il partecipante, adattando le domande e il protocollo dell’intervista alla tipologia di risposte ricevute.
  • durante l’intervista, chiedere ‘perché’ più e più volte è indispensabile per approfondire ciascuna risposta e raggiungere quel livello di profondità che si desidera raggiungere con l’intervista individuale.

Sintetizzare i risultati

Al termine di ciascuna intervista, i ricercatori discutono tra di loro i risultati emersi, annotando a caldo i temi rilevanti, le cose che non sapevano o che li hanno sorpresi, quello che vogliono essere sicuri di ricordarsi. Questo primo momento di debriefing è fondamentale per iniziare a processare le informazioni raccolte e fissare alcuni elementi per un secondo momento di analisi più strutturata. Al termine delle attività di ricerca, i ricercatori analizzano le note raccolte, individuando i pattern di comportamento emersi, ovvero i temi chiave condivisi da tutti o buona parte dei partecipanti. In questa fase possono essere utilizzati alcuni strumenti di service design come i personas e le user journey per raccogliere le informazioni raccolte in profili utente e mappature dell’esperienza.

I focus group

La ricerca di tipo generativo prevede l’utilizzo di una tecnica chiamata focus group, ovvero un’intervista di gruppo (anziché individuale) in cui un ricercatore (o moderatore) propone una serie di esercizi e temi di discussione a un panel selezionato di partecipanti. L’organizzazione di un focus group segue un processo molto simile a quello descritto per la pianificazione di interviste individuali. Una delle principali caratteristiche distintive del focus group è quella di far leva sulle dinamiche di gruppo per stimolare la discussione, raccogliere diverse opinioni, e giungere a un consenso (o dissenso) collettivo rispetto a una specifica soluzione proposta. Ecco una lista di attività necessarie per la preparazione di un focus group, e consigli pratici per la moderazione.

Costruire un panel di partecipanti

Il punto di partenza per l’organizzazione del focus group è la definizione del tipo di partecipanti da coinvolgere. A seconda del contesto e dell’obiettivo delle sessioni di ascolto di gruppo si possono coinvolgere gruppi omogenei, ovvero persone che condividono caratteristiche simili (per età, estrazione sociale, conoscenza della tecnologia o conoscenza del servizio) oppure gruppi misti, ovvero persone che rappresentano diverse tipologie di utenti collegati al servizio in questione. I gruppi omogenei aiutano ad avere una comprensione completa del punto di vista di una stessa categoria di utenti, facendo leva sul fatto che tutti i partecipanti condividono le stesse competenze, problemi e necessità. Nel caso di gruppi misti si cerca invece di creare una situazione di scambio, in cui il confronto tra punti di vista e necessità differenti può facilitare la comprensione di tutti i fattori in gioco e l’individuazione di soluzioni che soddisfano molteplici bisogni. Al di là della omogeneità o disomogeneità del gruppo, il primo passo è sempre quello di definire nel dettaglio tutti i criteri che il campione dei partecipanti deve soddisfare e costruire un questionario di screening che permetta di formare un panel soddisfacente. Il questionario di screening è un insieme di domande orientato a raccogliere dati su ciascun rispondente in modo da capire se è qualificato o meno per partecipare al focus group. Questo questionario può essere distribuito in formato digitale o cartaceo, cercando di raggiungere il più ampio numero di persone possibile (per esempio, tutti gli abitanti di un Comune, o tutti gli insegnanti di una scuola) in modo da raccogliere un alto numero di risposte e mettere il ricercatore nella condizione di selezionare i partecipanti più adatti per la sessione, analizzando le risposte e bilanciando tra le diverse variabili desiderate. Un focus group può prevedere un minimo di 5 fino a un massimo di 10 partecipanti in un’unica sessione, supportati da un moderatore nello svolgimento degli esercizi o dello scambio di idee e opinioni e da una persona incaricata di prendere appunti per documentare le informazioni e osservazioni emergenti. È buona pratica svolgere almeno 3 sessioni di simile tipologia (es. 3 focus group con lo stesso insieme di partecipanti) per avere un quantitativo di dati sufficiente per l’analisi.

Progettare un focus group

Per organizzare un focus group è necessario definire una durata temporale (variabile tra 1 e 3 ore a seconda della quantità di temi da coprire) e un luogo neutrale per lo svolgimento delle sessioni. Il ricercatore progetta quindi le attività da svolgere durante il focus group sulla base degli obiettivi da raggiungere. In un momento iniziale di esplorazione e generazione di idee, il focus group può essere impostato come una conversazione di gruppo, in cui il moderatore solleva degli spunti di discussione e agevola lo scambio di opinioni tra i vari partecipanti. In questa fase può essere utile avere una lista di storie, funzionalità o servizi da prioritizzare insieme, in modo da passare da uno scambio iniziale libero a una discussione focalizzata, in cui i partecipanti traducono le loro necessità in richieste maggiormente tangibili. In un momento più avanzato di esplorazione e generazione di idee, il focus group può essere utilizzato per sottoporre ai partecipanti diverse soluzioni e discutere insieme vantaggi e svantaggi di ciascuna proposta, in modo da capire quali aspetti validare e quali invece migliorare rispetto alle loro specifiche esigenze. Sulla base del tipo di attività da svolgere, il moderatore prepara in anticipo una scaletta dei vari punti di discussione o esercizi e l’insieme dei materiali necessari per facilitare la sessione. I materiali possono includere card stampate contenenti descrizioni testuali di storie, funzionalità o servizi, oppure storyboard che raccontano nuovi scenari, oppure ancora prototipi (digitali o analogici) di nuovi servizi.

Moderare il focus group

Il compito del moderatore (o facilitatore) è quello di guidare la discussione, sulla base dei temi e delle attività definite nella scaletta della sessione. Durante la sessione, il moderatore pone domande specifiche, volte ad avviare la discussione, e cerca di alimentarla chiedendo dettagli, motivazioni e aneddoti sulla base delle risposte raccolte. Se la discussione prosegue in modo naturale e produttivo, il moderatore lascia i partecipanti liberi di confrontarsi e di condividere i diversi punti di vista. Quando invece la conversazione rallenta, oppure si blocca attorno a opinioni contrastanti, il moderatore riprende il controllo della discussione passando a un altro argomento o interpellando una persona specifica all’interno del gruppo. Rivolgersi ai partecipanti chiamandoli con il loro nome proprio è fondamentale per esprimere sempre con chiarezza a chi è indirizzata la domanda (in caso sia necessario) e mettere i partecipanti a proprio agio. Uno dei rischi dei focus group è quello di avere persone con opinioni molto forti o per natura più estroverse di altre che diventano figure guida nella discussione, allineando le opinioni altrui alle proprie o rispondendo sempre a tutte le domande per primi. Il moderatore deve individuare questi soggetti e trovare il modo di arginare la loro influenza sul gruppo, dando la possibilità a tutti di esprimere la propria opinione, e – se necessario – invitando esplicitamente questi partecipanti a dare spazio anche agli altri nella conversazione.

Documentare i risultati

Ciascun focus group viene documentato tramite la raccolta di note relative alle informazioni e osservazioni che emergono durante lo scambio: per questo è bene prevedere una persona dedicata alla raccolta di appunti, in aggiunta al moderatore. Le sessioni possono inoltre essere documentate tramite la registrazione video (in questo caso è necessario chiedere ai partecipanti di firmare il modulo di liberatoria). I materiali vengono utilizzati per costruire un report dei focus group che va ad informare le successive attività di sviluppo delle soluzioni di

L’A/B testing

L’A/B testing è una metodologia di analisi che ha l’obiettivo di confrontare due versioni di una pagina web di un sito o di un’applicazione, che differiscono per un elemento specifico. Permette quindi di effettuare delle scelte di design basate su dati - secondo l’approccio data-driven tipico della ricerca quantitativa - confermando o confutando delle ipotesi progettuali.

Obiettivo di questo tipo di test è arrivare - tramite ottimizzazioni successive - a superare un problema o migliorare una performance di UX (e non solo). Gli utenti cui il test viene “somministrato” sono suddivisi in due gruppi ad ognuno dei quali viene mostrata una delle due diverse varianti/configurazioni. Alla fine del test vengono analizzati e confrontati i dati derivati delle due versioni sperimentate: la variante con la performance migliore rispetto all’obiettivo del test verrà portata avanti nel percorso di sviluppo.

Caratteristica della metodologia A/B testing è quella di testare un elemento per volta così da poter isolare senza ambiguità quale variazione abbia prodotto un determinato risultato. Tramite tale metodologia si possono testare diversi elementi di una pagina web, dalla grafica, al layout e organizzazione degli elementi del sito, ai contenuti: può ad esempio essere interessante utilizzare l’A/B test sui contenuti, sia per esaminare quanto influisca la lunghezza di un testo sulla fruizione del sito, sia per ciò che concerne il microcopy.

Vai al kit di supporto per la realizzazione di test A/B

Web analytics

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Premessa

Questa guida ha l’obiettivo di aiutare chi si occupa a vario titolo del sito web di una pubblica amministrazione a:

  • comprendere il funzionamento di una piattaforma di web analytics
  • capire come collezionare i principali indicatori di performance di un sito
  • capire come interpretare determinati set di dati per trarre informazioni utili rispetto al comportamento degli utenti e il loro livello di soddisfazione
  • comprendere quali azioni migliorative applicare ai contenuti, ai metadati e alla struttura del sito in base ai risultati dell’analisi dei dati
  • comprendere come configurare una piattaforma di web analytics su uno o più siti
  • comprendere come produrre e distribuire un report di analytics, per condividere i dati di utilizzo con gli stakeholder e il team di lavoro interno
  • comprendere come una lettura sistematica dei dati possa influenzare positivamente la comprensione dei comportamenti online degli utenti e consentire l’avvio di azioni migliorative dei servizi digitali

Introduzione

L’analisi delle performance di un ambiente web è un’attività cruciale per comprendere in che maniera un sito (o un servizio digitale di altro tipo) rispondono in maniera adeguata ai bisogni informativi e/o di servizio degli utenti.

Questa tipologia di analisi consente di rispondere, ad esempio, in modo puntuale alle seguenti domande:

  • Quanti utenti visitano il sito, per quanto tempo e quali e quante pagine visitano?
  • Quali sono le principali città da cui provengono i visitatori del sito? Quanti utenti che visitano il sito provengono dall’Italia e quanti eventualmente dall’ estero?
  • Quali sono i contenuti più visitati dagli utenti in un dato intervallo di tempo?
  • In quale momento della settimana o dell’anno il sito registra il maggiore o il minore numero di visite? Queste oscillazioni sono causate da un’eventuale stagionalità delle tematiche trattate o coincidono con la pubblicazione di nuovi contenuti?
  • Quali sono i termini tramite cui gli utenti arrivano al sito tramite un motore di ricerca? Rappresentano per la maggior parte il nome/dominio del sito oppure fanno riferimento a informazioni/servizi trattati al suo interno?
  • Quali sono i principali termini di ricerca digitati nel motore di ricerca interno del sito, se presente?
  • In che percentuale gli utenti che visitano il sito lo fruiscono da dispositivi mobili?

Le risposte a tali domande derivano dall’analisi continuativa di indicatori di performance che offrono ad esempio informazioni su quali siano volumi di traffico del sito, quale il comportamento degli utenti, quale la qualità dei contenuti pubblicati o quale l’efficienza tecnologica del sito nel suo complesso.

Metriche e Dimensioni

I dati generati dalle piattaforme di web analytics sono il frutto di combinazioni eterogenee di metriche (dati quantitativi) e dimensioni (attributi qualitativi dei dati). Si precisa che il numero reale dei visitatori conteggiati per un dato intervallo di tempo è soggetto a distorsioni — per eccesso o per difetto — dovute al fatto che il calcolo degli utenti in web analytics è basato su cookies e tende quindi a generare più o meno utenti unici al variare di determinate circostanze (accesso al sito da dispositivi diversi, browser diversi, cancellazione dei cookies). Di seguito una panoramica esplicativa delle principali metriche e dimensioni utilizzate nella web analysis. Si precisa che la nomenclatura di metriche e dimensioni può variare a seconda della piattaforma di analytics utilizzata.

Principali Metriche (dati quantitativi)
Visite

Definizione: numero totale di visite al sito in un dato intervallo di tempo (anche da parte dello stesso utente)

A cosa serve: rappresenta il volume di traffico che il sito riceve in un determinato lasso temporale. È una delle metriche più usate per costruire uno storico dei volumi di traffico del sito, su cui basare comparazioni e/o proiezioni

Visite uniche

Definizione: numero di singoli individui (o singoli IP) che ha effettuato almeno una visita al sito

A cosa serve: è la metrica che restituisce in maniera accurata il numero di singoli individui che ha interagito con il sito in un dato lasso di tempo

Visualizzazioni di pagina

Definizione: numero totale di pagine visitate, anche da parte dello stesso utente, in un dato intervallo di tempo. Comprende visualizzazioni ripetute della stessa pagina

A cosa serve: indica il volume complessivo dei contenuti del sito acceduti dagli utenti

Pagine visitate per visita

Definizione: media aritmetica del numero di pagine visitate per visita al sito. Comprende le visualizzazioni ripetute della stessa pagina

A cosa serve: offre indicazioni sulla “profondità” delle visite al sito e sul livello di coinvolgimento dei contenuti. Tale metrica deve essere interpretata a seconda della natura del sito e dei suoi obiettivi (es. rispetto al numero minimo di pagine desiderate per visita)

Durata delle visite

Definizione: media aritmetica della durata di una singola visita al sito

A cosa serve: indica il tempo medio trascorso dai visitatori sul sito. Tale metrica deve essere interpretata a seconda della natura del sito e dei suoi obiettivi

Tempo sulla pagina

Definizione: media aritmetica del tempo trascorso dagli utenti su una determinata pagina (o un insieme di pagine)

A cosa serve: determina l’efficacia di un contenuto, a seconda della sua tipologia e dei suoi obiettivi

Frequenza di rimbalzo

Definizione: percentuale di visitatori che ha abbandonato il sito dopo una pagina

A cosa serve: misura la quota di utenti che arrivano al sito e lo abbandonano subitaneamente. La percentuale di frequenza di rimbalzo può essere interpretata in maniera opposta a seconda della natura del sito: ad esempio una frequenza di rimbalzo alta per un sito informativo è indice del fatto che le pagine potrebbero essere scarsamente utili/interessanti, mentre può essere considerata un dato positivo per un sito o una pagina che hanno il semplice scopo di direzionare gli utenti altrove

Nuove visite

Definizione: percentuale delle prime visite al sito sul totale delle visite

A cosa serve: metrica utile in particolare quando l’obiettivo del sito è quello di accrescere i volumi di traffico provenienti da nuove tipologie di visitatori

Nuovi utenti/utenti di ritorno

Definizione: rapporto fra prime visite al sito e utenti che hanno già visitato il sito precedentemente, in un dato intervallo di tempo

A cosa serve: a seconda degli obiettivi del sito, serve a comprendere in che misura i volumi di traffico si suddividono fra nuovi utenti e utenti fidelizzati

Velocità di caricamento del sito

Definizione: quantità di tempo media (espressa in secondi) impiegato da una pagina del sito per caricarsi, dall’avvio della visualizzazione nel browser alla fine del suo caricamento

A cosa serve: metrica fondamentale per monitorare l’efficienza del sito in termini di velocità, anche e soprattutto per la fruizione da dispositivi mobili

Principali Dimensioni (attributi qualitativi dei dati)
Tempo
intervallo di tempo su cui impostare una rilevazione (giorno, settimana, mese, anno, intervallo personalizzato)
Provenienza geografica e lingua
luogo da cui provengono le visite degli utenti (paese, città, continente, subcontinente); impostazioni relative alle preferenze di lingua
Tecnologia utilizzata
strumenti tecnologici utilizzati dagli utenti per la navigazione sul sito (tipologia di dispositivo, browser, sistema operativo, provider di rete)
Contenuti
le pagine, le pagine di entrata e di uscita, gli “eventi” compiuti sul sito (es. download di documenti, click su link outbound)
Canali di acquisizione del traffico
canali web tramite cui gli utenti arrivano al sito. Il raggruppamento di canali principali comprende: traffico diretto, ricerca organica (cioè traffico non a pagamento proveniente dai motori di ricerca), siti referenti, social. Altri canali - se attivi - sono ad esempio: email marketing, digital advertising, affiliazioni
Ricerca su sito
monitora la funzione di search del motore interno di un sito web, restituendo i termini di ricerca immessi dagli utenti, il numero di ricerche per termine e altri indicatori
Obiettivi
per tracciare il completamento di determinate azioni eseguite degli utenti sul sito (es. compilazione di un form, durata minima di una visita, numero minimo di pagine per visita)

Analizzare le ricerche degli utenti

Le ricerche degli utenti sono quasi sempre il più ampio vettore di traffico verso i contenuti web. Per questa ragione, non soltanto è fondamentale fare in modo che le pagine di un sito siano “ottimizzate” per essere trovate dagli utenti attraverso i motori di ricerca, ma è altrettanto importante analizzare i dati di web analytics provenienti dalle ricerche interne ed esterne al sito per avere contezza delle performance dei singoli contenuti e del livello di soddisfazione-utente che generano.

Ecco i principali indicatori da tenere in considerazione quando si analizzano le ricerche degli utenti e le relative azioni migliorative che si possono intraprendere:

Ricerca esterna al sito
Top motori di ricerca referenti

Definizione: Principali motori di ricerca (Google, Bing, Yahoo…) che portano traffico al sito

Azione: Usa i relativi webmaster tools (es. Google Search Console) per ottimizzare i contenuti e la struttura del sito e renderli così più facilmente scansionabili dai crawler dei motori e “trovabili” dagli utenti

Top termini/frasi di ricerca

Definizione: Le principali parole e frasi digitate nei motori di ricerca tramite cui gli utenti arrivano al sito

Azione: Verifica che i termini utilizzati dagli utenti coincidano o siano simili a quelli utilizzati nel sito. Puoi prendere spunto da parole e frasi utilizzate dagli utenti per migliorare la terminologia che usi nei titoli, nei metadati, nelle URL e in generale all’interno dei contenuti, in modo da favorirne l’ottimizzazione sui motori di ricerca

Top termini di ricerca con basso CTR (click through rate)

Definizione: Parole e frasi digitate nei motori di ricerca che portano la minore quota di traffico al sito

Azione: Revisiona e aggiorna i contenuti che gli utenti visitano dopo aver cercato tali termini, per renderli più appetibili e utili

Ricerca su sito
Top termini/frasi di ricerca

Definizione: Le principali parole e frasi digitate dagli utenti nel motore di ricerca interno del sito

Azione: Crea nuovi contenuti o aggiorna quelli già presenti, incorporando la terminologia degli utenti nei metadati, negli eventuali tag e nel testo stesso, in modo da aiutare i visitatori a trovare le informazioni più aderenti ai bisogni espressi nella ricerca

Top ricerche che non generano risultati

Definizione: Parole e frasi digitate dagli utenti nel motore interno del sito che non restituiscono risultati, per mancanza di contenuti associati o non rappresentati nella maniera corretta

Azione: Analizza i contenuti per capire se è il caso di aggiornarli o di pubblicarne di nuovi che rappresentino il bisogno espresso dall’utente nella ricerca

Top termini di ricerca con basso CTR (click through rate)

Definizione: Parole e frasi digitate nel motore di ricerca interno che restituiscono il più basso numero di visualizzazioni di pagina

Azione: Incorpora la terminologia valida nei testi e nei metadati per rendere le pagine più rilevanti rispetto a quei termini

Principali oscillazioni nelle top ricerche

Definizione: Macro cambiamenti nel ranking dei termini più cercati nel motore di ricerca interno del sito

Azione: Cerca di analizzare le ragioni per cui alcuni termini diventano meno ricercati di altri e viceversa; assicurati che per i nuovi termini di ricerca diventati popolari siano presenti contenuti che soddisfano i nuovi bisogni espressi dai visitatori

Utenti che utilizzano la ricerca su sito

Definizione: Percentuale dei visitatori unici del sito che utilizza la funzione di ricerca interna

Azione: Ti aiuta a capire se è il caso di ottimizzare le funzionalità di ricerca e l’architettura informativa del sito, facendo in modo che i contenuti più ricercati siano il più possibile visibili

La segmentazione

La segmentazione in web analytics consiste nell’isolare dal traffico web aggregato sottoinsiemi di visite (o di utenti unici) che condividono attributi (qualitativi e/o quantitativi) comuni. La segmentazione del traffico in sottogruppi, ha l’obiettivo di far emergere il “valore” di uno specifico insieme di utenti rispetto al traffico aggregato - che è tipicamente quello più rappresentato nei report, ma meno rappresentativo delle specificità dei singoli gruppi di utenza.

Nelle principali piattaforme di web analytics la segmentazione può essere applicata utilizzando segmenti preimpostati (laddove disponibili) oppure creando dei segmenti di utenza ad hoc. Si possono creare segmenti sulla base di attributi demografici dei visitatori, delle tecnologie utilizzate per navigare il sito, del comportamento, della data di prima visita dell’utente, delle sorgenti di traffico, e così via.

Il traffico «segmentato» può essere poi quindi comparato nei rapporti e nelle configurazioni dashboard.

Per maggiori dettagli sulla segmentazione utenti si rimanda al Kit Web Analytics.

La reportistica

Un’analisi sistematica dei dati statistici di performance e soddisfazione utente è fondamentale per decidere quali azioni migliorative intraprendere su un servizio digitale.

È altrettanto fondamentale la creazione di una reportistica ad hoc che abbia la finalità di essere condivisa all’interno di un team di lavoro (o con altri stakeholder). In linea generale è possibile creare e inviare report customizzati direttamente dalle principali piattaforme di web analytics.

Per un approfondimento sul tema, si rimanda al Kit Web Analytics.

Strumenti di web analytics: Web Analytics Italia

In questa sezione puoi trovare informazioni e alcuni link di approfondimento che ti aiuteranno a comprendere come adottare uno strumento di web analytics per i tuoi siti e servizi digitali.

Tieni presente che a partire dalla prima metà del 2020, è disponibile gratuitamente una soluzione di web analytics open source dedicata alle pubbliche amministrazioni italiane, Web Analytics Italia (WAI).

WAI ha lo scopo di:

  • centralizzare e standardizzare la raccolta e l’elaborazione dei dati di traffico e comportamento utente dei siti e dei servizi digitali delle PA
  • facilitare per gli operatori l’accesso ai dati, la loro condivisione e la loro interpretazione grazie a risorse e reportistica ad hoc
  • garantire la massima aderenza alla norma GDPR in termini di privacy degli utenti tracciati, oltre che la completa proprietà e controllo del dato rilevato da parte dell’amministrazione
  • offrire una vista aggregata dei dati di traffico raccolti accessibile pubblicamente, in ottica di condivisione e trasparenza.

Il servizio WAI si colloca nel contesto delle Linee guida di design per i servizi digitali della PA italiana, oltre che nel Piano Triennale per l’Informatica nella PA.

Per saperne di più su WAI puoi consultare il sito webanalytics.italia.it oltre che la guida utente di riferimento.

Ricorda che la soluzione open source WAI è compatibile e può funzionare contemporaneamente a qualsiasi altro strumento di web analytics che stai già utilizzando.

Nei paragrafi seguenti ti proponiamo inoltre una serie di link di approfondimento per comprendere come installare/configurare due fra le principali piattaforme di web analytics, Matomo (piattaforma open source) e Google Analytics (piattaforma commerciale, nella sua versione free).

User interface

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

L’interfaccia utente è tutto ciò che fa da ponte tra i servizi digitali e i loro destinatari. È l’insieme dei cosiddetti touch point di un servizio digitale. Non si tratta solo di una serie di elementi grafici e visuali, ma di tutto ciò con cui l’utente entra in relazione, nei vari contesti, per usare un servizio o un prodotto digitale.

L’interfaccia utente (in inglese user interface, abbreviato UI) è l’insieme di quegli elementi con i quali il cittadino interagisce per ottenere servizi digitali. Non si compone esclusivamente di elementi grafici o visuali, ma comprende tutto ciò con cui l’utente entra in relazione durante l’utilizzo di un servizio digitale.

Nei passi che compongono la progettazione di un servizio, dopo la fase di ricerca che consente di definire le diverse tipologie di utenti (personas), comportamenti e scenari di utilizzo (user stories e user journeys), si passa alla fase di realizzazione del prodotto, che comporta anch’essa alcuni passaggi, con diversi livelli di dettaglio dell’interfaccia stessa.

Principi

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Progettiamo Servizi, non interfacce

Lo scopo primario dell’interfaccia di un servizio è quello di aiutare l’utente a raggiungere ciò che cerca in modo naturale ed immediato, in modo quasi trasparente. Per questo, la coerenza dei vari elementi che la compongono, anche su diversi dispositivi, è un elemento fondante per la creazione di prodotti funzionali e semplici da usare.

Un altro punto cardine di una buona interfaccia è la sua inclusività e la tolleranza agli errori: non ci si deve aspettare che l’utente abbia sempre chiaro ciò che vuole, sappia comprendere appieno eventuali istruzioni, o che sia in grado di decifrare colori ed elementi d’interfaccia non familiari.

In quest’ambito, il designer ha lo scopo di progettare interfacce che sappiano accompagnare il cittadino nel percorso di ricerca del servizio, correggendo eventuali errori e prevedendo diverse modalità di utilizzo da parte di utenti ad esempio con disabilità fisiche, con difficoltà di comprensione tecnologica, o che utilizzano dispositivi per l’accesso ai servizi con limitate capacità o scarsa connettività.

In questa parte delle linee guida ci concentriamo sugli elementi più classici della costruzione d’interfaccia, partendo da un prototipo grezzo fino ad arrivare ad un sito o ad una app funzionante e pronta per essere usata da chiunque.

Il modello di un’interfaccia

Il livello di dettaglio più basso viene definito attraverso la creazione di un modello (chiamato anche prototipo o, in inglese wireframe) dell’interfaccia utente, definendo una struttura di massima dell’esperienza utente durante il suo percorso nella ricerca ed utilizzo del servizio.

La realizzazione di un prototipo “a bassa fedeltà” (in inglese lo-fi) per un’interfaccia utente definisce:

  • l’organizzazione degli elementi interattivi nello spazio disponibile sullo schermo;
  • la collocazione dei blocchi di contenuto;
  • la sequenza di passaggi (in inglese workflow) che l’utente deve fare per concludere un processo;
  • le modalità di interazione o comportamento dell’utente con il prodotto.

Tutto questo viene progettato con un’attenzione agli aspetti di struttura dell’informazione e dei flussi di navigazione, senza preoccuparsi in questa fase delle soluzioni di dettaglio che definiscono le interfacce dal punto di vista «grafico». Durante questa fase infatti viene concretizzata soltanto la struttura portante del servizio e le soluzioni ipotizzate in fase di ricerca.

Questa scelta assicura che l’attenzione sia incentrata sugli aspetti fondamentali della navigazione e della struttura, nel pieno rispetto dei requisiti di progetto e dei bisogni dei cittadini da soddisfare. In questo modo si incoraggia la discussione e il confronto sulle soluzioni proposte.

Un esempio di wireframe, o prototipo a "bassa fedeltà".

Un esempio di wireframe, o prototipo a «bassa fedeltà».

Nella Figura è mostrato un esempio di prototipo costruito con un programma di design, ma per costruire un wireframe si possono usare diversi metodi, dalla carta ai numerosi software messi a disposizione dal mercato specificatamente per questo scopo.

Altre informazioni sul processo di prototipazione e tutti i riferimenti al wireframe kit di Designers Italia sono disponibili nel capitolo dedicato alla prototipazione. Nel paragrafo seguente affronteremo invece i principi e le linee guida per il design delle interfacce.

Il disegno di un’interfaccia e lo UI Kit

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Il disegno dell’interfaccia

Il disegno dell’interfaccia in “alta fedeltà” (in inglese hi-fi) è la fase finale della progettazione che si concentra sugli aspetti grafici di visual design, aggiungendo dettagli, stile e animazioni.

L’interfaccia viene costruita tenendo come punto di riferimento il wireframe contenente la struttura generale del prodotto: lo scheletro viene trasformato e arricchito in modo da dare una resa reale del prodotto finale, nonostante questa sia ancora mancante di tutta quella parte di interazione con l’utente che verrà realizzata durante la fase di sviluppo.

Un esempio di un progetto a bassa ed alta fedeltà.

Un esempio di un progetto di pagina web desktop a bassa fedeltà, a sinistra, e, a destra, la realizzazione dell’interfaccia grafica ad alta fedeltà.

Il visual design dell’interfaccia utente, specularmente al wireframe, sarà quindi composto da diversi elementi come bottoni, campi di compilazione, menù, blocchi di testo ecc., i quali di norma vengono combinati e posizionati seguendo una griglia per organizzare il loro posizionamento nello spazio.

Uniformità ed identità

Il visual design serve quindi a presentare informazioni e comportamenti in modo comprensibile e semplice tenendo presente non soltanto l’aspetto estetico, ma soprattutto le esigenze dell’utente.

Tutto ciò che riguarda lo stile è soltanto una parte del prodotto.

Sebbene la comunicazione visiva attiri giudizi soggettivi, le tematiche legate al gusto estetico non sono così fondamentali come si possa pensare. Tutto ciò che afferisce all’aspetto estetico fornisce degli indizi o crea delle emozioni, ma non è sufficiente ad ottenere un’esperienza soddisfacente.

Una chiara rappresentazione degli obiettivi dell’esperienza utente (user experience) del prodotto sono invece le fondamenta imprescindibili di tutti quegli aspetti di interfaccia utente che fanno parte dell’identità e che generano una risposta emozionale positiva.

L’interfaccia utente (User Interface, in breve UI) è di fatto una conversazione tra l’utente e il prodotto, attraverso dei task che servono a far raggiungere gli obiettivi di progetto per il cittadino. La logica di funzionamento è la stessa di una conversazione tra due persone: la comunicazione è focalizzata sull’obiettivo e deve essere efficace per ottenere una comprensione chiara e completa.

Standard visuali

L’uniformità di un’interfaccia, concretizzata attraverso degli standard visuali e di comportamento, fa sì che, se applicata correttamente, porti importanti benefici.

In primo luogo, gli utenti utilizzeranno più rapidamente e con facilità i percorsi che hanno già imparato a riconoscere. Potranno prevedere i comportamenti del prodotto basandosi su un’esperienza pregressa.

In secondo luogo, portano ad una riduzione dei costi di produzione attraverso il riuso di design e di codice già pronti e che sono il risultato di discussioni e decisioni già prese, favorendo anche una riduzione dei costi di supporto e assistenza agli utenti poiché gli standard incrementano la facilità d’uso e di apprendimento.

L’applicazione di un modello non basta però a costruire una buona interfaccia: gli standard rispondono a questioni relative a generali processi cognitivi e di percezione. Essi devono essere inglobati nel contesto di riferimento, che presuppone un’organizzazione logica e strutturale, che può richiedere specifici “comportamenti” e scegliere percorsi dedicati a particolari bisogni dell’utente.

È possibile approfondire queste tematiche anche nel paragrafo Conoscere gli utenti.

Lo stile

Lo stile è il «linguaggio» del design, ed è costituito da elementi variabili come la forma, il colore, la tipografia, o l’applicazione di spazi coerenti tra loro. Questi aspetti sono combinati insieme per creare una risposta emozionale (riconoscibilità, confidenza con il servizio), e dare solidità e consistenza al layout, aiutando l’utente nella navigazione e nella ricerca delle informazioni.

Lo stile è trasversale a tutti i componenti di una interfaccia: ognuno è costruito sulla base di una griglia, utilizzando ben definite palette di colori, tipo e dimensione dei caratteri, spaziature, ombre, ecc.

Lo UI Kit per la creazione dell’interfaccia

Il prototipo ad alta fedeltà può essere costruito utilizzando lo UI kit messo a disposizione da Designers Italia e descritto di seguito, di cui si possono trovare i file sorgente in formato Sketch sul repository GitHub dedicato:

Esso è inoltre pubblicato su InVision, una piattaforma di condivisione dove è possibile vedere tutti gli elementi disponibili:

Lo UI Kit fornisce una libreria di elementi già pronti che possono essere assemblati per montare un’interfaccia utente adatta a servizi della PA.

Gli elementi di cui si compone il kit sono raggruppati nelle seguenti categorie principali:

  • Tipografia
  • Definizione di colori e loro applicazione
  • Posizionamento e spaziature, con un sistema di griglie
  • Icone
  • Bottoni
  • Elementi di navigazione, come menu e liste di link
  • Elementi per la visualizzazione di dati e contenuti
  • Elementi di data entry, come campi di testo ed esempi di form

La costruzione degli elementi segue una roadmap dove si può osservare e commentare il progetto in corso di realizzazione.

Poiché l’approccio è open source, le Pubbliche Amministrazioni, le agenzie e singoli cittadini possono contribuire alla discussione e alla modifica dello UI Kit stesso.

Un esempio di componenti dello UI Kit.

Un esempio di componenti dello UI Kit con le indicazioni necessarie alla loro applicazione.

Come si usa lo UI Kit

Lo UI Kit è realizzato seguendo un sistema a blocchi, che può essere paragonato ad un set di pezzi componibili, dimensionati in modo da poter essere assemblati ed adattati.

Costruzione di un’interfaccia attraverso i principi di composizione.

Costruzione di un’interfaccia attraverso i principi di composizione.

Ogni componente ha un numero di proprietà ad esempio la forma e il colore che possono essere combinati o variati per comunicare un diverso significato. Si pensi ad esempio ad un bottone: esso può essere, “primario” o “secondario”, in stato di “riposo” o “premuto”. Il modo in cui sono applicate queste proprietà o variazioni darà un significato differente al componente.

Variazioni di un’interfaccia.

Variazioni di un’interfaccia.

Il software scelto per costruire lo UI Kit è Sketch.

La scelta di questo software è legata ad alcune caratteristiche fondamentali. In primo luogo, è possibile gestire la libreria di componenti in modo trasversale a tutti i file che si vogliono creare ed aggiornarla qualora vengano modificati i componenti. Inoltre, mettendo a disposizione una piattaforma di sviluppo collaborativo, permette di installare innumerevoli estensioni (plugin) a seconda delle esigenze di design.

In alternativa, è possibile importare il file Sketch in altri programmi di prototipazione, come Adobe XD, Studio, o Figma.

La tipografia

La principale famiglia di font usata nello UI Kit è il Titillium Web. È stato scelto come typeface principale per i contenuti web, grazie alla x-height ampia, alla struttura lineare e alla flessibilità d’uso essendo composto da 11 stili.

Il Titillium Web è stato realizzato come progetto didattico dagli studenti del corso in Type Design dell’Accademia di Belle Arti di Urbino.

Il font Titillium Web.

Il font Titillium Web.

Un typeface secondario è il Roboto Mono, la variante monospaced della famiglia Roboto. È stato introdotto nelle Linee Guida per la chiarezza e leggibilità dei numeri pertanto è adatto ad essere utilizzato per la rappresentazione di numeri, calcoli matematici, numeri in tabelle, codice di programmazione.

Il font Roboto Mono.

Il font Roboto Mono.

Un terzo typeface con grazie (o serif) è il Lora, introdotto per la sua leggibilità e nato espressamente per la lettura su display.

Il font Lora.

Il font Lora.

Tutti questi typeface sono rilasciati con licenza SIL Open Font License e sono scaricabili da Google Fonts, una piattaforma di distribuzione gratuita di font per il web.

Corpo del testo

Le misure dei caratteri non devono essere utilizzate senza una logica, ma devono seguire una scala tipografica precisa e studiata appositamente per creare una gerarchia visiva.

Un esempio di scala tipografica.

Un esempio di scala tipografica.

La gerarchia serve a gestire la trasmissione di un messaggio e il suo impatto, e quando non viene utilizzata la comunicazione diventa meno efficace.

Un esempio di gerarchia.

Un esempio di gerarchia.

La dimensione del corpo del testo, con riferimento ad esempio al font Titillium Web, non può essere inferiore a 16px per uno schermo mobile e inferiore a 18px per schermi grandi.

Si possono utilizzare misure inferiori in caso di didascalie, note, o testi di secondaria importanza che per lunghezza o posizionamento nella pagina richiedano dimensioni ridotte.

Dimensionamento dei paragrafi

La lunghezza di un paragrafo che permetta una lettura confortevole del testo non dovrebbe superare i 75 caratteri. In caso di colonne multiple, la lunghezza può essere compresa tra 40 e 50 caratteri. Per testi a margine, la lunghezza è non dovrebbe essere inferiore ai 15 caratteri.

Un paragrafo di testo deve essere composto con allineamento a sinistra. Nei casi in cui si prevedono paragrafi a margine posti a sinistra del blocco di testo principale, il paragrafo può essere allineato a destra. L’allineamento giustificato e senza sillabazione è invece sempre da evitare per l’incongrua spaziatura delle parole e la minore leggibilità che comporta.

I paragrafi possono essere distinti applicando uno spazio verticale tra di essi o, in alternativa, usando una indentatura di misura pari a quella dell’interlinea.

L’interlinea (in inglese, leading), sia dei titoli che del corpo del testo, è calcolata tenendo conto di una immaginaria griglia di 8px, in modo da creare una sorta di “ritmo verticale” nella lettura.

Colore del testo

Il colore del testo deve essere tale da garantire un rapporto di contrasto minimo con lo sfondo sfondo di 4,5:1 (AA) come stabilito dalle specifiche di accessibilità. Approfondisci nella sezione Accessibilità.

Collegamenti

I collegamenti (in inglese, link) ad altre aree del servizio o a siti esterni devono avere un elemento di distinguibilità rispetto al testo normale.

Pertanto, è buona norma mantenere una sottolineatura, specialmente se il link è inserito all’interno di un paragrafo. Alternativamente, si può utilizzare anche il grassetto.

Il colore

Il colore è un elemento essenziale nella definizione di un’interfaccia: può servire a differenziare, connettere, evidenziare, nascondere. Contribuisce alla gerarchia visiva e può essere un elemento di supporto alla comunicazione.

Nota

Il colore influisce sull’accessibilità del prodotto. Gli utenti affetti da disabilità visive come la deuteranopia, protanopia e tritanopia potrebbero non vedere bene i colori oppure non vederli affatto. Approfondisci nella sezione Accessibilità.

Lo schema colore

La scelta dei colori è dettata dal materiale identitario dell’Ente o Agenzia (logo, stemma, gonfalone etc.) o comunque da elementi afferenti alla sua riconoscibilità.

In uno schema colore distinguiamo il colore base, che viene utilizzato per una percentuale maggiore rispetto agli altri colori, i colori secondari e i colori neutri (ad esempio grigi, bianco, nero).

Tra i colori secondari si dovranno definire:

  • colori strettamente connessi al colore base
  • un eventuale colore di risalto (chiamato accent color), utilizzato in misura minore poiché è associato a elementi che prevedono un’interazione, come bottoni, elementi di controllo (sliders, radio, ecc.), link, campi di testo.

Si consiglia l’utilizzo di una palette costituita da non più di 5 tonalità, dove non più di 3 avranno un differente valore di colore (hue, in inglese).

La palette può essere:

  • monocromatica, quando è costituita dal colore base e dalle sue variazioni in termini di saturazione e/o luminosità.
  • policroma, ossia costituita da associazioni di colori con differente hue. Questo tipo di schema oltre al colore base e alle sue variazioni, comprende un colore che può essere scelto tra gli analoghi, complementari, triadici, ecc. del colore base, oppure scelto dalla gamma di colori appartenenti all’identità visiva.
La palette estesa

La palette può essere estesa, creando variazioni in termini di saturazione e luminosità dei colori scelti come “colore base”, da cui si possono generare tinte, ombre e toni.

Le tinte e le ombre consistono nell’aggiunta rispettivamente di bianco e di nero al colore di base, che significa variare i valori di saturazione (in inglese saturation, indicata con “S”) e luminosità (in inglese brightness, indicata con “B”).

Per esempio, dato un colore base con i valori H 93; S 100; B 50, si possono sottrarre 10 gradi di luminosità (B) per ottenere le variazioni più scure o aggiungere 10 gradi di luminosità (B) per quelle più chiare fino a un massimo di 80 gradi di luminosità.

Per ottenere le cosiddette “tinte” basta aumentare progressivamente di 4 gradi la luminosità (B) a partire da un valore di 80 e contemporaneamente diminuire la saturazione (S) di 15 gradi.

Un esempio di variazioni di colore.

Un esempio di variazioni partendo dal colore base H 93, S 100, B 50 verso le tinte (in alto) e verso le ombre (in basso)

Per ottenere diversi toni è necessario diminuire contemporaneamente i valori di saturazione e luminosità di 10 gradi.

La palette delle Amministrazioni Centrali

Un esempio di schema cromatico costruito sui principi appena descritti è la palette realizzata con il colore base “Blu Italia” (codice esadecimale #0066CC).

Pensata per un design semplice e minimalista, è una palette costituita dalle variazioni del colore base, più le tinte neutre. Sono presenti anche colori che possiamo definire “utility colors”, ossia colori da utilizzare per i messaggi di feedback all’utente (errori o notifiche) o per la realizzazione di elementi grafici.

La palette dello UI Kit è piuttosto estesa: comprende molte variazioni in tinte, toni e ombre del colore base (il “Blu Italia”), e dei colori secondari e neutri, permettendo così una certa flessibilità di uso.

Un esempio di palette monocromatica estesa.

Un esempio di palette monocromatica estesa.

Un esempio di palette monocromatica di colori di accento.

Un esempio di palette monocromatica estesa di colori per elementi in evidenza.

Un esempio di palette monocromatica di colori neutri.

Un esempio di palette monocromatica estesa di colori neutri.

Le Griglie

All’interno dello spazio a disposizione, l’organizzazione del contenuto deve essere strutturata seguendo un sistema di griglie responsivo, per mantenere una efficace esperienza utente trasversalmente ai dispositivi utilizzati.

La griglia rappresenta la struttura invisibile che permette di organizzare i contenuti della pagina. Una griglia di impaginazione consiste in colonne di testo e immagini, separate da spazi intercolonna e contornate da margini esterni.

Un esempio di griglia.

Un esempio di griglia applicata a diverse risoluzioni dello schermo.

Le dimensioni delle colonne vanno adattate ai cambiamenti della viewport: ogni colonna occuperà una percentuale di spazio specifica a seconda che sia visualizzata su dispositivi desktop, tablet, o smartphone.

La disposizione dei contenuti, a seconda delle dimensione dello schermo, garantisce che i testi siano leggibili anche sugli schermi più piccoli e l’interazione utente (ad esempio, l’utilizzo di form e controlli dinamici) rimanga agevole.

Risoluzione Small Medium Large Extralarge
Breakpoint fino a 768px da 768px a 991px da 992px a 1279px oltre 1280px
Larghezza massima del container nessuna 688px 904px 1184px
Spaziatura 12px 20px 20px 28px

La griglia orizzontale contribuisce alla consistenza del design e a determinare il pattern di lettura di un sito web. In un sistema condiviso come quello di uno UI Kit, è necessario avere una metrica comune, per mantenere coerenza anche tra diversi siti web appartenenti a enti o pubbliche amministrazioni diverse.

La griglia orizzontale è definita sulla baseline del testo, ossia la linea dove poggiano le lettere del font scelto. La baseline diventa una griglia a cui ancorare non solo il testo ma anche gli oggetti del layout. La baseline è di 8px ed è basata sul Titillium a 16px.

Avendo come base la misura di 8 px e i suoi multipli per calcolare dimensioni, padding e margini dei vari elementi, si può ottenere un ritmo verticale armonico.

Un esempio di componente con baseline a 8px.

Un esempio di componente con baseline a 8px.

Nota

È possibile approfondire l’argomento su un post di Designers Italia intitolato: “Le griglie: alla scoperta dello Ui Kit di designers”.

Le icone

Quando si utilizzano delle icone è necessario assicurare una chiara comprensione del loro significato. Pertanto ogni icona dovrà essere associata ad un tooltip o ad un piccolo testo che ne chiarisca l’azione. La stessa icona non dovrà essere utilizzata per indicare azioni diverse all’interno della stesso contesto.

Al fine di garantire una coerenza visiva si consiglia di utilizzare icone provenienti da un unico set grafico come, ad esempio, quelle disponibili gratuitamente su Font Awesome o il set di icone in formato SVG incluso in Bootstrap Italia.

I componenti

Di seguito sono presentati per ogni categoria degli esempi di componenti dello UI Kit. Per avere un quadro completo del kit è possibile collegarsi al progetto UI Kit su InVision.

Bottoni

Lo UI Kit contiene quattro tipologie di bottoni, dal primary al quaternary, ordinati secondo una funzione gerarchica.

Un esempio di componente Bottone.

Un esempio di componente “Bottone” nelle sue varianti, ordinate gerarchicamente.

Tutte le azioni principali sono rappresentate dal bottone “Primary”, a cui può essere associata una o più azioni secondarie attraverso l’uso degli altri bottoni a disposizione.

Un esempio di UI con più bottoni.

Un esempio d’uso del bottone “Primary” e “Secondary”. Il primario mostra l’azione più importante della pagina, il secondario rappresenta un’azione alternativa.

Un esempio di UI con azioni diversificate.

Un esempio d’uso di un bottone “Primary” associato ad un bottone gerarchicamente inferiore. In questo caso è stato usato un “Quaternary” dello UI Kit: l’utente cosi è indirizzato sul bottone primario in modo inequivocabile.

Data display

Nella categoria Data Display sono inseriti i componenti che hanno come funzionalità quella di mostrare informazioni in modo organizzato oppure evidenziato, come ad esempio gli “Accordion” o i “Callout”.

Un esempio di componente Callout.

Un esempio di componente “Callout”.

Data entry

Esempi di componenti appartenenti alla categoria Data entry sono i campi di tipo “Input” che si utilizzano per costruire form. Il componente è costruito in modo da poter attivare o disattivare i diversi status: normale, avvertimento, errore, successo.

L’etichetta del campo è indicativa di cosa va inserito. All’attivazione del campo con il cursore, l’etichetta si sposta in alto.

Nel componente si possono attivare oltre gli stati di feedback, gestendo colori e icone, anche i relativi messaggi.

Un esempio di form contenente componenti “Input”.

Un esempio di form contenente componenti “Input”.

Gli strumenti

Lo UI Kit è disponibile a tutti in formato Sketch sul repository GitHub dedicato, un servizio di hosting dove è possibile commentare, caricare files e interagire tramite messaggi (issue) e contributi (pull request).

Esso è inoltre pubblicato per consultazione su InVision:

Lo sviluppo di un’interfaccia e i Web Kit

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

Alcune attività preliminari alla fase di sviluppo

Durante le fasi iniziali dello sviluppo di un sito web professionale, è di fondamentale importanza dedicare tempo e risorse ad alcune attività che avranno impatto sull’intero ciclo di vita del progetto:

  • un’analisi di componenti (librerie, linguaggi, documentazione, ecc.) e best practices già utilizzate e validate dalla comunità, che possano semplificare e standardizzare la realizzazione del servizio.
  • una revisione dei requisiti di progetto con lo scopo di ottenere un documento di specifiche condiviso, che possa anche definire ruoli e responsabilità.
  • la selezione di una metodologia di sviluppo agile ottimale per il team di lavoro, con una conseguente definizione precisa delle procedure di comunicazione, di testing e di rilascio cadenzato.

Contestualmente a questa fase di kick-off tecnico, è auspicabile avviare sin da subito una fase di prototipazione avanzata, con la quale iniziare a validare in modo iterativo ogni progresso raggiunto. Questo obiettivo può essere ottenuto sia con classici test manuali, che attraverso un’adeguata continuous integration che faccia uso di test automatici.

In caso di applicazioni ad alta interattività o di grandi dimensioni, anche la metodologia di lavoro è fondamentale: un approccio BDD per la stesura delle funzionalità, e l’uso della stessa metodologia per l’applicazione di test funzionali, unit test e test di integrazione, possono essere elementi chiave per il buon funzionamento e la solidità dell’applicazione.

Approccio
Web design responsivo

Il sito web deve sempre essere progettato e sviluppato con un approccio responsive, con l’obiettivo di fornire un’esperienza d’uso ottimale indipendentemente dalla risoluzione dello schermo e dal tipo di dispositivo utilizzato, consentendo in ogni situazione facilità di lettura e navigazione.

Al concetto di responsive web design vanno associate pratiche di semplificazione delle interfacce in ottica mobile first, e un’attenzione particolare nel fornire un’esperienza soddisfacente anche a coloro che hanno difficoltà visive o motorie.

Nota

È possibile approfondire l’argomento nella sezione dedicata all’accessibilità nell’area Service Design.

Mobile first

L’approccio mobile first è, assieme all’utilizzo di progressive enhancement trattato di seguito, una pratica oramai consolidata: consiste nel valutare in prima istanza l’esperienza e le necessità per gli utilizzatori di dispositivi mobili, per poi arricchire di elementi e funzionalità la composizione della pagina mano a mano che la dimensione, le capacità computazionali e di rete del dispositivo aumentano.

L’aproccio mobile first.

Un esempio di approccio mobile first.

Nell’approccio mobile first si parte dall’essenziale.

La forzatura nella progettazione di un’applicazione con ridotte disponibilità di spazio, di interazione, di velocità di caricamento costringe a stabilire delle priorità e a fare delle scelte che risulteranno utili all’usabilità del prodotto.

Per progressive enhancement si intende una pratica fondante per lo sviluppo di una nuova applicazione web flessibile e a prova di future evoluzioni di dispositivi e browser, con la quale la lavorazione inizia da un nucleo solido e irrinunciabile di contenuti che vengono via via arricchiti man mano che il dispositivo utilizzato dal cittadino è più performante e all’avanguardia.

Al contrario, nel caso della graceful degradation, con la programmazione ci si fa carico di verificare che l’interfaccia, inizialmente pensata per i dispositivi più moderni, rimanga navigabile e permetta comunque di accedere alle sue funzioni fondamentali anche man mano che viene fruita attraverso tecnologie meno moderne o meno interattive. In questo secondo caso, si può pensare anche in termini di tolleranza del sito all’assenza di alcune funzionalità.

Come si potrà notare, si tratta in fondo di due risposte diverse alla stessa esigenza: rendere il contenuto accessibile su dispositivi con diverse caratteristiche e potenzialità.

Feature detection

Tecnicamente, l’approccio appena analizzato può essere realizzato attraverso la cosiddetta feature detection (riconoscimento delle caratteristiche): il sito web può rilevare una miriade di proprietà che caratterizzano il metodo di accesso al sito da parte del cittadino.

Nota

Si prega di non confondere la feature detection con la pratica, in passato molto diffusa, di utilizzare lo user-agent (ovvero quale browser e quale sistema operativo è connesso) per differenziare i servizi forniti. È infatti scoraggiato l’utilizzo di user-agent a tale scopo, in quanto impreciso e difficilmente mantenibile vista la quantità di diversi dispositivi in costante uscita sul mercato.

Attraverso una feature detection puntuale, è possibile sapere come indirizzare ogni aspetto dell’informazione che si vuole trasmettere. Tali caratteristiche possono spaziare dallo schermo utilizzato, in termini di dimensioni, risoluzione e densità dei pixel, fino ai metodi di input (mouse, touch-screen, tastiera, input vocale, ecc.); senza dimenticare le opzioni per la stampa e le tecnologie di ausilio per le persone con disabilità.

Ad esempio, attraverso semplici media-queries nel CSS, è possibile mostrare versioni diverse di una pagina web a seconda che il cittadino stia utilizzando uno smartphone, un televisore o voglia stampare la pagina stessa con la propria stampante.

Sia CSS che Javascript permettono di rilevare la presenza puntuale di determinate caratteristiche nei dispositivi usati.

Javascript permette di analizzare qualsiasi funzionalità presente tra le Web API, oltre a poter conoscere praticamente ogni dettaglio dell’utente che è collegato. Ad esempio, attraverso la geo-localizzazione di un dispositivo, è possibile fornire un servizio più preciso a seconda della posizione dell’utente nello spazio, a patto che tale feature sia disponibile nel dispositivo utilizzato. Ecco come si può realizzare:

if("geolocation" in navigator) {
  navigator.geolocation.getCurrentPosition(function(position) {
    // è possibile ottenere la posizione
  })
} else {
  // il browser non può fornire la posizione
}

CSS ha capacità più limitate, ma ad esempio attraverso la regola @support (in modo simile a quanto avviene per la più conosciuta regola @media), può verificare la corretta interpretazione di proprietà CSS da parte dei browser su cui viene usata. Ecco, ad esempio, come si può verificare attraverso il codice se il browser prevede il supporto della funzionalità CSS grid:

@supports not (display: grid) {
  .nome-classe {
    float: right;
  }
}

Esistono moltissimi strumenti per la feature detection e per le pratiche di polyfill e shim (librerie o frammenti di codice che riescono ad arginare le differenze tra i vari Browser nel pieno supporto di alcune funzionalità); di seguito ne sono riportate alcuni.

Strumenti

Una fonte di dati molto utile invece per una verifica a monte delle feature disponibili nei browser è caniuse.com. Tale strumento permette di ricercare e verificare se per i browser supportati è necessaria una gestione ad-hoc di determinate funzionalità oppure no.

Una volta individuati i dispositivi supportati e le feature da realizzare, è buona norma scegliere uno stack di sviluppo che ottimizzi il lavoro.

In ambito CSS, è ormai pressoché d’obbligo l’utilizzo di pre-processori (SASS, LESS, e PostCSS sono i più utilizzati), che migliorano la leggibilità e la modularità del codice sorgente, agevolando nel contempo l’applicazione di pratiche virtuose quali l’utilizzo di BEM, una metodologia per scrivere classi CSS “parlanti”, o di Autoprefixer per la gestione automatica di prefissi CSS a supporto dei vari motori di rendering presenti nei browser.

Per quanto riguarda Javascript invece, la scelta degli strumenti è talmente ampia e mutevole che delineare uno scenario ottimale in termini di framework o librerie non avrebbe senso senza un’analisi approfondita del progetto da realizzare. In questo ambito è necessaria una formazione continua, e un’attenzione particolare a ciò che permetta di ottenere codice modulare, scalabile e performante, senza appesantire l’esecuzione e l’interfaccia utente.

Alcune risorse interessanti, in inglese:

Alcune pratiche sono comunque sempre auspicabili, come la compressione del codice e il caricamento dei file Javascript stessi in modo asincrono oppure al termine della pagina HTML, al fine di non bloccare il rendering della pagina stessa; o ancora, l’utilizzo di strumenti di analisi della sintassi come ESLint o StyleLint per rendere il codice leggibile e coerente con regole condivise dalla comunità degli sviluppatori.

Supporto browser

Come regola generale, per la realizzazione di un servizio web per la PA, è necessario assicurare la compatibilità con versioni dei browser che abbiano una penetrazione media tra la popolazione di almeno 1 persona ogni 100 abitanti.

Ciò significa che, con i dati disponibili ad oggi, è necessario assicurare la compatibilità con almeno i seguenti browser:

  • Apple Safari 11+ (mobile e desktop)
  • Google Chrome (ultime versioni, mobile e desktop)
  • Microsoft Edge (tutte le versioni, mobile e desktop)
  • Microsoft Internet Explorer 11
  • Mozilla Firefox (ultime versioni, mobile e desktop)
  • Samsung Internet 7+

È buona norma analizzare regolarmente le statistiche sull’utilizzo dei dispositivi e delle diverse risoluzioni che gli utenti adoperano per accedere al sito, con lo scopo di abbracciare una base di utenti che copra più del 95% delle versioni utilizzate in Italia. Per fare questo, ci si può avvalere di diverse sorgenti di dati: una delle più usate è StatCounter.com, che permette di filtrare i dati per Paese:

Come ampiamente descritto nel paragrafo precedente, non è necessario che l’interfaccia di un sito web sia assolutamente identica sui diversi dispositivi; graceful degradation significa tuttavia garantire un’esperienza utente equivalente, graficamente coerente, e completa nelle sue funzionalità. Vediamo come sia possibile farlo.

Misurare le prestazioni

Così come avviene per il design di un sito, anche le sue prestazioni concorrono a una maggiore facilità di utilizzo. In questo senso, è bene differenziare due principali ambiti che possono avere impatto determinante sull’esperienza finale dell’utente: i tempi di caricamento della pagina e le performance di esecuzione della pagina stessa.

Per analizzare i tempi di caricamento e rendering della pagina web si possono utilizzare semplici strumenti online come Google PageSpeed, WebPagetest.org. Con questi strumenti, è possibile verificare problemi di immediata risoluzione, come l’utilizzo di immagini esageratamente grandi o poco ottimizzate, oppure calibrare altri fattori, come sfruttare al meglio il caching del browser o dare priorità ai contenuti immediatamente visibili.

Per ottenere invece informazioni più dettagliate riguardo eventuali inefficienze di codice a runtime, si può fare riferimento ai strumenti di analisi presenti sui principali browser, i quali possono dare indicazioni su eventuali problemi che avvengono durante la navigazione stessa di una singola pagina.

Nota

Chrome developer tools può inoltre fornire un’analisi approfondita di una pagina web nella sua sezione «Audits», permettendo di portare a galla problemi in ambito di progressive web apps, performance, accessibilità, e utilizzo di best practices.

In caso di progettazione di progressive web apps ideate per essere usate principalmente su dispositivi mobili, è bene tenere a mente anche il concetto di offline first, fornendo un’esperienza di base anche in caso di limitata connettività.

I Web Kit per lo sviluppo dell’interfaccia

Per avvicinarci alle esigenze di Pubbliche Amministrazioni e fornitori in questa fase, il progetto Designers Italia ha supportato la creazione di alcune librerie open source di ausilio per lo sviluppo di interfacce e il mantenimento di un design system solido e coerente: Bootstrap Italia, Web Toolkit, React Kit e Angular Kit, oltre ad alcuni strumenti dedicati alla realizzazione di siti web per comuni e scuole.

Bootstrap Italia è il principale punto di riferimento e il più moderno set di componenti disponibile per la costruzione di interfacce per servizi della PA, costruito sulle basi delle più recenti modifiche allo UI Kit e sulla libreria Bootstrap 4. Esso contiene codice HTML e CSS già pronto all’utilizzo per l’applicazione di tipografia, spaziature, design responsivo ed altri pattern di interfaccia conformi alle attuali Linee Guida. Bootstrap Italia recepisce le informazioni e i suggerimenti ricevuti e aggiorna il precedente Web Toolkit, secondo le nuove direttive introdotte nella più recente versione dello UI Kit e semplificando moltissimo lo sviluppo di un sito web conforme con le Linee Guida di Design.

React Kit e Angular Kit (in lavorazione) contengono componenti programmati in linguaggio JavaScript, costruiti rispettivamente sulle basi di React e AngularJS 6, due librerie open source per sviluppo di applicazioni web e mobile ad alta interattività e scambio di dati.

Sulle fondamenta della libreria Bootstrap Italia, sono stati inoltre creati degli strumenti in ausilio alla realizzazione di siti di comuni e scuole, secondo i ripettivi modelli, frutto di una corposa fase di ricerca con diverse tipologie di utenti ed impiegati:

Tali strumenti si concretizzano sotto forma di un tema WordPress per il modello di siti delle scuole, e di template HTML nel caso del modello per siti dei i comuni. Questi strumenti, oltre a fornire codice già pronto all’uso, implementano in modo puntuale l’architettura dell’informazione, l’organizzazione della navigazione e dei contenuti previsti dai modelli.

Bootstrap Italia

Bootstrap Italia contiene codice pronto all’uso, e descrive in dettaglio nella propria documentazione di progetto come iniziare ad utilizzare la libreria nel proprio sito, come aggiungere nuovi componenti, organizzare spazi e contenuti, ed altro ancora.

Esso permette di copiare frammenti di codice ed ottenere esattamente ciò che è mostrato nella documentazione del progetto, al cui interno sono presenti informazioni sull’utilizzo, componenti, esempi e progetti già realizzati grazie all’utilizzo della libreria.

Bottoni

Ad esempio, per aggiungere un bottone personalizzato è sufficiente aggiungere una classe .btn, associandola a classi di tipo .btn-* per applicarne varianti di stile, dimensione, ed altro.

È possibile consultare tutti i dettagli nella pagina dedicata al componente “Bottone” nella documentazione.

Un esempio del componente Bottone di Bootstrap Italia.

Un esempio del componente “Bottone” nelle sue varianti.

Interfaccia a Tab

Così come per i Bottoni, anche componenti più complessi come interfacce a “Tab” (o a “schede”), che mostrano il contenuto relativo al tab selezionato, possono essere realizzate semplicemente copiando il codice visibile nella documentazione di Bootstrap Italia, assicurandone così il funzionamento anche per utenti che usino la tastiera o dispositivi di comando vocale.

Un esempio del componente Tab di Bootstrap Italia.

Un esempio del componente “Tab” nelle sue varianti.

Input Toggle

Bootstrap Italia recepisce anche scelte di design su componenti che non esistono nello standard web, come l’input di tipo “Toggle” (una sorta di “interruttore” a due stati), un componente che si sostituisce al più usato “Checkbox” rendendone l’aspetto più chiaro ed immediato.

Un esempio del componente Toggle di Bootstrap Italia.

Un esempio di componente “Toggle” nelle sue varianti.

React Kit e Angular Kit

I kit React e Angular dipendono da Bootstrap Italia per quanto riguarda lo stile, ma espongono componenti già pronti all’utilizzo per applicazioni ad alta interattività basate su queste librerie. Entrambe le librerie sono disponibili come pacchetti npm, per cui gli sviluppatori React ed Angular troveranno codice già ottimizzato per essere incluso come dipendenza nelle loro applicazioni web.

Bottoni

A titolo di esempio, l’inclusione di un bottone di colore primario nei bordi, di piccola dimensione, e disabilitato sarà semplice come scrivere il codice che segue.

Per il React Kit:

<Button color="primary" size="sm" outline disabled>...</Button>

Per l’Angular Kit:

<it-button color="primary" size="sm" outline disabled>...</it-button>

La maggior parte di questi componenti prevedono già anche le funzionalità di ascolto e di modifica del proprio stato in base a valori impostati dinamicamente dall’esterno.

Gli strumenti

I Web Kit sono disponibili a tutti sui repository dedicati:

I kit seguono un processo di evoluzione e miglioramento continuo, e sono aggiornati secondo le regole del versionamento semantico.

Puoi verificare lo stato di avanzamento e la roadmap di ogni kit all’interno del repo GitHub che lo ospita o su Designers Italia. Tutti i progetti della Pubblica Amministrazione sono tenuti a contribuire, sempre utilizzando GitHub, segnalando componenti mancanti, suggerendo errori e mettendo a disposizione di tutti i componenti già realizzati.

Come contribuire ai Kit di Design

Queste linee guida sono superate

I riferimenti attuali sono:

Per approfondire

I modelli di design e i blocchi di codice presenti nel Wireframe Kit, nello UI Kit e nei Web Kit, proprio per la natura della loro utilità, hanno bisogno di evolversi in conseguenza dell’evoluzione della tecnologia, delle capacità di interazione degli utenti e dell’evoluzione del loro stesso obiettivo.

Per questo, essi sono tutti progetti open source che favoriscono il confronto e la collaborazione di chi vuole partecipare, non solo su tutto quanto è ancora in fase di realizzazione, ma anche su tutta la documentazione già pubblicata.

Si ritiene doveroso per la Pubblica Amministrazione, dovendo fornire dei servizi digitali accessibili ed usabili, interessarsi alle varie fasi dalla progettazione alla realizzazione, fornendo un proprio contributo all’implementazione e al miglioramento degli strumenti condivisi.

Strumenti di collaborazione

Per discussioni sul design è disponibile un canale dedicato su Forum Italia:

Per condividere informazioni, esperienze, fare domande in forma di chat, è possibile utilizzare la piattaforma Slack ufficiale di Developers Italia, dove è possibile trovare molti di coloro che stanno contribuendo attivamente ai progetti:

Per collaborare al design dei componenti o allo sviluppo, oppure per dare un feedback su quanto già realizzato, è possibile utilizzare le issue di Github.

Esse sono uno strumento di messaggistica molto simile alle email, che consiste in un messaggio pubblico su cui si può discutere con il resto del gruppo di lavoro. Ogni repository ha la propria sezione dedicata alle Issues: