Usabilit

1
Usabilità dei Sistemi Interattivi

• Tiziana Catarci
• Dipartimento di Informatica e Sistemistica
• Università di Roma "La Sapienza
• catarci_at_dis.uniroma1.it

2
Sistema Interattivo

• Un sistema in cui avviene un continuo scambio di
  comunicazioni tra utente e strumento al fine di
  realizzare un compito.
• La facilità duso è un problema ben noto (non
  ristretto al software) avete mai provato a fare
  un versamento bancario con un terminale bancomat?
• Nel seguito si parlerà soltanto di usabilità del
  software, per chi fosse interessato agli altri
  strumenti Donald A. Norman, The Design of
  Everyday Things.

3
Indice

• Usabilità dei sistemi interattivi
• Definizioni
• Normative
• Progettazione User-centered
• Una Metodologia
• Usabilità e PA
• Caratteristiche Peculiari
• LEsperienza GLU
• Usabilità e WWW
• Regole di Progettazione
• Verificate lUsabilità del vostro Sito

4
Usabilità Definizioni

• La proprietà che riflette la facilità di impiego
  di un sistema informatico (1971)
• Linsieme delle seguenti caratteristiche
  effettività, apprendibilità, flessibilità e
  atteggiamento (1991)
• Linsieme delle seguenti caratteristiche
  facilità di apprendimento, efficienza
  nellimpiego, facile da ricordare, pochi errori,
  soggettivamente gradevole (1993)
• Il livello di efficacia, efficienza e
  soddisfazione da parte degli utenti raggiunto da
  un prodotto che venga utilizzato da specifici
  utenti per raggiungere determinati scopi in
  determinati ambienti (1993)
• Linsieme delle proprietà funzionali e non
  funzionali rilevanti ai fini della produttività e
  soddisfazione dellutente finale (1997)

5
Usabilità Altre Definizioni

• Usabilità ISO-9241_11 la capacità di un
  prodotto di agevolare uno specifico utente nel
  raggiungimento di specifici obiettivi con
  efficacia, efficienza e soddisfazione in uno
  specifico contesto duso
• Usabilità ISO-9126 la capacità del software di
  essere compreso, appreso, usato con soddisfazione
  dallutente in un determinato contesto duso

6
Altre Definizioni Utili

• Ergonomia insieme di principi, metodi e tecniche
  per la progettazione di sistemi di lavoro
  centrati sullutente
• Qualità del sw capacità intrinseca ed estrinseca
  del sistema sw di servire al raggiungimento dello
  scopo dellUtente e della sua Organizzazione

7
Altre Definizioni Utili(2)

• Utenti utenti diretti e indiretti che si trovano
  ad interagire con il sistema software
• Contesto dUso un insieme di condizioni reali e
  vincoli associati rilevabili e documentabili in
  cui lUtente interagisce con il sistema software
  per gli scopi suddetti
• Compito un insieme di operazioni svolte
  dallUtente in interazione con il sistema al fine
  di raggiungere uno scopo rilevante per lUtente e
  per la sua Organizzazione

8
Vantaggi

• Permette di focalizzarsi sui bisogni dellutente
  e della organizzazione
• Riduzione dei tempi di sviluppo
• Diminuzione del training necessario
• Aumenta la produttività
• Diminuzione degli errori dellutente
• Migliora la qualità dei prodotti
• Aumento di profilo di prodotti competitivi
• Diminuzione dei tempi e costi di manutenzione
• Migliora la qualità della vita
• Riduzione dello stress e aumento della
  soddisfazione dellutente
• Miglioramento dellambiente di lavoro
• Permette di rispettare le direttive europee

9
Usabilità e Progettazione

• Lusabilità misura la distanza tra il designer
  model, ovvero il modello del sistema informatico
  e delle sue modalità duso posseduto dal
  progettista, e lo user model, il modello di
  funzionamento del sistema che lutente si
  costruisce e che regola la sua interazione col
  sistema stesso.
• Quanto più i modelli sono vicini, tanto più il
  sistema è da considerarsi usabile.

10
La norma 9241_10

• Scopo
• illustrare i principi ergonomici da adottare per
  la progettazione e la valutazione di dialoghi
  utente-sistema
• Contenuto
• idoneità al compito
• autodescrittività
• controllabilità
• conformità alle aspettative
• tolleranza agli errori
• idoneità alla personalizzazione
• idoneità allapprendimento

11
Principio 1

• Idoneità al compito
• un dialogo utente-sistema è adatto al compito
  quando aiuta ad eseguirlo
• presentare solo le informazioni pertinenti alla
  particolare fase di esecuzione del compito
• progettare lHELP in modo da renderlo sempre
  pertinente alla fase di esecuzione del compito
• progettare le funzioni in modo da limitare
  lintervento dellutente
• progettare tenendo conto dellesperienza e della
  competenza dellutente

12
Principio 2

• Autodescrittività
• un dialogo utente-sistema è autodescrittivo
  quando è immediatamente comprensibile
• fornire sempre messaggi di conferma
• utilizzare sempre terminologia comprensibile
• fornire sempre spiegazioni pertinenti alla
  specifica fase di esecuzione del compito
• progettare la messaggistica in modo da evitare i
  continui ricorsi a materiale di supporto (help e
  manuali)
• fornire liste di valori di default

13
Principio 3

• Controllabilità
• un dialogo utente-sistema è controllabile quando
  lutente è in grado di scegliere in ogni punto e
  poter tornare indietro
• progettare il dialogo in modo che sia possibile
• ritornare sempre al punto di partenza
• annullare lultima operazione
• ritornare allultimo punto di scelta
• modificare il ritmo e la velocità di
  visualizzazione
• selezionare i dispositivi di inserimento/selezione
  /puntamento piu adeguati

14
Principio 4

• Conformità alle aspettative dellutente
• un dialogo utente-sistema è conforme se
  corrisponde alle caratteristiche (esperienza,
  conoscenza del dominio, etc.) degli utenti
• progettare il dialogo in modo da rendere
  consistenti i passi di dialogo anche tra sistemi
  diversi
• progettare le azioni necessarie allo svolgimento
  del dialogo in modo coerente

15
Principio 5

• Tolleranza agli errori
• un dialogo utente-sistema è tollerante agli
  errori se nonostante gli errori commessi il
  risultato puo essere raggiunto con poco sforzo
• fornire sempre la spiegazione degli errori
• progettare sempre al fine di evitare gli errori
  piu frequenti
• se il sistema è in grado di eliminare gli errori
  automaticamente, lasciare comunque sempre agli
  utenti la possibilità di rivedere il risultato

16
Principio 6

• Idoneità alla personalizzazione
• un dialogo utente-sistema è personalizzabile
  quando può essere modificato in base alle
  esigenze dellutente
• fornire sempre modalità di modifica di
  visualizzazione dei dettagli e/o del livello di
  AIUTO
• fornire se possibile comandi personalizzati
• fornire acceleratori e macro

17
Principio 7

• Idoneità allapprendimento
• un dialogo utente-sistema è idoneo
  allapprendimento quando guida lutente
  nellacquisizione delle modalità di utilizzo
• fornire supporto a diverse strategie di
  apprendimento (basato su testi, esercitazione,
  dimostrazioni, tutorial, etc...)
• fornire se possibile possibilità di accesso
  rapido a informazioni necessarie
  allapprendimento
• rendere disponibile allutente un insieme di
  strumenti coerenti per acquisire conoscenza

18
La norma ISO 9241_11

• La norma 9241_11 fornisce la guida per la
  valutazione dellusabilità di un sistema software
• Usabilità Qualità in Uso
• la misura in cui un prodotto sw (o una componente
  interattiva del sistema sw) viene utilizzato da
  specifici utenti per raggiungere specifici
  obiettivi con efficacia, efficienza e
  soddisfazione in uno specifico contesto duso

19
Definizioni

• Efficacia
• laccuratezza e la completezza con cui utenti del
  sistema raggiungono gli scopi per cui il sistema
  è stato progettato
• Efficienza
• il rapporto tra lefficacia dellinterazione e le
  risorse spese (tempo, lavoro, carta...) per
  raggiungere gli scopi
• il rapporto tra la qualità dei risultati
  raggiunti e le risorse fisico-mentali spese

20
Definizioni

• Soddisfazione
• misure oggettive stress e carico mentale tramite
  osservazione psico-fisiologica
• il comfort con cui lutente svolge i propri
  compiti e raggiunge gli scopi senza eccessivi
  carichi
• misure soggettive questionari di soddisfazione
  dellinterazione
• la piacevolezza e il benessere percepito
  dallutente durante lo svolgimento di compiti al
  fine di raggiungere scopi specifici

21
Il piano di valutazione

• I passi del piano
• identificare gli scopi del sistema ed
  eventualmente scomporli in attività (es. scrivere
  una lettera, utilizzare un correttore
  ortografico, etc..)
• identificare il contesto duso del sistema (es.
  utenti, compiti, vincoli organizzativi e di
  ambiente tecnologico, etc.)
• identificare dei valori/soglia di efficacia,
  efficienza e soddisfazione

22
La scelta delle misure

• Misure di efficacia
• esse sono legate agli scopi e alle attività
  previste per il sistema e misurano laccuratezza
  con cui il sistema permette di raggiungere gli
  scopi
• Es. se lo scopo è scrivere una lettera allora
  le misure possibili sono
• il NUMERO degli errori ortografici
• la selezione IN TEMPI BREVI del formato di stampa
  ottimale, etc..

23
La scelta delle misure (2)

• Misure di efficienza
• esse sono legate al consumo di risorse necessarie
  al raggiungimento degli scopi
• Es. se lo scopo è stampare un report allora le
  misure possibili sono
• il NUMERO delle copie stampate in una unità di
  tempo
• il RAPPORTO tra il numero complessivo delle
  copie stampate e il numero delle copie stampate
  correttamente
• il NUMERO delle copie stampate non valide

24
La scelta delle misure (3)

• Misure di soddisfazione
• esse sono legate al comfort e alla soddisfazione
  dellinterazione
• piacevolezza nelluso del sistema
• accettabilità del carico di lavoro mentale
• numero dei commenti negativi/positivi durante
  luso
• scale di soddisfazione legate a
• supporto allapprendimento
• efficienza globale
• supporto alla memorizzazione di passi specifici

25
User-centered Design

• A supporto della usabilità sono nate le tecniche
  di sviluppo human centered (od user centered)
  che si fondano su
• lattivo coinvolgimento degli utenti, al fine di
  ottenere una chiara identificazione dei requisiti
  utente, dei loro compiti e del contesto duso, ed
  una appropriata allocazione tra utente e sistema
  delle funzioni da sviluppare
• un processo iterativo di disegno della soluzione,
  che faccia uso per quanto più possibile di
  prototipi
• la presenza di competenze multidisciplinari nel
  team di progettazione.

26
Norma ISO 13407

• Obiettivi
• definizione dei requisiti di base per la
  certificazione dei processi di produzione del
  software centrato sullutente
• Contenuti
• definizione delle regole di documentazione del
  processo sul modello dell'ISO 9000
• Applicazioni
• per orientare il lavoro cooperativo e
  certificarlo
• relazione con lo standard IS12207

27
Human-centered Design (dalla 13407)

• Un approccio allo sviluppo di sistemi
  interattivi focalizzato specificatamente sul
  rendere il sistema usabile. E una attività
  multidisciplinare, che richiede competenze e
  tecniche specifiche di ergonomia. La applicazione
  di tali metodi e tecniche al disegno di sistemi
  interattivi ne aumenta la efficacia e la
  efficienza, migliora le condizioni di lavoro,
  contrasta possibili efffetti nocivi sulla salute
  dei lavoratori, sulla sicurezza e sulle
  prestazioni. Applicare la ergonomia al disegno di
  sistemi richiede di considerare fattori primari
  le capacità competenze, conoscenze, limitazioni
  ed esigenze degli utenti.

28
I Principi della norma

• Principi di progettazione centrata sullutente
• coinvolgimento attivo degli utenti
• comprensione dei requisiti degli utenti e dei
  compiti
• allocazione appropriata di funzioni tra gli
  utenti e il sistema
• iterazione delle soluzioni di progettazione
  (prototipi)
• progettazione multi-disciplinare

29
Il Ciclo di Sviluppo
30
Il Contesto dUso

• E un documento che contiene
• caratteristiche degli utenti
• caratteristiche dei compiti e allocazione di
  attività tra utenti e sistema
• vincoli socio-organizzativi e di ambiente
  tecnologico
• Il documento viene
• validato dagli utenti
• rivisto ciclicamente
• influenza la progettazione

31
I requisiti utente e organizzativi

• E un documento che contiene
• la descrizione approfondita degli scopi del
  sistema
• stabilisce la priorità tra i diversi requisiti
  (che possono anche essere in conflitto)
• include eventuali requisiti di legge
• stabilisce gli obiettivi di usabilità che
  guideranno la successiva valutazione
• Viene validato dagli utenti

32
Le soluzioni di progettazione

• produrre diverse soluzioni (multi-disciplinari)
  in uno spazio di soluzioni
• utilizzare simulazioni, mock-up e prototipi e
  documentarne levoluzione
• coinvolgere gli utenti anticipatamente in modo da
  esplorare e validare le scelte
• iterare le soluzioni fino ad arrivare a quella
  ottimale (best-fit)

33
Valutare le soluzioni

• La valutazione delle scelte di progettazione è
  cruciale!
• stilare un piano di valutazione
• effettuare una valutazione durante tutte le fasi
  del ciclo di vita del sistema (con o senza
  utenti)
• identificare le anomalie e i difetti più
  rilevanti
• selezionare la soluzione di progetto migliore
  rispetto ai requisiti

34
I criteri di valutazione

• selezione dei metodi appropriati per il
  particolare stato di sviluppo del sistema
• Analitici vs. Empirici
• basati su esperti
• orientati alla applicazione di linee guida
  generali
• orientati alla verifica di conformità a standard
• basati su utenti
• orientati alla raccolta di feedback anticipato
• orientati alla esecuzione controllata di compiti
• documentazione delle procedure e dei risultati
  della valutazione

35
Metodi basati sugli Utenti

• User testing con utenti reali, attraverso
  esperimenti controllati effettuati in laboratori
  di usabilità
• Osservazione diretta
• Questionari e interviste
• Focus Groups
• Analisi dei files di log
• Feedback
• Misurazione delle performances del sistema
• Thinking aloud

36
Quanti Utenti?

• 4 o 5 utenti rappresentativi sono in grado di
  scoprire l80 dei principali problemi di
  usabilità di un prodotto 10 utenti fino al 90
  (Nielsen 2000)

37
Metodi basati su eperti

• Valutazione euristica (ispezione sistematica del
  progetto dellinterfaccia utente per verificarne
  lusabilità)
• Pluralistic usability walkthrough

38
Sommario dei Metodi
(da J. Nielsen, Usability Engineering, 1993)
39
Valutazione Analitica

• Permette di effettuare previsioni su alcuni
  aspetti parziali dell'usabilità di un sistema
  prima che il primo prototipo del sistema stesso
  venga realizzato. È un metodo basato sul
  costruire un modello formale del sistema che
  permette di predire, per esempio, il tempo
  necessario ad un utente esperto ad effettuare un
  certo compito senza errori. Purtroppo, l'utilizzo
  di questo metodo, oltre a richiedere l'intervento
  di un esperto che costruisca il modello formale,
  porta a risultati marginali e non tiene conto del
  contesto d'uso del sistema.

40
Valutazione Euristica

• Sfrutta la conoscenza di un esperto nel campo
  della interazione uomo-macchina per effettuare
  previsioni sull'usabilità del sistema a partire
  da un prototipo che può essere anche cartaceo
  (cioè che simuli sulla carta possibili schermate
  del sistema). Il maggior difetto di questo
  metodo, che pure offre il vantaggio di una
  analisi approfondita dei fattori che determinano
  l'usabilità del sistema, è quello di dipendere
  dal giudizio di un singolo esperto, che non è
  comunque l'utente finale.

41
Osservazione Diretta

• Coinvolge utenti reali che vengono osservati
  durante l'interazione con il sistema. Per questo
  motivo può essere utilizzato solo quando un reale
  prototipo del sistema è stato prodotto. Inoltre,
  è preferibile non osservare direttamente le
  persone che interagiscono con il sistema, ma
  filmarle ed analizzare il film. Questo permette
  di evidenziare i punti critici dell'interazione.
  L'aspetto più costoso di questo metodo è
  costituito dal tempo necessario ad analizzare i
  filmati sugli utenti. Per ovviare a questo
  inconveniente sono stati approntati degli
  strumenti software che aiutano nell'analisi dei
  filmati.

42
Questionari/Interviste

• È basato sull'analisi delle opinioni,
  aspettative, reazioni, ecc. degli utenti, che
  vengono estesamente consultati tramite
  questionari ed interviste. I questionari possono
  essere usati in più fasi dello sviluppo del
  progetto, sia inizialmente, seguendo i criteri
  descritti nella sezione precedente per definire
  le prime linee di progetto del sistema, sia nelle
  varie fasi di sviluppo del prodotto per testare
  le reazioni degli utenti. È essenziale progettare
  correttamente i questionari e le domande da porre
  agli utenti nel corso delle interviste. Una volta
  che ciò sia stato fatto, è possibile effettuare
  una valutazione affidabile dell'usabilità del
  sistema. In particolare, per le fasi finali della
  valutazione esistono degli strumenti software che
  forniscono un ausilio nella progettazione dei
  questionari e nella valutazione della
  soddisfazione dell'utente in base alle risposte
  alle varie domande.

43
Esperimenti Controllati

• È particolarmente valido per verificare
  lusabilità di un sistema in tutte le fasi del
  ciclo di vita. Inoltre, permette di verificare se
  un cambiamento nel progetto del sistema possa
  inficiarne l'usabilità. Permette sia di
  effettuare un test sull'usabilità dell'intero
  sistema, che di confrontare diverse scelte
  progettuali locali. In questultimo caso, è
  preferibile applicarlo una volta che siano
  disponibili prototipi che presentano le varie
  alternative, ed è molto importante che tutti i
  prototipi differiscano esclusivamente
  nell'aspetto da scegliere.

44
Una Metodologia di Progetto
45
Passi e Obiettivi di Ogni Fase

• Analisi dell'applicazione e dell'utenza
• Obiettivi Locali produrre un documento che
  descriva le caratteristiche dell'applicazione,
  degli utenti e del contesto in cui si svolge il
  lavoro.
• Input non c'è un input preciso in questa fase
  preliminare, ciò che si deve fare è osservare gli
  utenti nel loro luogo di lavoro ed applicare le
  tecniche di indagine.
• Approccio in questa fase viene applicato il
  metodo basato su indagine.
• Output il documento che descrive le tipologie di
  utenza e le caratteristiche dell'applicazione
  (DOC-UT).
• Criteri di qualità il documento deve essere
  verificato da rappresentanti degli utenti,
  esperti e progettisti finché non viene
  unanimamente considerato completo e consistente.

46
Identificazione Obiettivi di Usabilità

• Obiettivi Locali dopo aver analizzato i
  risultati della fase precedente, il team di
  analisi (TA) stabilisce precisamente le
  caratteristiche che deve avere il prodotto
  finale, in particolare rispetto all'usabilità.
• Input l'output della fase precedente.
• Approccio gli obiettivi devono essere
  identificati attraverso un'analisi della
  situazione condotta dal TA.
• Output un documento che descriva le
  caratteristiche che deve avere il prodotto
  finale.
• Criteri di qualità il TA deve verificare
  attraverso una verifica con gli utenti finali che
  le caratteristiche evidenziate per il prodotto
  soddisfino completamente le esigenze di tali
  utenti.

47
I generazione prototipi

• Obiettivi Locali ottenere commenti precisi dagli
  utenti sulla prima generazione di prototipi.
• Input l'output della fase precedente ed una
  prima generazione di prototipi (anche soltanto su
  carta) prodotti dai progettisti.
• Approccio i prototipi vengono mostrati ai
  rappresentanti degli utenti per raccogliere le
  loro reazioni, inoltre viene sottoposto agli
  utenti anche un questionario con domande precise
  sui punti critici del prototipo. Si può
  richiedere l'apporto di un esperto per una
  ulteriore valutazione dei prototipi.
• Output un primo documento, scritto dai
  rappresentanti degli utenti, che raccoglie i
  commenti degli utenti sui prototipi un secondo
  documento, scritto dai progettisti ed approvato
  dal TA, che analizza il contenuto del primo e
  propone le conseguenti modifiche ai prototipi.
  Inoltre, si potrà avere un raffinamento del
  documento DOC-UT.
• Criteri di qualità il TA deve verificare sia che
  il documento prodotto dagli utenti copra la
  verifica di tutte le caratteristiche del sistema,
  sia che il prototipo sia consistente con gli
  obiettivi di usabilità identificati nella fase
  precedente.

48
II generazione prototipi

• Obiettivi Locali ottenere commenti precisi dagli
  utenti sulla seconda generazione di prototipi.
• Input i documenti prodotti nella fase
  precedente la II generazione di prototipi (che
  prevedono diverse possibilità alternative per
  alcune funzionalità), non più su carta ma reali.
• Approccio i prototipi devono essere mostrati a
  gruppi di utenti (non solo ai loro
  rappresentanti). La valutazione dei prototipi
  deve essere condotta con vari metodi indagine,
  supporto di esperti, esperimenti controllati e,
  se possibile, anche con l'osservazione diretta.
• Output un primo documento, scritto dai
  rappresentanti degli utenti, che raccoglie i
  commenti degli utenti sui prototipi un secondo
  documento, scritto dai progettisti ed approvato
  dal TA, che analizza il contenuto del primo e
  propone le conseguenti modifiche ai prototipi.
  Inoltre, si potrà avere un raffinamento del
  documento DOC-UT.
• Criteri di qualità il TA deve verificare sia che
  il documento prodotto dagli utenti copra la
  verifica di tutte le caratteristiche del sistema,
  sia che il prototipo sia consistente con gli
  obiettivi di usabilità descritti in DOC-UT.

49
Prototipo completo

• Obiettivi Locali ottenere commenti precisi
  dagli utenti sul prototipo completo. Se il
  progetto è stato portato avanti per raffinamenti
  successivi, seguendo questa metodologia, i
  cambiamenti da apportare in questa fase
  dovrebbero essere esigui.
• Input i documenti prodotti nella fase
  precedente un prototipo completo del sistema.
• Approccio il prototipo completo devono essere
  mostrato a gruppi di utenti. Per alcune
  funzionalità è possibile anche in questa fase
  proporre più alternative. La valutazione del
  prototipo deve essere condotta con vari metodi
  indagine, supporto di esperti, esperimenti
  controllati e, se possibile, anche con
  l'osservazione diretta.
• Output un primo documento, scritto dai
  rappresentanti degli utenti, che raccoglie i
  commenti degli utenti sul prototipo un secondo
  documento, scritto dai progettisti ed approvato
  dal GV, che analizza il contenuto del primo e
  propone le conseguenti modifiche al prototipo.
• Criteri di qualità il GV deve verificare sia che
  il documento prodotto dagli utenti copra la
  verifica di tutte le caratteristiche del sistema,
  sia che il prototipo sia consistente con gli
  obiettivi di usabilità descritti in DOC-UT.

50
Prodotto

• Obiettivi Locali validare il prodotto finale
  nell'ambiente reale di lavoro, allo scopo di
  ottenere commenti dagli utenti finali
  utilizzabili per migliorare le versioni
  successive.
• Input i documenti prodotti nella fase
  precedente il sistema reale.
• Approccio una volta che il prodotto è realmente
  disponibile inizia la sua sperimentazione presso
  grandi gruppi di utenti. La maniera più semplice
  ed economica per effettuare tale sperimentazione
  è sottoporre agli utenti dei questionari ed
  analizzare le risposte. Altre possibilità sono
  offerte, per esempio, da un monitoraggio
  indiretto, basato su un sistema automatico di
  supporto che memorizza ed analizza le fasi
  salienti dell'interazione.
• Output un documento, scritto dai rappresentanti
  degli utenti, che raccoglie i commenti degli
  utenti sul prototipo un raffinamento del
  documento DOC-UT.
• Criteri di qualità il TA deve verificare che gli
  obiettivi originari del progetto siano stati
  conseguiti. Al termine di un periodo di prova, il
  TA, se necessario, produce un documento finale in
  cui vengono indicate le possibili migliorie da
  effettuare nelle versioni successive.

51
Usabilità e PA
52
Usabilità e PA

• Grande varietà e quantità di utenti
• operatori dei vari settori P.A.
• cittadini
• portatori di handicaps
• Mancanza di una specifica preparazione tecnica da
  parte dellutenza
• Varietà di applicazioni, da generiche ad
  altamente specialistiche
• Informatizzazione dei processi amministrativi,
  nuove tecnologie e strumenti informatici
• Es. RUPA, SIU
• Necessità di valutare gli strumenti informatici
  prodotti dai vari fornitori
• Desiderata
• trasparenza degli atti
• diritto allinformazione
• disponibilità dei servizi
• qualità dellinformazione

53
PA Software
54
Investimenti PA in Sviluppo SW vs. Management
Maintenance
55
Disctribuzione Costi Manutenzione e Gestione SW
56
Accessibilita dei Sistemi SW nella PA
57
Qualita dei SI nella PA (1999)
58
Esperienza GLU

• Gruppo di lavoro sullusabilita dei sistemi
  interattivi della PA, formalizzato dallAIPA con
  deliberazione N. 53 del 22 Ottobre 1997.
• Obiettivi
• Definizione delle linee guida per la stesura di
  studi di fattibilità che includano lusabilità
  come parametro essenziale in termini di costi,
  benefici e rischi connessi alla produzione di
  sistemi informatici con una significativa
  componente interattiva.
• Conduzione di una sperimentazione con il fine di
  individuare le linee guida per la definizione di
  un sistema usabile nella Pubblica
  Amministrazione.
• Attività
• Redazione di un documento introduttivo
  sullusabilità.
• Redazione di un primo documento che delinea le
  caratteristiche di un generico sistema usabile
  nellambito della P.A.
• Sperimentazione di strumenti sw per la P.A.
• Ministero di Grazia e Giustizia (sistema per
  reperire informazioni necessarie a creare
  documenti)
• Ministero delle Finanze (sistema per
  reperire/scambiare informazioni tra vari uffici,
  per diversi scopi)

59
Sperimentazioni

• Obiettivi dellanalisi
• Modalità di lavoro del team di progettazione
• Modalità di partecipazione degli utenti PA alle
  varie attività di progettazione
• Valutazione degli utenti riguardo lusabilità dei
  prodotti
• Metodologia utilizzata
• Interviste al team di progettazione
• Interviste agli utenti finali (dopo un test di
  utilizzo del prodotto)
• Lezioni apprese
• Usabilità Costo
• Carenze culturali e metodologiche
• Carenze organizzative
• Desiderio di partecipazione da parte dellutenza

60
Problemi Rilevati

• Carenze Organizzativo/Contrattuali
• Chi commissiona il prodotto non ne sarà lutente
  finale
• Chi effettua i collaudi non è lutente finale
• Il coinvolgimento degli utenti non è richiesto o
  regolato da contratti
• Nei Piani di qualità non è citata lusabilità
• I collaudi riguardano la funzionalità e
  laffidabilità
• La soddisfazione dellutente non è mai rilevata
• Le griglie di aggiudicazione non premiano
  lusabilità
• Carenze Metodologico/Culturali
• Mancanza di una formazione adeguata
• Processi di sviluppo che in genere non sono
  user-centered, non analizzano il contesto e le
  esigenze degli utenti
• Mancanza di competenze interdisciplinari nei team
  di sviluppo
• Scarso coinvolgimento dellutente, soprattutto
  nelle fasi iniziali del progetto

61
Progettazione User-centered
1. Pianificare un progetto orientato allutente
Il progetto soddisfa i requisiti
2. Specificare il contesto duso
5. Valutare il progetto rispetto ai requisiti
utente
3. Specificare i requisiti utente e
dellorganizzazione
4. Produrre le soluzioni progettuali
62
Specificare il contesto duso
ATTIVITÀ Determinare le caratteristiche
dellutenza Identificare i compiti che gli
utenti devono svolgere con il sistema. Caratteriz
zare lambiente in cui il sistema sarà usato
PROBLEMI Scarsa rappresentatività dellutenza
coinvolta nel progetto I compiti sono analizzati
separatamente, assenza di workflow, mancanza di
flessibilità dei sistemi prodotti Ignorato
63
Specificare i requisiti di utenza e organizzazione
ATTIVITÀ Analizzare le prestazioni del sistema
rispetto agli obiettivi operazionali e
finanziari Identificare benchmarks per testare il
progetto Progettare il workflow e
lorganizzazione del lavoro Analizzare le
performance rispetto ai compiti Considerare i
cambiamenti nellorganizzazione del lavoro
PROBLEMI Ignorato Ignorato Impatto
sullorganizzazione del lavoro in genere
sottostimato Ignorato Scarsi programmi di
formazione o riqualificazione
64
Produrre le Soluzioni
ATTIVITÀ Formare team di lavoro con competenze
multi-disciplinari Usare simulazioni, mock-ups,
prototipi Mostrare le soluzioni allutenza e
simulare le attività Utilizzare il feedback degli
utenti per miglorare il progetto Procedere
iterativamente
PROBLEMI Team di lavoro senza competenze
multi-disciplinari Assenza di prototipi su carta,
il sistema è spesso il primo prototipo Pochi
incontri con lutenza Scarsa attenzione ai
suggerimenti degli utenti Poca iterazione nel
processo di progettazione
65
Valutare il Progetto
ATTIVITÀ Produrre piani di valutazione Analizzar
e i risultati dei test Verificare il
raggiungimento degli obiettivi
PROBLEMI La valutazione non è progettata
accuratamente ma lasciata alla sensibilità del
progettista Le tecniche per le analisi di
usabilità sono spesso sconosciute ai
progettisti Mancanza di un piano di qualità
66
Possibili Cause

• Persistenza di vincoli tecnologici ed
  applicazioni obsolete
• Scarso ritorno per i fornitori rispetto ad
  eventuali costi sostenuti per migliorare
  lusabilità dei prodotti
• Mancanza di conoscenza su metodologie di sviluppo
  avanzate user-centered
• Mancanza di percorsi formativi adeguati
• Scarsa attenzione dei committenti a problematiche
  legate allusabilità
• Scarso coinvolgimento e responsabilizzazione
  dellutente finale nel processo di progettazione
  del prodotto

67
Possibili Interventi

• Requisito di usabilità inserito negli studi di
  fattibilità
• Premiare la qualità nelle gare dappalto,
  adottando criteri di giudizio che tengano conto
  dellutente (progettazione user-centered, test di
  usabilità, rilevamento della soddisfazione
  dellutente)
• Formare lutenza
• Prevedere il monitoraggio della usabilità e
  leventuale miglioramento del prodotto
  nellambito delle procedure di assistenza e
  manutenzione dopo il rilascio
• Inserire la valutazione di usabilità nellambito
  del monitoraggio

68
Usabilità e WWW
69
Caratteristiche Utente/WWW

• Accesso navigazionale allinformazione
• Estrazione dellinformazione (compito spesso
  arduo)
• Progetto e manutenzione del sito
• Lutente controlla la navigazione
• Utenza enorme e variegata
• Impatto sociale del Web

70
Trovare lInformazione...

• Difficile trovare linformazione di interesse
• Disorientamento
• Sovraccarico cognitivo
• Problema del profumo (scent problem)
• Mancanza di guida
• Scarsa history

• Informazione spezzettata e dispersa
• Dati di tipi e formati diversi

71
Quando un Sito è Usabile?

• Dipende dallattività che lutente vuole svolgere
  (e.g., surfing, cercare informazioni, comprare
  prodotti...)
• Essenziale permettere allutente di trovare,
  comprendere ed usare le informazioni di interesse
• Contenuto informativo
• Organizzazione dellinformazione
• Struttura della navigazione
• Usabilità del sito struttura dellinformazione
  navigazione e ricerca links progetti
  differenziati per diversi utenti consistenza di
  stile e presentazione templates layout e
  grafica.
• Usabilità della pagina comprensibilità di
  intestazioni, links e spiegazioni messaggi di
  errore chiari filtraggio delle informazioni non
  essenziali grafica.

72
Regole Generali per lUsabilità del Web

• Navigazione e contenuto sono inseparabili. La
  grafica sofisticata non risolve i problemi di
  usabilità, anzi spesso ne crea di nuovi.
• La ricerca di informazioni è diversa dal
  surfing
• I link devono essere testuali
• Testare lusabilità di un sito è diverso dal
  testare software generico.

73
Home page di SERCO cosa fa questa società?
74
Un purificatore di acqua non ha taglia o
colore Lorder form è troppo aggressiva per
lutente
75
Navigazione

• È invisibile quando funziona
• Quando gli utenti non hanno familiarità con il
  dominio non riconoscono le diverse opzioni che
  vengono loro presentate
• Gli utenti generalmente non si formano un modello
  mentale del sito
• Non ci si può basare semplicemente sulla presenza
  di strumenti di navigazione
• frames
• table of contents
• navigation bars
• hierarchical maps
• you are here
• site maps

76
Links

• Strettamente legati alla navigazione
• Navigazione -gt Struttura del sito
• Links -gt Meccanismi per muoversi
• Il successo di un link dipende da
• Chiarezza della destinazione del link
• Differenziazione tra link vicini e/o simili
• La selezione di un link dipende dallaspettativa
  della pagina di arrivo.
• Evitare link ambigui, immersi nel testo, iconici,
  non informativi.

77
Link non informativi
Quale è la current issue? Su quale argomento?
78
Link informativi, con un corretto layout
79
Qui ci sono link bianchi su fondo bianco
80
Ricerca Interna al Sito

• Due problemi per gli utenti
• Non comprendono lo spazio di ricerca
• Hanno problemi nellinterpretazione dei risultati
• Aree di ricerca confuse
• Mancanza di organizzazione nel risultato
• Se è organizzato, perchè in quel modo?
• Informazioni insufficienti sui link restituiti
  come risultato
• Informazioni ridondanti
• Informazioni inutili

81
Uso del linguaggio naturale(la query era Who
does sell Ferrari in Rhode Island?) Ma il primo
link porta ad un venditore di auto che non ha
Ferrari
82
Leggibilità e Layout della Pagina

• Gli utenti non leggono il testo di una pagina
  Web, lo scorrono per trovare qualcosa che somigli
  a quello che cercano
• La leggibilità è diversa che per i testi
  tradizionali
• Rapporto spazio bianco e testo
• Scrolling
• Posizione dei bottoni

83
Uso dello spazio
Sistema Operativo
Pubblicità
Informazioni Utili
Navigazione nel sito
Spazio sprecato
84
Qualè lo scopo di questo sito?
Meccanismo importante
Meccanismo utile per pochi utenti
85
Grafica

• Non e uno dei fattori chiave per lusabilità di
  un sito
• Importante cambiamento di colore dei link
  visitati
• Problema Tempo di Download
• Animazione e movimento spesso distraggono e sono
  controproducenti

86
Quale è il significato di questa metafora? Questa
metafora aumenta lusabilità del sito?
87
Test di Usabilità per il Vostro Sito

• Tipi di domande
• Fatti (e.g., sito immobiliare Si può trovare una
  casa con 3 camere da letto per meno di 600Mil. a
  Roma?)
• Confronto di fatti (e.g., sito agenzia viaggi da
  Roma costa di meno volare a Zurigo o a Losanna?)
• Decisione (e.g., sito del Giubileo una persona
  con handicap motori riuscirà a recarsi nei luoghi
  dei maggiori eventi giubilari?)
• Confronto di decisioni (e.g., sito spettacoli
  Londra quale potrebbe essere lo spettacolo più
  adatto dove andare con una mia nipote di cinque
  anni?)

88
Riferimenti

• N. Bevan, M. Macleod. Usability Assessment and
  Measurement. In The Management of Software
  Quality (M. Kelly, ed.), Ashgate Technical/Gower
  Press, 1993.
• N.Bevan. Measuring Usability as quality of use.
  Journal of sw quality, 4, 115-130, 1995.
• R.G.Bias, D.G.Mayhew. Cost-justifying Usability.
  Academic Press, 1994.
• T. Catarci. Web-based Information Access. In
  Proc. CoopIS'99, 1999.
• T.Catarci, G. Matarazzo, G. Raiss. La usabilità
  nei sistemi informatici della PA. Aspetti teorici
  e studi di caso. (A cura del Gruppo Lavoro
  Usabilità). AIPA Report, 1999.
• J. Dix al. Human Computer Interaction. Prentice
  Hall, 1998.
• D.J.MayHew. Usability Engineering LifeCycl.
  Morgan Kaufmann Publishers, 1999.
• J.Nielsen. Usability engineering. Academic Press,
  1993.
• J.Nielsen. Designing Web Usability. New Riders
  Pub., 1999.
• B. Shneiderman. Designing the User Interface
  Strategies for Effective Human-Computer
  Interaction. Addison Wesley Pub, 1997.
• J.M.Spool, T.Scanlon , W. Schroeder, C. Snyder,
  T. DeAngelo. Web Site Usability A Designer's
  Guide. Morgan Kaufmann, 1999.