Riassunto Progettazione dell'interazione con l'utente PDF

# Riassunto Progettazione dell'interazione con l'utente ## INDICE: 1. Sistemi interattivi e interfacce d'uso 2. Evoluzione dei paradigmi d'interazione 3. Usabilità 4. Progettare per l'utente 5. Ingegneria dell’usabilità 6. I requisiti 7. Ingegneria e creatività 8. I prototipi 9. Principi e linee g...

# Riassunto Progettazione dell'interazione con l'utente ## INDICE: 1. Sistemi interattivi e interfacce d'uso 2. Evoluzione dei paradigmi d'interazione 3. Usabilità 4. Progettare per l'utente 5. Ingegneria dell’usabilità 6. I requisiti 7. Ingegneria e creatività 8. I prototipi 9. Principi e linee guida 10. Progettare per l'errore 11. Progettare la grafica 12. Progettare il testo 13. Valutare l'usabilità 14. Accessibilità 15. Task Analysis ## Capitolo 1: Sistemi interattivi e interfacce d'uso Un sistema interattivo è una combinazione di componenti *hardware* e *software* progettata per ricevere input da un utente e fornire output utile per svolgere un compito. Non rientrano in questa definizione i sistemi che interagiscono esclusivamente con altri sistemi. Un'interfaccia d'uso comprende tutti i componenti di un sistema (*hardware* o *software*) che permettono all'utente di ricevere informazioni e impartire comandi necessari per completare compiti specifici. Un *task* è definito come un insieme di attività necessarie per raggiungere un obiettivo. L'interazione tra utente e sistema interattivo viene formalizzata dall’ISO 9241 come *dialogo*. La complessità di un sistema interattivo si basa su due dimensioni principali: 1. **Complessità strutturale:** dipende dal numero e dalla relazione tra le componenti interne del sistema. 2. **Complessità funzionale:** misura la capacità del sistema di supportare diverse attività. Questi due aspetti non sono necessariamente correlati: un sistema può essere funzionalmente complesso ma strutturalmente semplice, o viceversa. * La complessità strutturale può essere valutata, ad esempio, contando le linee di codice sorgente. * La complessità funzionale si misura attraverso i *punti funzione,* che rappresentano le funzionalità fornite all'utente, indipendentemente dal linguaggio di programmazione. Infine, si considera la *complessità d'uso*, ovvero quanto è semplice per l'utente completare i task offerti dal sistema. La complessità d'uso di un sistema interattivo è strettamente legata alla diversità dell'utenza. Fattori come lingua, cultura e abitudini influenzano il modo in cui ogni utente si rapporta al sistema. I sistemi interattivi tendono a evolversi nel tempo, dando origine al problema dell' *iperfunzionalismo*. Donald Norman descrive il modello evolutivo tipico dei prodotti tecnologici: 1. **Fase immatura:** il prodotto presenta prestazioni insufficienti rispetto ai bisogni degli utenti. 2. **Punto di pareggio:** le prestazioni del prodotto soddisfano pienamente il target principale. 3. **Eccesso di prestazioni:** il prodotto evolve per attrarre un'utenza più ampia, ma introduce funzionalità inutili per l'utente medio, rendendo il sistema più complesso e, potenzialmente, instabile. L'interfaccia d'uso svolge un ruolo cruciale nel *filtrare* la complessità del sistema, facilitando un dialogo chiaro e immediato tra utente e sistema. Negli anni '90 nasce la disciplina dell' *Human-Computer Interaction (HCI)* che si occupa di progettare, valutare e realizzare sistemi interattivi basati su computer per uso umano, studiando i fenomeni connessi all'interazione tra uomo e macchina. ## Capitolo 2: Evoluzione dei paradigmi d'interazione L'evoluzione dei paradigmi di interazione L'avanzamento della tecnologia ha introdotto 5 paradigmi principali, ciascuno rappresentato da un dispositivo o tecnologia caratteristica: 1. **Teletype (Paradigma “scrivi e leggi")** * Caratteristiche: Tastiera e stampante su carta continua.
 * Come funziona: La macchina guida l'interazione, e l'utente risponde ai comandi richiesti.
 * Limiti: Interazione rigida e sequenziale.
 * Esempi: Sistemi esperti. 2. **Terminale video (Paradigma “indica e compila”)** * Caratteristiche: Introduzione dello schermo video e cursore spostabile con tasti. * Come funziona: Uso di menu e form gerarchici per semplificare l'interazione.
 * Limiti: L'utente è vincolato a ciò che vede sullo schermo. 3. **Personal computer (Paradigma “non dirlo, fallo”)** * Caratteristiche: * Potenza di calcolo locale.
 * Archiviazione su dischetti.
 * Stampa locale. * Novità: * Interfacce grafiche con finestre.
 * Accessibilità per utenti non tecnici grazie a software intuitivi. * Risultato: La tecnologia diventa disponibile a un pubblico molto più ampio. 4. **Browser web (Paradigma “point & click”)** * Caratteristiche: * Esplorazione di documenti ipertestuali.
 * Navigazione non sequenziale basata sugli interessi. * Novità: * Nascono i motori di ricerca, che guidano gli utenti verso contenuti rilevanti. * Risultato: Interazione più libera e basata sull'esplorazione. 5. **Mobile (Paradigma “alzati e cammina”)** * Caratteristiche: * Dispositivi come smartphone e laptop.
 * Interazioni in mobilità. * Risultato: La tecnologia è sempre connessa e accessibile ovunque. **Social Computing** * Importanza: Permette interazioni complesse tra persone distanti nello spazio e nel tempo. * Esempi: Social network, strumenti di collaborazione online. **Intelligenza ambientale** • Un ramo moderno dell'evoluzione tecnologica che punta a creare ambienti intelligenti e interconnessi. • Caratteristiche principali: * Embedded: Dispositivi integrati nell'ambiente.
 * Context-aware: Capacità di percepire e interpretare il contesto.
 * Personalizzate: Configurabili in base alle esigenze dell'utente.
 * Adattive: Apprendono e si evolvono nel tempo.
 * Anticipatorie: Prevedono bisogni e desideri dell'utente. ## Capitolo 3: Usabilità L'interazione che avviene tra l'utente e un sistema viene concettualizzato per la prima volta da Norman. Suddivise l'operare sugli oggetti in 7 passi principali: * **ne**  * **Jione**  * **ne**  * **ndo**  * **ndo**  * **Tato** Ovviamente i passi sono approssimativi, il vero scopo di questo modello è quello di evidenziare i momenti in cui possono presentarsi problemi. Infatti è possibile che si incontrino difficoltà nel passare da uno stato all'altro (cioè nell'attraversare i golfi che li separano **Golfo dell'esecuzione** * Capire come agire sul sistema per ottenere ciò che desidera.
 * Tradurre le sue intenzioni in azioni concrete sul sistema.
 * Offrire affordance: Gli elementi dell'interfaccia devono suggerire all'utente come utilizzarli (esempio: un pulsante che sembra "premibile"). **Golfo della valutazione** * Osservare ciò che il sistema sta facendo.
 * Interpretare se l'azione ha avuto successo. Si introduce ora il termine *affordance*, importante come concetto in quanto un oggetto che è dotato di affordance è quello che ci invita a utilizzarlo nel modo corretto, cioè nel modo in cui è stato concepito. Gli oggetti ad alta tecnologia sono spesso privi di affordance. Una buona affordance riduce il golfo di *esecuzione*, mentre per ridurre il golfo della valutazione gli oggetti dovranno fornire un feedback che indichino chiaramente quali modifiche, le azioni, abbiano prodotto sullo stato del sistema. Il feedback deve essere ben comprensibile e specifico e l'utente deve essere in grado di interpretarlo senza fatica. Fattore importante è la sua tempestività in modo che l'utente lo pone in relazione con l'azione a cui si riferisce. Se passa troppo tempo tra l'azione e il feedback è opportuno inserire dei feedback intermedi (discreti o continui) con lo scopo di segnalare all'utente il progredire dello stato del sistema verso lo stato finale desiderato. In conclusione, compito principe del progettista è quello di progettare oggetti con buona affordance (per ridurre ampiezza del golfo di esecuzione) e con buon feedback (per ridurre ampiezza del golfo della valutazione). Norman però non definisce formalmente l'usabilità e ciò che serve è proprio un modo per quantificarla. Nello standard ISO 9241 l'usabilità è definita come l'appropriatezza e la soddisfazione di un sistema in uno specificato contesto. Questa definizione offre l'opportunità di creare delle metriche, in particolare scompone il concetto di usabilità su 3 assi: * **Accuratezza:** è quella che viene definita come l'accuratezza e la completezza con ciò gli utenti raggiungono specifici obiettivi. * **Efficienza:** è definita come la quantità di risorse spese in relazione all'accuratezza e alla completezza con cui gli utenti raggiungono gli obiettivi. * **Soddisfazione:** è definita come la libertà dal disagio e l'attitudine positiva verso l'uso del prodotto. Questa definizione è ancora rudimentale in quanto non tiene in conto che un utente può subire un'evoluzione di apprendimento nel tempo. Nella progettazione di un sistema, il progettista ha di fronte a sé diverse scelte possibili: * considerare come principali destinatari del prodotto gli utenti occasionali; * progettare in primo luogo per gli utenti continuativi, cioè per coloro che lo utilizzeranno in modo frequente e continuativo. Apprendibilità e memorabilità sono così importanti che diversi autori li considerano talmente influenti da incorporarli nella stessa definizione di usabilità. Nielsen definisce l'usabilità come la somma dei 5 attributi seguenti: * **Apprendibilità:** il sistema deve essere facile da imparare per permettere agli utenti di ottenere rapidamente risultati. * **Efficienza:** il sistema deve garantire un alto livello di produttività dopo l'apprendimento. * **Memorabilità:** il sistema deve essere intuitivo da ricordare per gli utenti occasionali. * **Errori:** il sistema deve prevenire errori e facilitare il loro recupero. * **Soddisfazione:** il sistema deve offrire un'esperienza piacevole e soddisfacente. Per favorire l'apprendimento all'utenza vengono messi a disposizione diversi sussidi. Per esempio i tutorial, gli help online, gli help desk oppure i manuali stessi del prodotto. Questi sussidi hanno lo scopo di assistere l'utente in vari modi: alcuni (starter kit e tutorial) lo accompagnano nell'uso iniziale del sistema, quando non lo conosce ancora, altri (manuali utente) hanno lo scopo di assisterlo durante l'uso successivo. Dal processo di apprendimento, attraverso i suoi sussidi, che spesso non sono distinguibili all'uso iniziale. Iniziare a un uso evoluto, un sistema usabile dovrebbe mettere in grado i suoi utenti di utilizzarlo senza alcun sussidio esterno al sistema stesso.
In questo senso va interpretata la frase di Norman: ho una regola semplice per individuare il cattivo design. Tutte le volte che trovo indicazioni su come usare qualcosa, si tratta di un oggetto progettato male. Ovviamente vanno considerati anche i contesti d'uso e le tipologie di utenti. Ciò significa che l'usabilità, così come gli altri parametri di qualità di un software, è relativa. L'accessibilità è un concetto strettamente correlato all'usabilità ed è definita come la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari. Per tecnologie assistive la legge intende: gli strumenti e le soluzioni tecniche, hardware e software, che permettono alla persona disabile (mimmo), superando o riducendo le condizioni di svantaggio, di accedere alle informazioni e ai servizi erogati dai sistemi informatici ## Capitolo 5: Progettare per l'utente Nell'attività di progettazione si parte da un esame della situazione attuale per riconoscerne difetti o limiti per concepire e specificare il risultato finale. Pertanto progettare è diverso da realizzare.
Quest'ultima infatti è un'attività concreta: si parte da un progetto e lo si attua concretamente. La progettazione di sistemi usabili richiede un drastico cambiamento di mentalità rispetto all'approccio di progettazione tradizionale. Nella progettazione tradizionale, l'oggetto principale dell'attenzione è il sistema da progettare (partendo dai requisiti funzionali fino a essere realizzato). In questo approccio il progettista concentra la sua attenzione sulle funzionalità e sugli aspetti tecnici connessi all alla loro realizzazione, per arrivare a soddisfare le specifiche con un rapporto costo/qualità accettabile. Se l'obiettivo è la progettazione di un sistema usabile, questo approccio non funziona. In questo caso, il progettista dovrà porre la sua attenzione sull'utente e dovrà studiarne le caratteristiche, le abitudini, e le necessità in relazione all'uso del sistema: 1. dovrà preconfigurare i vari contesti in cui il sistema sarà utilizzato, e i suoi diversi casi d'uso; 2. dovrà analizzare in dettaglio i compiti che l'utente svolgerà con il sistema. Secondo questa impostazione il compito del progettista sarà quello di progettare l'interazione fra il sistema e il suo utente. Si parla così di *interaction design* e di *progettazione centrata sull'essere umano (human centred design HCD)*. La progettazione centrata sull'essere umano è l'oggetto di un altro standard molto importante, I'ISO 13407: Human-centred design processes for interactive systems.
E' un approccio allo sviluppo dei sistemi interattivi specificamente orientato alla creazione di sistemi usabili. E' un'attività multidisciplinare che incorpora la conoscenza e le tecniche dei fattori umani e dell’ergonomia (per applicarla si deve tener conto della capacità, delle abilità, delle limitazioni e delle necessità umane). 
Queste tecniche potenziano la progettazione dei sistemi interattivi nell' efficienza, efficacia e migliora le condizioni del lavoro umano. Inoltre contrasta i possibili effetti avversi dell'uso sulla salute, sulla sicurezza e sulle prestazioni. I benefici human-centred posso includere una maggiore produttività, una migliore qualità del lavoro, riduzione dei costi di supporto e di addestramento e una migliore soddisfazione dell'utente. La progettazione human-centred è un approccio generale, che può essere sviluppato in molti modi, in funzione della natura dei prodotti da realizzare e delle caratteristiche dell'organizzazione che ospita il progetto.
L'utilizzo di un approccio human-centred è caratterizzato da: * il coinvolgimento attivo degli utenti e una chiara comprensione dei requisiti degli stessi e dei compiti; * un'assegnazione appropriata delle funzioni fra utenti e tecnologia; * l'iterazione delle soluzioni di progetto; * una progettazione multidisciplinare. L'ultimo punto è il cambiamento più rilevante rispetto a un approccio progettuale tradizionale, poiché richiede un'organizzazione diversa dei gruppi di progetto. Infatti oltre all'ingegnere sono necessarie altre competenze, relative alle scienze dell'uomo e non alla tecnologia. 
Queste competenze sono: * l'analisi e la comprensione dei comportamenti e delle loro motivazioni; * l’analisi e la conoscenza dei processi percettivi e cognitivi coinvolti nell'interazione con i sistemi; * la comprensione delle problematiche ergonomiche; * la competenza sulle diverse modalità della comunicazione umana. Tutto questo deve inevitabilmente far parte dei processi che portano alla progettazione e alla realizzazione di sistemi usabili. Lo HDC produce risultati completamente diversi da quelli ottenuti con l'approccio tradizionale. Le funzioni che interessano agli utenti non vengono fornite dai singoli componenti modulari, ma dalla loro cooperazione. Si dovrebbe partire dall'utente nella progettazione di qualsiasi strumento, semplice o complesso. Un caso d'uso, di grande importanza nella progettazione human-centred, può essere definito come un insieme di interazioni tra l'utente e il sistema, finalizzate a uno scopo utile per l'utente. Nota molto importante è che non bisogna confondere i casi d'uso con le funzionalità del sistema. Nel primo il soggetto è l'utente (ex. Ascoltare CD, Guardare DVD), nel secondo è una prestazione realizzata dal sistema (ex. Caricamento del CD, Espulsione del CD). Semplificando al massimo, si può dire che il progettista orientato al sistema si occupa di progettare funzioni, lasciando all'utente il compito di “metterle nella sequenza giusta”, per ottenere ciò che gli serve (segue un approccio *bottom-up*).
II progettista orientato all'utente desidera conoscere perché l'utilizzatore adopererà il sistema, e vuole permettergli di raggiungere questi obiettivi nel modo più semplice e lineare (segue *approccio top-down*: non parte dalle funzioni, ma dagli obiettivi). L'identificazione dei casi d'uso è un'attività fondamentale nella progettazione human-centred: disporre di un elenco ben fatto dei casi d'uso del sistema costituisce un primo passo indispensabile per poterlo progettare. Per eseguirlo correttamente, occorre superare diverse difficoltà: 1. esiste sempre il rischio di scambiare i casi d'uso con le funzionalità e ricadere nelle pratiche della progettazione orientata al sistema; 2. occorre individuare il giusto livello di astrazione; 3. l'elenco dei casi d’uso deve essere il più possibile completo (ciò permette di avere un quadro preciso del rapporto fra utente e sistema e della sua complessità funzionale. Si vuole poter costruire sistemi che risultino usabili non solo per una specifica persona o gruppo di persone, ma per ogni categoria di utenti.
La progettazione di sistemi universalmente usabili è stata chiamata *progettazione universale* o *design for all (DfA)* che è la progettazione di prodotti e ambienti usabili da tutte le persone senza la necessità di adattamenti o progettazioni speciali. 
Questa filosofia del design universale non riguarda solo i sistemi interattivi ma può applicarsi a molti ambiti diversi. Un gruppo di architetti, ingegneri, designer industriali, e ricercatori, alla fine degli anni 90, ha elaborato 7 principi generali per orientare i progettisti indipendentemente dal particolare ambito di progettazione: 1. **Equità d’uso:** prodotto utile e vendibile a persone con abilità diverse; 2. **Flessibilità d’uso:** prodotto supporta ampio spettro di preferenze e abilità individuali; 3. **Uso semplice e intuitivo:** l'uso del prodotto facile da comprendere indipendentemente dalle caratteristiche dell'utente; 4. **Informazione percepibile:** prodotto comunica efficacemente l'informazione necessaria all'utente (indipendentemente dalle condizioni ambientali o abilità sensoriali dell'utente); 5. **Tolleranza agli errori:** il prodotto minimizza i rischi e conseguenze di azioni avverse e accidentali o non intenzionali; 6. **Ridotto sforzo fisico:** prodotto può essere usato in modo efficace, confortevole e con sforzo minimo; 7. **Dimensione e spazio adatti all'uso e all'approccio:** forniti dimensioni e spazi appropriati per avvicinamento, manipolazione e uso indipendentemente dalla corporatura, postura o mobilità dell'utente. Nel caso dei prodotti interattivi, la progettazione universale rappresenta una sfida difficile per il progettista. 
Le difficoltà derivano sostanzialmente da 3 ragioni: 1. **Diversità delle tecnologie disponibili ai diversi utenti.** Gli ecosistemi tecnologici sono in continuo cambiamento; 2. **Diversità degli individui.** 
Queste differenze rientrano approssimativamente in 3 grandi categorie: fisiche, cognitive, socio-culturali; 3. **Diversità nella capacità d'uso della tecnologia.** Dal punto di vista generale, ci sono 2 strade per produrre un design universale. La prima rappresenta l'approccio tradizionale: consiste nel definire un utente “medio” del sistema (cioè al quale il prodotto si indirizza prioritariamente), mentre per gli altri utenti si realizzano dei componenti ad hoc (separati dal sistema). Questo approccio però pone diversi problemi: * il progettista non è in grado di tener conto fin dall'inizio delle necessità degli utenti diversi (adattamenti quindi potranno essere complessi da realizzare); * altra difficoltà dovuta alla necessità di mantenere la compatibilità fra il sistema e le diverse tecnologie assistive destinate agli utenti speciali. Per risolvere queste difficoltà si è fatta strada una filosofia di progettazione molto diversa: questa non privilegia l'utente medio, ma tiene in considerazione fin da subito le necessità di tutte le categorie di utenti. E' evidente che i due approcci sono molti diversi. Il primo semplifica l'attività di progettazione; il secondo richiede che tutti i problemi siano affrontati e risolti in modo sistematico fin dall'inizio (strategia più complessa). Esiste infine, una terza possibilità (ancora più sofisticata). In questo caso il sistema, oltre ad essere personalizzabile in fase di configurazione iniziale, è in grado di monitorare con continuità i comportamenti e le modalità d'uso dell'utente, e di adattarvisi modificando il proprio comportamento.
In sostanza, il sistema impara durante l'uso (sistemi si chiamano adattativi). I tre approcci non sono alternativi, ma complementari. Possono essere in qualche misura compresenti in uno stesso sistema. 
In definitiva, potremmo definire la progettazione universale come l'approccio secondo il quale i sistemi sono progettati per essere sufficientemente intelligenti da adattarsi alle richieste o alla modalità di utilizzo dei loro diversi utenti o da permettere un facile interfacciamento con adattatori speciali. Lo human-centred design può essere considerato un approccio maturo, che contiene al suo interno le problematiche tecniche del system-centred design e ci permette di comprendere in modo più approfondito le finalità del sistema. 
Possiamo classificare le attività di progettazione in differenti livelli di maturità: * **Primo livello di maturità:** il prodotto funziona. Il progettista si occupa principalmente della risoluzione di problemi di natura tecnologica, e si accontenta che le funzioni previste nel sistema siano operative, e non ci siano errori di funzionamento. * **Secondo livello di maturità:** il prodotto fornisce le funzionalità necessarie. Il sistema non soltanto funziona, ma realizza tutte le funzionalità ritenute necessarie per gli scopi per cui è concepito. * **Terzo livello di maturità:** il prodotto è facile da usare. Questo è il livello della progettazione human-centred. Non solo il prodotto funziona e offre tutte le funzionalità richieste, ma le organizza in modo adeguato rispetto alle tecnologie e alla necessità dei suoi utenti, nei diversi contesti d'uso. * **Quarto livello di maturità:** il prodotto è invisibile durante l'uso. In questo caso il prodotto funziona, fornisce tutte le funzionalità richieste, è usabile e si integra in modo così armonico e poco intrusivo con i comportamenti del suo utente che questi non si accorge di usarlo. Le competenze richieste a un *interaction designer* sono molto diverse da quelle richieste a un *system designer*.
Mentre quest'ultimo dovrà possedere essenzialmente competenze di natura tecnologica nel dominio cui appartiene il sistema da progettare e progettuale, il primo dovrà essere in grado di analizzare e comprendere le caratteristiche e i bisogni dell'utente per definire, a partire da queste, le modalità d'interazione più opportune. ## Capitolo 6: L'ingegneria dell'usabilità Il termine ingegneria può essere definito in molti modi. Vuole sottolineare l'approccio pragmatico e basato su fondamenti scientifici di questa disciplina, che si propone di dare indicazioni concrete e operative a chi abbia il compito di progettare e sviluppare sistemi interattivi.
L'ingegneria del software si occupa dei metodi e delle tecniche per la progettazione e realizzazione di sistemi software di qualità, senza sprechi (si è occupata tradizionalmente di sistemi software molto complessi il cui sviluppo coinvolge decine di persone o più. Più recentemente è entrato nell'uso il termine *ingegneria dell'usabilità (usability engineering)* per indicare la disciplina che studia le tecniche, i metodi e i processi che possono essere utilizzati per progettare e sviluppare sistemi usabili.
E' un processo che si basa sull'ingegneria classica e consiste nello specificare quantitativamente e in anticipo quali caratteristiche e in qual misura il prodotto finale da ingegnerizzare dovrà possedere.
Inizialmente, l'ingegneria dell’usabilità si è focalizzata sul design dell'interfaccia utente dei sistemi software. 
Oggi, comprende la totalità delle pratiche utilizzate nel processo di progettazione e sviluppo dei sistemi interattivi, a partire dalla raccolta e analisi iniziale dei requisiti. I principi cardine di questa disciplina possono considerarsi ben consolidati e si possono riassumere in 3 punti chiave: 1. **Focalizzazione sull'utente, all'inizio e durante tutto il processo di progettazione;** 2. **Prove con l'utente durante l'intero processo di progettazione, con analisi qualitative e misure quantitative;** 3. **Modello di progettazione e sviluppo iterativo, per prototipi successivi.** Quando la disciplina dell'ingegneria del software era agli esordi si pensava che per realizzare un progetto di successo fosse necessario procedere per fasi logiche ben sequenziate, ognuna delle quali ponesse le basi per la fase successiva. In poche parole, dalla fase iniziale di un progetto si arriva, passo passo, al rilascio del sistema senza tornare mai sui passi precedenti (Modello a cascata, waterfall model). Per costruire qualcosa bisogna prima decidere che cosa si vuole ottenere e descriverlo dettagliatamente; poi si passerà alla sua realizzazione, quindi al collaudo finale e alla consegna al richiedente. 
Ci si accorse però che non sempre funzionava così: nella pratica, in nessun progetto reale le cose procedevano in maniera così semplice e lineare. Bisognava ritornare sui passi precedenti, per rivedere e modificare decisioni già prese, anche se erano ritenute assolutamente consolidate. Le cause potevano essere molteplici: * il committente richiedeva delle varianti che modificavano le specifiche già approvate; * i progettisti scoprivano difficoltà tecniche inattese; * nella fase di rilascio del sistema, i primi utenti segnalavano delle difficoltà nell'uso che non erano state previste e richiedevano cambiamenti consistenti. Quindi ci si rese conto che nessun sistema complesso può essere realizzato con il modello della cascata, perché impossibile specificarne tutti gli aspetti all'inizio e poi realizzarlo senza modificarne nulla.
Ragioni di questa impossibilità sono sia di carattere pratico, sia teorico- concettuale. * **Pratico** perché molto difficile prevedere “sulla carta” tutti gli aspetti di un sistema complesso. * **Teorico-concettuale** perché per soddisfare le nostre necessità produciamo strumenti, che a loro volta, generano nuovi bisogni. Allora si costruiscono nuovi strumenti o si modificano quelli già disponibili in un ciclo evolutivo infinito, al quale è stato dato il nome di *task-artifact cycle* (ciclo compito-artefatto). In sostanza, non è possibile valutare completamente l'adeguatezza dello strumento ai suoi utenti, prima che questi lo usino effettivamente. Se il modello a cascata è inadeguato si ha bisogno di un modello che coinvolga gli utenti fin da subito per sperimentare l'uso di versioni preliminari del sistema e aiutarci, con le loro reazioni e le loro indicazioni in un processo di prove e aggiustamenti successivi. Quindi ecco come il *modello iterativo* prende il sopravvento. L'idea è di procedere con la realizzazione di una serie di *prototipi*, via via più vicini al sistema finale. Si inizia con un prototipo preliminare, a costi ridotti e lo si sottopone all'utente che prova a utilizzarlo (prima prova limitata perché il sistema sarà molto semplificato ma sufficiente a verificare alcune assunzioni di partenza ed eventualmente aggiustare il tiro. Si realizza poi un altro prototipo, sempre incompleto, ma più vicino alla versione finale e lo si sottopone ancora alla prova degli utenti e così via per approssimazioni successive fino alla conclusione del progetto. Si nota quindi che le prove d'uso diventano parte integrante del processo di progettazione. Ovviamente, nelle varie iterazioni le diverse attività avranno pesi diversi. Infatti il primo prototipo sarà piuttosto rudimentale (mock up): effettuare un primo confronto con gli utenti e il committente. 
II processo di progettazione per prototipi successivi è il modello concettualmente corretto per la realizzazione di sistemi complessi. A fronte di questi vantaggi esiste il rischio che il processo diverga a causa di richieste di modifiche che nascono durante le attività di valutazione dei vari prototipi. Per evitare ciò, per ogni progetto sarà quindi necessario pianificare il processo iterativo di progettazione e sviluppo in modo che non degeneri. Il modello iterativo nell'ambito dell'ingegneria dell’usabilità assume una particolare autorevolezza.
La descrizione che ne da lo standard ISO 13407 ha lo scopo di fornire una guida alle attività di progettazione centrata sull'essere umano lungo il ciclo di vita dei sistemi interattivi basati sui computer. Il contesto in cui il sistema sarà utilizzato è definito dalle caratteristiche degli utenti, dei compiti e dell'ambiente fisico e organizzativo. E' importante identificare il contesto per orientare le decisioni iniziali del progetto e per fornire una base per la loro successiva convalida. Tutto questo sia per un nuovo progetto che per una modifica di un progetto già esistente.
Nel secondo caso, possono essere molto utili le reazioni degli utenti provenienti dai rapporti dell' help desk o da specifiche indagini esplorative. La descrizione del contesto d'uso del sistema dovrebbe comprendere i seguenti argomenti: * le *caratteristiche degli utenti*; * i *compiti* che gli utenti dovranno eseguire; * l'ambiente nel quale gli utenti utilizzeranno il sistema. Lo standard ricorda esplicitamente che tutte queste descrizioni non potranno essere congelate in un documento immutabile, ma in un documento di lavoro che sarà corretto, revisionato e ampliato più volte in accordo con la natura iterativa del processo di progettazione e sviluppo. Nella maggior parte dei processi di progettazione, esiste una consistente attività per la specifica dei requisiti del prodotto o sistema. Nella progettazione human-centred, quest'attività dovrebbe essere ampliata, per descrivere i requisiti in relazione al contesto d'uso più sopra specificato. Si dovrebbero considerare i seguenti aspetti: * le prestazioni richieste al nuovo sistema in relazione agli obiettivi operativi ed economici; * requisiti normativi e legislativi rilevanti, compresi quelli relativi alla sicurezza e alla salute; * comunicazione e cooperazione fra gli utenti e altri attori coinvolti; * attività degli utenti; * ripartizione dei compiti fra esseri umani e sistemi tecnologici; * prestazioni dei diversi compiti; * progettazione delle procedure di lavoro e dell'organizzazione; * gestione del cambiamento; * fattibilità delle diverse operazioni; * progettazione dei posti di lavoro e interfaccia uomo-computer. I requisiti e obiettivi dovrebbero essere stabiliti operando opportuni compromessi fra eventuali requisiti tra loro conflittuali.
Organizzati inoltre per livelli di priorità e formulati in modo da permettere la loro successiva convalida mediante opportuni test. **Produrre soluzioni di progetto:** Lo standard identifica le seguenti attività: * utilizzare le conoscenze disponibili per sviluppare proposte di progetto con un approccio multi-disciplinare; * rendere le soluzioni di progetto più concrete, utilizzando simulazioni, modelli e prototipi di vario tipo; * presentare le soluzioni di progetto agli utenti, permettendogli di eseguire i compiti che il sistema è destinato a supportare; * modificare il progetto in conseguenza delle reazioni degli utenti, e ripetere questo processo fino a che gli obiettivi della progettazioni non siano raggiunti; * gestire l'iterazione delle soluzioni di progetto (registrando i risultati delle attività precedenti). La **valutazione** è un passo essenziale nella progettazione human-centred e dovrebbe essere compiuta in tutte le fasi del ciclo di vita del sistema. Lo standard identifica le seguenti attività: * **produrre il piano di valutazione.** Le tecniche di valutazione variano secondo i casi. La scelta è determinata dalla natura del sistema, dai vincoli economici e di tempo e dalla fase del ciclo di sviluppo in cui si svolge la valutazione. * **fornire feedback per la progettazione.** 
La valutazione dovrebbe essere condotta in ogni fase del ciclo di vita del sistema; * **verificare se gli obiettivi sono stati raggiunti.** La valutazione dovrebbe utilizzare metodi appropriati, con un campione rappresentativo di utenti che eseguono compiti realistici; * **valutazione sul campo.**
Lo scopo sul campo è provare il funzionamento del sistema finale durante l'uso effettivo, per assicurare che esso soddisfi i requisiti degli utenti, dei compiti e dell'ambiente; * **monitoraggio di lungo termine.** 
Consiste nel raccogliere input dagli utenti, con modalità differenti, lungo un certo periodo di tempo; * **documentazione dei risultati.** 
Allo scopo di gestire il processo di progettazione iterativo, i risultati delle valutazioni dovrebbero essere registrati in modo sistematico. Al modello dell'ISO 13407 sono stati definiti e applicati vari approcci che differiscono fra loro nei dettagli e nel ruolo che l'utente assume durante il processo della progettazione.
L'approccio più conosciuto è noto come *progettazione centrata sull'utente (user-centred design (UCD))* : l'utente ha un ruolo fondamentale nell'acquisizione dei requisiti del sistema e nell'effettuazione delle prove d'uso dei diversi prototipi prodotti nelle varie iterazioni del progetto. Non è coinvolto, invece, nelle attività di progettazione e realizzazione dei vari prototipi che sono condotte dai progettisti e dagli sviluppatori del sistema. In altri approcci, il coinvolgimento dell'utente avviene con modalità diverse. Nella *progettazione partecipativa (participatory design)* l'utente viene coinvolto anche nelle attività di progettazione, partecipando attivamente alla realizzazione dei prototipi.
Nello *usage-centred design* il centro dell'attenzione è sull'uso e non sull'utente, che viene coinvolto nel processo di progettazione in modo molto limitato. Nel contesto dei processi dell'ingegneria dell'usabilità, alcune professionalità specifiche assumono un ruolo rilevante. Possono venire raccolte sotto la generica etichetta di *usability professional*. I primi costi da affrontare sono quelli relativi alla trasformazione di un progetto tradizionale in uno che utilizza principi dell'ingegneria dell'usabilità. Questo richiede attività di addestramento (per progettisti e responsabili di progetto) e reclutamento di nuove risorse come ad esempio consulenti esperti di usabilità. Inoltre vanno quantificati i costi delle attività esclusive per rendere il progetto usabile, attività che in un progetto tradizionale non verrebbero eseguite. Un'idea secondo Nielsen sarebbe quella di realizzare due prodotti “equivalenti”, differenti però solo per l'approccio ingegneristico: uno tradizionale e uno human-centred in modo da valutare i costi aggiuntivi. Ovviamente il tutto è puramente teorico e per le situazioni reali si utilizzano tecniche euristiche. ## Capitolo 7: I requisiti **Definizione dei requisiti **
La definizione dei requisiti si articola in tre fasi principali: * **Fase esplorativa:** raccolta dei requisiti tramite interviste, questionari, focus group, ecc. * **Fase organizzativa:** analisi e organizzazione delle informazioni raccolte, risolvendo eventuali conflitti. * **Fase di revisione:** verifica e approvazione del documento dei requisiti da parte degli stakeholder e del committente. II documento non è mai finale in un modello iterativo. **Problemi nella fase esplorativa** * **Problemi di dominio:** campo di esplorazione troppo ampio o troppo ristretto. * **Problemi di comprensione:** difficoltà di comunicazione tra utenti e chi raccoglie i requisiti. * **Problemi di conflitto:** stakeholder con opinioni diverse sul sistema. * **Problemi di volatilità:** requisiti che cambiano rapidamente per fattori esterni (mercato, ristrutturazioni, ecc.). **Metodologie di raccolta delle informazioni** **Interviste individuali:** * Non strutturate: esplorative, come conversazioni. * Strutturate: domande predefinite. * Semistrutturate: combinano domande libere e specifiche. **Nota:** evitare domande che influenzino l'intervistato. **Questionari:** raccolta dati in forma strutturata; utili per analisi statistiche (