INTRODUZIONE ALL'USABILITA'

Per un prodotto interattivo non e' sufficiente essere utile, deve essere anche usabile.

Esempi:
una porta che non si capisce se bisogna spingerla o tirarla...
un barattolo col tappo che non si capisce se bisogna sollevarlo o svitarlo; oppure troppo duro da aprire, o viceversa che si apre troppo facilmente anche per sbaglio...

L'usabilita' e' fondamentale!

Un prodotto non usabile sara' un prodotto che di fatto non esistera' (sara' disertato dagli acquirenti e scomparira' dal mercato). Un costo inutile per il produttore e per l'utente, che ne scegliera' un altro e percepira' un'immagine negativa non solo del prodotto ma anche e soprattutto del produttore.

Nel determinare l'usabilita' entrano molti elementi:

• lo scopo / finalita' dell'oggetto esiste (es. una sedia serve per sedersi)
• l'utente che deve usarlo (adulto, bambino...)
• il contesto / situazione in cui deve usarlo (postazione da computer, autobus, bar, ristorante)

In sintesi un prodotto interattivo per essere usabile deve:

• essere adeguato ai bisogni / aspettative di specifici utenti in specifici contesti (ved. sopra)
• essere facile da capire, da imparare, da usare, ed essere gradevole (qui rientrano considerazioni cognitive / psicologiche / culturali)
• esplicare il suo scopo specifico in modo corretto, veloce, e con soddisfazione
• generare pochi errori e non critici (= che non provochino danni irreparabili al lavoro)

Usabilita' dei prodotti informatici

Un prodotto informatico si usa attraverso la sua interfaccia utente. L'interfaccia deve permettere:

• Lato macchina -- di fornire accesso a tutte le funzionalita' dell'applicazione sw sottostante e sfruttare in modo ottimale le risorse hw della macchina
• Lato utente -- permettere di eseguire il lavoro in modo facile, comodo, veloce, gradevole

Si puo' intendere l'usabilita' come caratteristica del prodotto nel suo complesso, o anche della sola interfaccia utente, a prescindere da valutazioni circa la presenza / assenza / correttezza / efficienza di funzionalita' nell'applicazione sottostante.

Usabilita' e' diversa da utilita', es. lettore di CD con solo 'play' e 'stop' e' meno utile di uno con anche altre funzionalita', ma puo' essere, limitatamente alle funzionalita' presenti, piu' usabile (dipende da come queste funzionalita' sono fornite).

Breve storia dell'usabilita'

L'ostacolo principale a progettare interfacce utente usabili e' la distanza tra modello del progettista e modello dell'utente.
I due modelli (= modi di ragionare) in genere differiscono per: livello di conoscenza informatica, livello di conoscenza del dominio applicativo, interessi, esigenze, desideri che i due si pongono quando usano il prodotto, abilita'.

Anni '70

Inizialmente il problema dell'usabilita' non si pone perche' gli utenti finali dei prodotti informatici sono gli stessi progettisti.

Quando il problema dell'usabilita' inizia a delinearsi, nasce scienza Human Computer Interaction, HCI (interazione uomo macchina) e si comincia a parlare di fattori umani nella progettazione dei prodotti informatici.

Nascono le prime metodologie di progettazione centrata sull'utente.

• progettazione scomposta in fasi e si valuta usabilita' di ogni fase (modello a cascata)
• valutazione affidata agli sviluppatori senza coinvolgere utenti veri
• basata su modello teorico di utente 'umano' generico visto dal punto di vista psicologico (psicologia del software)
• poco efficaci

Primi anni '80

Prima diffusione della tecnologia informatica negli uffici e nelle case.

Inizialmente e' l'utente che viene costretto ad adeguarsi al modello del progettista. L'usabilita' comincia a essere problema rilevante.

HCI assume l'obiettivo di avvicinare modello del progettista a modello dell'utente.

• linee guida per la progettazione
• si creano prima prototipi, che vengono sperimentati e valutati in laboratorio con utenti prima di immissione in commercio
• in base ai risultati si ripete fino a prodotto accettabile (design iterativo)

Fine anni '80 inizio '90

Si conclude che non esistono linee guida generali che assicurino di progettare un prodotto usabile. Dipende troppo dal contesto (tipo di utente, dominio applicativo, ambiente di utilizzo, ecc.).

Secondi anni '90

Coinvolgere utenti in tutte le fasi del progetto (non solo nel test del prototipo finito).
La progettazione diventa processo iterativo con diretto coinvolgimento degli utenti finali a partire dalla raccolta dei requisiti, attraverso la stesura del progetto nei vari livelli di dettaglio, fino al prodotto finito (design partecipativo).

Che parte ha l'usabilita'

Un prodotto informatico deve essere:

• usabile (nell'interfaccia con l'utente)
• robusto (pochi errori interni)
• di facile installazione, manutenzione e aggiornamento
• sicuro (da attacco hacker)
• accettabile socialmente
• con costo economico entro il tetto previsto

Definizione di usabilita'

Secondo lo standard ISO 9241,
L'usabilita' misura il grado di efficacia, efficienza e soddisfazione con cui il prodotto (a mezzo della sua interfaccia) consente a un utente specifico, in un contesto d'uso specifico, di raggiungere obiettivi specifici.

• efficacia: completezza e precisione dei risultati
• efficienza: risorse impiegate (tempo, concentrazione, sforzo di memoria...)
• soddisfazione: comodita', accettabilita' del sistema di lavoro
• specifico / specifici: usabilita' non e' caratteristica del prodotto in se ma dipende da chi lo usa, dove e perche' (= quale utente, in quale situazione, per quale scopo).

Se in un prodotto misuriamo numericamente (in modo empirico) questi tre parametri possiamo visualizzarne l'usabilita' come un punto in spazio 3D (efficienza, efficacia, soddisfazione).

Fattori chiave

Fattori chiave nella valutazione dell'usabilita' di un'interfaccia. Ci riferiamo a un'attivita' (task) applicativa:

1. Intuitivita' e facilita' di apprendimento: quanto tempo e sforzo impiega utente ad imparare a svolgere l'attivita': scoprire come si fa (la prima volta) e raggiungere padronanza
2. Velocita' di esecuzione: quanto tempo impiega utente esperto a svolgere l'attivita' (dopo avere imparato)
3. Frequenza di errori: quanti e quali errori utente tende a fare nello svolgere l'attivita', e quanto dannosi
4. Persistenza nel tempo: quanto tempo utente impiega a dimenticare come si fa (dipende anche da frequenza d'uso)
5. Soddisfazione soggettiva: comodita', accettabilita' (il modo d'uso del prodotto puo' influenzare l'intero metodo di lavoro della persona nello svolgere la sua ativita')

In piu' ci sono da considerare i costi economici per progetto e realizzazione dell'interfaccia, strettamente connessi al tempo richiesto (mesi/uomo).

Nonche' eventuali limitazioni della piattaforma su cui dovra' girare (es. interfaccia grafica per un palmare; memoria o potenza di calcolo limitate).

Alcuni obiettivi sono in conflitto fra loro.
Importanza di ciascun fattore dipende dall'applicazione in questione. Esempi:

• Sistemi critici (controllo di traffico aereo, centrali nucleari, strumentazioni mediche...).
  Importante esecuzione rapida e senza errori. Costi e tempi di apprendimento importano poco. Soddisfazione importa poco perche' utenti ben motivati.

• Sistemi commerciali e industriali (software gestionale per banche, assicurazioni, prenotazioni aeree...).
  Importanti i costi, ma da distribuire sul costo di tutta l'attivita' dell'impresa. Importante facilita' di apprendimento e velocita' d'uso. Errori e soddisfazione utente hanno importanza modesta.

• Applicazioni per ufficio, casa, divertimento (word processor, contabilita', educazione, ricerca di informazioni, giochi...).
  Importanti facilita' di apprendimento, bassa frequenza di errori e soddisfazione (per vendere il prodotto). Importante costo, ma si puo' ammortizzare col numero di vendite.

• Sistemi creativi, scientifici, ambienti cooperativi (enciclopedia, sistemi esperti, simulazioni scientifiche, artisti, musicisti, conferenze, e-learning...).
  Utente e' esperto del campo applicativo ma non dello strumento informatico. Molto motivato ma si aspetta molto. Interfaccia deve essere meno invasiva possibile e permettere all'utente di concentrarsi sul lavoro vero.

Fattori umani

Progettare considerando lo scopo per cui l'utente usera' l'applicazione e gli utenti che devono adoperarla.

Scopo dell'utente

Identificare e capire le attivita' applicative che l'utente ha interesse ad effettuare attraverso l'interfaccia.
Tracciare profilo di un insieme di attivita' (task) su cui valutare l'interfaccia.

Stimare frequenza delle varie attivita'. Le piu' frequenti devono essere piu' facilmente accessibili.

Utenti

Tracciare profilo dell'utente tipico: eta', istruzione, cultura, esperienza (del dominio applicativo e di computer), frequenza con cui usa lo strumento.
Eventualmente piu' di un profilo se utenza e' eterogenea.

Tenere conto delle capacita', esperienza, limitazioni dell'utente tipico (relativamente a percezione, memoria, attenzione e apprendimento). Nonche' della predisposizione d'animo (ad alcuni computer causa rifiuto o ansieta', altri ne sono attratti).

Stessa applicazione puo' richiedere interfacce diverse per utenze diverse.

Interfaccia

Rendere il piu' possibile invisibile all'utente la tecnologia sottostante, perche' si possa concentrare sul compito che deve svolgere e non sull'interfaccia.

Gli utenti notano l'architettura di un sistema solo quando questa funziona male o crea problemi.