Appunti teoria Sistemi informativi

Efficacia viene definita come la accuratezza e completezza con cui gli utenti

 raggiungono specificati obbiettivi. Essa considera pertanto il “livello di precisione” con

cui l’utente riesce a raggiungere i suoi scopi, misurato in qualche modo numericamente.

Efficienza definita come “la quantità di risorse spese in relazione all'accuratezza e alla

 completezza con cui gli utenti raggiungono gli obiettivi”. Tali risorse potranno essere di

natura differente secondo le situazioni, e potranno anch’esse essere quantificate

Soddisfazione, infine, è definita – in modo in effetti un po’ contorto - come “la libertà

 dal disagio e l’attitudine positiva verso l’uso del prodotto”

Memorability (“memorizzabilità”) Ogni sistema dovrebbe essere facile da ricordare, in

 modo che l’utente occasionale possa tornare a usarlo dopo qualche tempo senza

bisogno consultare il manuale facile da ricordare (per utenti occasionali)

Learnability Ogni sistema dovrebbe permettere all’utente principiante di imparare ad

 utilizzarne almeno le funzioni base senza necessità di addestramento

Vengono introdotti dei sussidi per l’utente per rendere più semplice l’utilizzo del prodotto

(Guide in linea, FAQ…)

Vicino al concetto di usabilità c’è quello di Accessibilità che descrive la capacità di un prodotto

di essere adatto anche a utenti con disabilità. L’accessibilità dà quindi spazio alle tecnologie

assistive come le tastiere Braille e i lettori di schermo.

Progettare l’usabilità

1. Ridurre l’ampiezza del golfo dell’esecuzione (fare in modo che le azioni possibili

corrispondano in modo

evidente alle intenzioni) -> “affordance” → a proprietà di un oggetto d’influenzare, attraverso

la sua

apparenza visiva, il modo in cui deve essere usato

2. Facilitare l’esecuzione delle “azioni”

3. Ridurre l’ampiezza del golfo della valutazione (fare in modo che lo stato fisico del sistema sia

interpretabile in modo univoco e immediato) -> “feedback” → La risposta che otteniamo a

seguito delle

nostre azioni

Lez.4-5

I casi d’uso

La nozione di caso d’uso, richiamata nella sezione precedente senza definirla, è di grande

importanza nella

progettazione human-centred, e merita un approfondimento. In termini del tutto generali, un

caso d’uso può essere

definito come un insieme d’interazioni fra l’utente (o più utenti) e il sistema, finalizzate a uno

scopo utile per l’utente.

Non bisogna confondere i casi d’uso con le funzionalità del sistema. In un caso d’uso, il

soggetto è l’utente.

Progettazione dei casi d’uso:

Identificare l'utente (chi è? quali caratteristiche?)

Identificare i bisogni (espressi /inespressi) (che cosa gli serve? perché?)

Identificare il contesto d'uso (dove? quando? in che situazione?)

Identificare i casi d'uso

Descrivere i casi d’uso (in termini di attività più semplici)

Estensione di un caso d’uso è una variante non obbligatoria del caso d’uso.

Inclusione di un caso d’uso è una variante obbligatoria del caso d’uso.

Scenari d’uso

Storie immaginarie d’uso del sistema da parte di persone fittizie, ma concrete, che

rappresentano bisogni, contesti e modalità d’uso tipiche del sistema da progettare

(“personae”)

Gli scenari "mettono in scena" una serie di casi d'uso, collocandoli nel contesto:

• Contesto, concretezza, visione oggettiva

requisiti inespressi

• Mettono in evidenza

Lez.6

Dal documento dei requisiti al design concept

Mimesi

Una tecnica frequente consiste nel progettare oggetti virtuali (cioè realizzati via software), che

riproducono in ogni dettaglio oggetti reali ben noti. Nell’era dell’informatica molti oggetti

vivono, per così dire, due vite: una vita fisica, nel mondo reale, e una vita sullo schermo del

computer.

Ibridazione(MEALY, abbiamo unito app per fitness con app per gestione

dell’alimentazione)

Concepire un oggetto nuovo mescolando e integrando fra loro aspetti e funzioni di più oggetti

diversi.

Metafora

Un chiaro esempio di metafora sono le icone che vediamo in tutti i programmi di utilizzo

comune, senza etichetta. Queste devono rappresentare lo scopo del tasto attraverso

l’immagine che lo descrive e qui arriva anche il contro di questa tecnica: Icone poco esplicative

possono confondere l’utente.

Variazione

La variazione è uno dei procedimenti più frequenti nella progettazione. Una quota rilevante del

lavoro del

designer consiste nel progettare variazioni, in qualche senso migliorative, di sistemi esistenti.

Queste potranno generare

prodotti concorrenti di quelli originali, o nuove versioni evolutive degli stessi.

Un chiaro esempio di questa tecnica è l’evoluzione che ha avuto windows negli anni, piccole

modifiche grafiche ci hanno portato da un’interfaccia a linea di comando all’attuale windows

11.

Design Patterns

Non si tratta di copiare ciò che altri hanno concepito, ma di far tesoro dell’esperienza

sviluppata in altri progetti, e di svilupparla ulteriormente adattandola a nuovi contesti. Molte

pattern

soluzioni progettuali hanno una struttura o, come si dice, un - comune, che poi

design

s’incarna e si specializza in diversi ambiti applicativi. Più precisamente, con il termine

pattern si indica una soluzione generale a un problema di progettazione che si ripropone in

molte situazioni, anche diverse fra loro. Non una soluzione “finita”, ma piuttosto un modello, un

template da adattare allo specifico contesto.

Lez.7

Tecniche di valutazione con Esperti di usabilità

Il sistema viene esaminato verificandone la conformità a specifiche “regole d’oro” (dette,

appunto, “euristiche”), derivanti da principi e linee guida generalmente accettati.

Le euristiche possono essere diverse, più o meno dettagliate.

Si preferiscono euristiche costituite da pochi principi molto generali, piuttosto che linee guida

dettagliate, di difficile utilizzo.

Le 10 euristiche di Nielsen:

1. Visibilità dello stato del sistema(Es. Dialog box)

Il sistema dovrebbe sempre informare gli utenti su ciò che sta accadendo, mediante feedback

appropriati in un

tempo ragionevole.

2. Corrispondenza fra il mondo reale e il sistema(Es. cursore a forma di mano)

Il sistema dovrebbe parlare il linguaggio dell’utente, con parole, frasi e concetti familiari

all’utente, piuttosto che

termini orientati al sistema.

3. Libertà e controllo da parte degli utenti(Es. tasto indietro per annullare l’operazione)

Gli utenti spesso selezionano delle funzioni del sistema per errore e hanno bisogno di una

“uscita di emergenza”

segnalata con chiarezza per uscire da uno stato non desiderato senza dover passare attraverso

un lungo dialogo.

Fornire all’utente le funzioni di undo e redo.

4. Consistenza e standard(Es. Differenziare le icone)

Gli utenti non dovrebbero aver bisogno di chiedersi se parole, situazioni o azioni differenti

hanno lo stesso

significato. Seguire le convenzioni della piattaforma di calcolo utilizzata.

5. Prevenzione degli errori

Ancora meglio di buoni messaggi di errore è un’attenta progettazione che eviti innanzitutto

l’insorgere del

problema. Eliminare le situazioni che possono provocare errori da parte dell’utente, e chiedergli

conferma prima di

eseguire le azioni richieste.

6. Flessibilità ed efficienza d’uso(Es. un percorso più semplice e lungo è ottimo per un utente

novizio ma l’utente esperto preferirà un percorso più complesso ma veloce)

Acceleratori – invisibili all’utente novizio – possono spesso rendere veloce l’interazione

dell’utente esperto, in

modo che il sistema possa soddisfare sia l’utente esperto sia quello inesperto. Permettere

all’utente di

personalizzare le azioni frequenti.

7. Riconoscere piuttosto che ricordare

Minimizzare il ricorso alla memoria dell’utente, rendendo visibili gli oggetti, le azioni e le

opzioni. L’utente non

dovrebbe aver bisogno di ricordare delle informazioni, nel passare da una fase del dialogo a

un’altra. Le istruzioni

per l’uso del sistema dovrebbero essere visibili o facilmente recuperabili quando servono.

8. Design minimalista ed estetico

I dialoghi non dovrebbero contenere informazioni irrilevanti o necessarie solo di rado. Ogni

informazione

aggiuntiva in un dialogo compete con le unità di informazione rilevanti e diminuisce la loro

visibilità relativa.

9. Aiutare gli utenti a riconoscere gli errori, diagnosticarli e correggerli

I messaggi di errore dovrebbero essere espressi in linguaggio semplice (senza codici), indicare

il problema con

precisione e suggerire una soluzione in modo costruttivo.

10. Guida e documentazione

Anche se è preferibile che il sistema sia utilizzabile senza documentazione, può essere

necessario fornire aiuto e

documentazione. Ogni tale informazione dovrebbe essere facilmente raggiungibile, focalizzata

sul compito

dell’utente, e dovrebbe elencare i passi concreti da fare, senza essere troppo ampia.

Solitamente ci si aspetta che i valutatori siano almeno 5 e che possano scoprire i 2/3 dei

problemi di usabilità del prodotto.

Tecniche di valutazione con test su utenti

Utenti campione usano il sistema in un ambiente controllato, sotto osservazione da parte di

esperti di usabilità che raccolgono dati, li analizzano e traggono conclusioni. Possono essere

effettuate tramite due filosofie (Usability Lab che è una laboratorio costoso dove gli osservatori

effettuano le analisi in tempo reale o in un contesto informale (MEALY) quindi con strumenti

arrangiati e dove l’utente esprime ad alta voce perplessità e cosa sta cercando di fare)

Esistono tre tipologie di test su utenti:

Test su compiti: Agli utenti viene richiesto di svolgere compiti precisi (Es. Registrarsi)

 Test di casi d’uso: Agli utenti viene chiesto di svolgere diversi casi d’uso (Libro non lo

 cita neanche Bleah)

Test di scenario d’uso: Agli utenti viene esplicitato un obiettivo senza specificare i

 compiti da eseguire per raggiungerlo. L’utente dovrà quindi creare una sua tecnica per

raggiungerlo. (MEALY)

Secondo Nielsen, con il quinto utente si vengono a scoprire l’85% dei problemi di usabilità del

prodotto.

Qualunque sia la tecnica di valutazione utilizzata, i problemi i