Risultati
26 risultati
-
italia
4.3. Linguaggio
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. 4.3.5.1. 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. 4.3.5.2. 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. 4.3.5.3. 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. Pagine web in formato Html. Documenti in formato Pdf. File di testo in formato Odt. Fogli di calcolo in formato Ods. 4.3.5.4. 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 ...
-
italia
4.1. Architettura dell’informazione
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. 4.1.3.1. 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. 4.1.3.2. 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 ...
-
italia
4.2. SEO
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. 4.2.5.1. Approfondimenti. Come configurare un sito web in Search Console. Centro assistenza Search Console. Come collegare Search Console a Google Analytics. 4.2.5.2. 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 ...
-
italia
5.3. Web analytics
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). 5.3.8.1. Strumenti di web analytics: Matomo. Installazione e configurazione di Matomo/Piwik. Aggiungere un sito a Matomo/Piwik. Implementare il tracciamento del motore di ricerca interno al sito. Impostare un obiettivo. La segmentazione. Creazione ed invio di report customizzati. Importare dati da GA a Matomo/Piwik. 5.3.8.2. Strumenti di web analytics: Google Analytics. Configurazione di Google Analytics. Implementare il codice di tracciamento. Implementazione del codice per app. Implementare il tracciamento del motore di ricerca interno al sito. Collegare la Search Console a Google Analytics. Impostare un obiettivo. La segmentazione. Export ed invio via email dei dati ...
-
italia
5.1. 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. 5.1.6.1. 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. 5.1.6.2. Le fasi della procedura. Di seguito vengono descritte le diverse fasi nelle quali si articola la procedura:. Preparazione;. Esecuzione;. Analisi dei risultati. 5.1.6.3. 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. 5.1.6.3.1. 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. 5.1.6.3.1.1. 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. 5.1.6.3.1.2. 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. 5.1.6.3.1.3. 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. 5.1.6.3.2. Quanti e quali tipologie di partecipanti selezionare. 5.1.6.3.2.1. 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:. una quota più alta, rispetto al teorico 85%, di problemi frequenti;. un certo numero di problemi più rari. 5.1.6.3.2.2. 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:. Se ci si rivolge a una sola tipologia di utenti, è consigliato avere almeno 5 partecipanti;. Se ci si rivolge a più tipologie di utenti, è utile avere almeno 3-5 partecipanti in rappresentanza di ciascuna tipologia;. 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. 5.1.6.3.2.3. 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. 5.1.6.3.3. 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. 5.1.6.3.3.1. 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). 5.1.6.3.3.2. 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. 5.1.6.3.4. 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). 5.1.6.3.5. 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. 5.1.6.3.6. 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. 5.1.6.4. 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. 5.1.6.4.1. 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. 5.1.6.4.1.1. 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. 5.1.6.4.1.2. 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. 5.1.6.4.2. Interazione con i partecipanti e conduzione del test. 5.1.6.4.2.1. 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. 5.1.6.4.2.2. 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. 5.1.6.4.2.3. 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. 5.1.6.4.2.4. 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. 5.1.6.4.3. 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. 5.1.6.4.4. 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». 5.1.6.4.5. 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. 5.1.6.4.6. 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. 5.1.6.5. 3. Analisi dei risultati. In questa sezione si spiega come riassumere i dati raccolti e stilare un report. 5.1.6.5.1. 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:. il Net Promoter Score per il Net Promoter Score (NPS);. il Questionario SUS per il System Usability Scale (SUS);. le Domande UMUX Lite nel caso si sia usato lo Usability Metric for User Experience (UMUX-LITE). 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). 5.1.6.5.2. 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. 5.1.6.5.3. 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. 5.1.6.6. Check-list di riepilogo per l’organizzazione del test. 5.1.6.6.1. Fase 1. Effettuare prove preliminari sul sito mobile con alcuni tool per verificarne le funzionalità di base;. effettuare delle verifiche con metodi euristici per verificare lo stato attuale;. utilizzare i dati degli Analytics del sito per ottenere utili indicazioni sulla popolazione di riferimento e sui browser e dispositivi più utilizzati;. identificare la popolazione fra cui scegliere i partecipanti;. 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;. definire i task (gli stessi per tutti i partecipanti) da far svolgere ai partecipanti;. 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;. prendere appuntamento con i partecipanti. Nel caso di un ambiente strutturato organizzare una stanza dedicata dove approntare browser e software di registrazione;. svolgere un test pilota con un collega. 5.1.6.6.2. Fase 2. Ricevere uno a uno i partecipanti, somministrando i task, mentre un assistente si occupa della registrazione;. interagire con i partecipanti, influenzandoli il meno possibile;. annotare i task riusciti e quelli falliti;. annotare ogni problema, apparentemente incontrato dal partecipante, che si riesca a identificare;. 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;. somministrare inoltre il Net Promoter Score (NPS) per ottenere dati sull’intenzione d’uso;. dopo i questionari, chiacchierare con il partecipante, anche ritornando su punti critici ed errori incontrati, per valutare se a posteriori offra indicazioni utili;. 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;. per il successivo partecipante, ripartire dal punto 8 e così fino all’ultimo partecipante;. al termine di tutte le attività, raccogliere tutti i dati, per ciascun task e per ciascun partecipante nella Tabella dei risultati. 5.1.6.6.3. Fase 3. Riunire tutti i problemi annotati con tutti i partecipanti in un unico elenco, indicando quali e quanti partecipanti hanno incontrato ciascuno degli specifici problemi;. produrre il report riepilogativo, usando il Report dei risultati;. discutere in équipe risultati e singoli problemi incontrati, per valutare possibili azioni correttive. Se necessario, approfondire con un esperto ...
-
italia
5.2. Ricerche qualitative e quantitative
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. 5.2.1.1. 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. 5.2.1.2. 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. 5.2.1.3. 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 ...
-
italia
2.2. Gestione dei progetti
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 ...
-
italia
2.1. Principi di design dei servizi
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 ...
-
italia
2.4. Normativa
2.4.3.1. Accessibilità. 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. 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). Direttiva (UE) 2016/2021 del 26 ottobre 2016, relativa all’accessibilità dei siti web e delle applicazioni mobili degli enti pubblici. 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. 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. 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. 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). allegato A linee guida editoriali per i libri di testo. allegato B linee guida per l’accessibilità e la fruibilità del software didattico da parte degli alunni disabili. 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. 2.4.3.2. Trasparenza. 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». 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. 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». 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. 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». Determinazione ANAC n. 6/2015 Linee guida in materia di tutela del dipendente pubblico che segnala illeciti (c.d. whistleblower). 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». 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. 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). Delibera ANAC n. 1309 del 28/12/2016 Linee guida operative sull’attuazione dell’accesso civico generalizzato (FOIA), Esclusioni e Limiti. 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. 2.4.3.3. Privacy. Decreto legislativo 30 giugno 2003, n. 196 e ss.mm.i. Codice in materia di protezione dei dati personali (c.d. Codice della Privacy). 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. Individuazione delle modalità semplificate per l’informativa e l’acquisizione del consenso per l’uso dei cookie» dell’8 maggio 2014. 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). 2.4.3.4. 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):. Obbligatorietà della designazione del Responsabile della protezione dei dati (Data Protection Officer - DPO) per alcune tipologie di enti pubblici e privati (art.37). 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). Diritto alla cancellazione o diritto all’oblio (art. 17). Diritto alla portabilità dei dati (art. 20). Diritto di opposizione (art. 21). 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. 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). Protezione dei dati fin dalla progettazione e per impostazione predefinita (art.25). Predisposizione e la tenuta dei Registri delle attività di trattamento (art. 30). Sicurezza dei dati personali e la notifica dell’eventuale violazione dei dati (artt. 32-33). Valutazione d’impatto sulla protezione dei dati e l’eventuale consultazione preventiva con il Garante (artt. 35-36). 2.4.3.5. Comunicazione pubblica. Legge 7 giugno 2000, n. 150 Disciplina delle attività di informazione e di comunicazione delle pubbliche amministrazione ...
-
italia
2.3. Accessibilità
Sono disponibili ulteriori approfondimenti sull’accessibilità nella sezione FAQ predisposta sul sito dell’Agenzia per l’Italia digitale ...
-
italia
6.3. Lo sviluppo di un’interfaccia e i Web Kit
I Web Kit sono disponibili a tutti sui repository dedicati:. Bootstrap Italia. React Kit. Angular Kit (in lavorazione). Siti dei comuni: template HTML. Siti delle scuole: tema WordPress. 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 ...
-
italia
6.4. Come contribuire ai Kit di Design
Per discussioni sul design è disponibile un canale dedicato su Forum Italia:. Vai al canale dedicato alla User Interface. 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:. Vai allo Slack di Developers Italia. 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:. Pagina delle issue del Wireframe Kit. Pagina delle issue dello UI Kit. Pagina delle issue del Web Toolkit. Pagina delle issue di Bootstrap Italia. Pagina delle issue del React Kit e dell’Angular Kit ...