6.
L’ingegneria della usabilità
Sintesi del capitolo
Questo
capitolo introduce i concetti base dell’ingegneria dell'usabilità, che saranno
approfonditi nei capitoli successivi.
Viene ricordato il tradizionale modello dei processi di progettazione e
sviluppo “a cascata” adottato inizialmente dall’ingegneria del software, e ne
viene motivato il fallimento.
Quindi, dopo avere discusso il cosiddetto ciclo compito-artefatto, si introduce
il modello iterativo di progettazione e sviluppo, e se ne discutono brevemente
vantaggi e svantaggi. Viene quindi descritto più specificamente il modello per
i processi di human-centred design proposto dallo standard ISO 13407. Dopo un
esempio di applicazione di questi concetti nella progettazione e sviluppo di
siti web, si discute brevemente la problematica del rapporto costi-benefici nell’adozione
degli approcci dell'ingegneria dell’usabilità.
Le diverse ingegnerie
Il termine ingegneria può essere definito in molti modi. Per esempio, il WordNet 2.0 Dictionary definisce l’ingegneria,
un po’ sbrigativamente, come “la disciplina che si occupa dell’arte o della
scienza di applicare la conoscenza scientifica a problemi pratici”. Più
specificamente, l’associazione degli ingegneri americani (American Engineer’s
Council for Professional Development), la definisce come
L’applicazione
creativa di principi scientifici alla progettazione o allo sviluppo di
strutture, macchine, apparati o processi di produzione, o di opere che li
utilizzano singolarmente o in combinazione; o alla costruzione o esercizio
degli stessi con piena consapevolezza del loro progetto; o alla previsione del
loro comportamento in specifiche condizioni operative; tutto ciò in relazione a
desiderate funzioni, economie di esercizio e obiettivi di sicurezza verso la vita
o la proprietà.
Queste
definizioni molto generali possono essere declinate in molti modi, in
relazione ai diversi settori di
applicazione. Per esempio, l’ingegneria
del software si occupa dei metodi e delle tecniche per la progettazione e realizzazione
di sistemi software di qualità, senza sprechi. Essa, nata negli Stati Uniti una quarantina di anni fa sulla
spinta dei grandi progetti software di origine militare[1], si è occupata, tradizionalmente, di
sistemi software molto complessi, il cui sviluppo coinvolge diecine di persone
(o più). Pertanto, non stupisce che, all’inizio, questa disciplina abbia
seguito approcci molto strutturati e formali, definendo e studiando processi di
progettazione e sviluppo organizzati in fasi predefinite, con grande enfasi sulle
attività di pianificazione e di specifica. In seguito, questi modelli si sono
profondamente evoluti, verso modelli iterativi di vario tipo, o modelli
relativamente poco strutturati e “agili”.
Più recentemente è entrato nell’uso il
termine ingegneria dell’usabilità (usability engineering), per denotare la
disciplina che studia le tecniche, i metodi e i processi che possono essere
utilizzati per progettare e sviluppare sistemi usabili.
Il termine, entrato
nell’uso soprattutto per merito del libro di Jakob Nielsen Usability Engineering, del 1994, era stato introdotto nel 1986 da
alcuni progettisti della Digital Equipment Corporation, in un’accezione che
enfatizzava fortemente un approccio quantitativo alla definizione degli
obiettivi di usabilità nella progettazione:
L’ingegneria
dell’usabilità è un processo, basato sull’ingegneria classica, che consiste
nello specificare, quantitativamente e in anticipo, quali caratteristiche e in
qual misura il prodotto finale da ingegnerizzare dovrà possedere. Questo processo
è seguito dall’effettiva realizzazione del prodotto, e dalla dimostrazione che
esso effettivamente possiede le caratteristiche pianificate. L’ingegneria non è
il processo di costruire un sistema perfetto con risorse infinite. Piuttosto,
l’ingegneria è il processo di costruire economicamente un sistema funzionante
che soddisfa una necessità. In assenza di specifiche misurabili di
usabilità, non c’è alcun modo di determinare le esigenze di usabilità di un
prodotto, o di misurare se il prodotto soddisfi o meno tali esigenze. Se non
possiamo misurare l’usabilità, non possiamo avere un’ingegneria dell’usabilità. [2]
La
parola ingegneria 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. Inizialmente, l’ingegneria dell’usabilità si è focalizzata sul
design dell’interfaccia utente dei sistemi software. Oggi, questo termine viene
usato in un’accezione più ampia, che comprende la totalità delle pratiche
utilizzate nel processo di progettazione e sviluppo dei sistemi interattivi, a
partire dalla raccolta e analisi iniziale dei requisiti. Al di là delle specifiche definizioni
ed enfasi date dai diversi autori negli anni, i principi cardine di questa
disciplina possono considerarsi ben consolidati fin dalla metà degli anni 80. In
estrema sintesi, essi si possono riassumere nei seguenti tre 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[3].
Senza
entrare in appofondimenti non rilevanti in questo contesto, poniamo a confronto
le idee essenziali dell’approccio tradizionale all’ingegneria del software (il
cosiddetto modello “a cascata”), e dell’approccio più moderno, basato su
processi di sviluppo iterativo, per prototipi successivi, adottato
nell’ingegneria dell’usabilità.
Il modello “a cascata”
Un tempo, 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. Si partiva dalla
raccolta dei requisiti, poi si definivano le specifiche del sistema da
realizzare. Quindi si progettava l’intero sistema “sulla carta” e lo si
codificava nel linguaggio di programmazione prescelto. Lo si collaudava e
infine lo si rilasciava. Si passava alla fase successiva solo quando la
precedente era completata e i suoi “prodotti” approvati formalmente dal
committente.
Si pensava che in un processo
ordinato, condotto da professionisti e guidato da un capo progetto esperto, non
si dovesse mai retrocedere. Per descrivere questo processo si usa la metafora
della cascata: come in una cascata l’acqua scorre soltanto verso il basso e non
torna mai indietro, così dalla fase iniziale di un progetto si arriva, passo
passo, al rilascio del sistema senza ritornare mai sui passi precedenti (waterfall model, Figura
1).
Figura 1.
Processo
di progettazione e sviluppo "a cascata"
Questa impostazione sembra
molto sensata, quasi ovvia: per costruire qualcosa (una casa, un ponte,
un’automobile, un sito web) 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 committente. Eppure ci si accorse ben presto
che non funzionava sempre così: nella pratica, in nessun progetto reale, anche
se ben gestito, le cose procedevano in maniera così semplice e lineare. Si
rendeva spesso necessario ritornare sui passi precedenti, per rivedere e
modificare decisioni già prese, anche se erano state ritenute assolutamente
consolidate.
Le cause potevano essere
molteplici: il committente, in fase avanzata di realizzazione, richiedeva delle
varianti che modificavano le specifiche già approvate. Oppure i progettisti
scoprivano difficoltà tecniche inattese, che consigliavano di cambiare
rotta. Oppure, ancora, magari
nella fase di rilascio del sistema, i primi utenti segnalavano delle difficoltà
nell’uso che non erano state previste da nessuno e richiedevano cambiamenti
consistenti. Tutti questi rifacimenti, non previsti nella pianificazione
iniziale, producevano costi aggiuntivi anche considerevoli. I budget
inizialmente assegnati venivano immancabilmente disattesi. Per molto tempo, queste
difficoltà furono imputate a una cattiva conduzione dei progetti. Era compito
di un buon capo progetto, si diceva, tenere a freno le richieste dei
committenti e degli utenti e far loro comprendere l’importanza di controllare
accuratamente le specifiche e di accettare che, una volta approvate, queste
dovessero essere considerate “congelate” fino al rilascio del sistema.
Con la maturazione della
disciplina dell’ingegneria del software, e dopo molti anni e molti fallimenti,
si capì che le cose non funzionavano, perché non possono funzionare
così. 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 modificare nulla. Le ragioni di questa
impossibilità sono sia di carattere pratico, sia teorico-concettuale.
Dal punto di vista pratico, è
molto difficile prevedere “sulla carta” tutti gli aspetti di un sistema
complesso, che non esiste ancora. Possiamo (e dobbiamo) tentare di farlo, ma
inevitabilmente non saremo in grado di anticipare tutti i problemi che
incontreremo durante la realizzazione, per risolvere i quali potremo essere
costretti a cambiare rotta. Queste difficoltà non si verificano soltanto nel
software, ma in progetti di ogni tipo. Pensiamo, per esempio, al progetto di
ristrutturazione di un appartamento. Anche in questo caso inizieremo con una
descrizione “sulla carta” delle opere murarie e degli impianti da realizzare.
Se il modello a cascata funzionasse bene, giunto a questo punto, il committente
potrebbe disinteressarsi del cantiere e affidarlo a un buon direttore dei
lavori, che gli consegnerà alla fine l’appartamento realizzato esattamente come
da specifiche. Chi ha fatto questa esperienza, tuttavia, sa bene che le cose
non funzionano così. Sa che, durante i lavori, s’incontrano difficoltà non
previste e non prevedibili.
Per risolvere queste difficoltà
può essere necessario cambiare le specifiche iniziali e realizzare un
appartamento diverso, per qualche aspetto, da quello progettato inizialmente.
Una soletta si rivela poco resistente e occorre rinforzarla con una putrella.
Questa impedisce il passaggio dei tubi dell’impianto di riscaldamento dove era
previsto: di conseguenza, il calorifero dovrà essere installato in un posto
diverso. Oppure, a lavori avviati, ci accorgiamo che il vicino ha l’abitudine
di ascoltare musica fino a tardi e decidiamo di insonorizzare la parete con uno
strato di materiale isolante. Questo modifica, anche se solo di pochi
centimetri, le misure della stanza e bisogna rivedere alcune decisioni sulla
posizione dei mobili. E così via: le varianti in corso d’opera potrebbero
essere diecine. Non necessariamente dovute a errori di progettazione, ma a
situazioni oggettive che non potevano essere previste e che impongono delle
modifiche senza le quali il risultato non sarebbe accettato dal committente. Il
direttore dei lavori non potrà certo rifiutarsi di realizzarle, appellandosi al
progetto iniziale regolarmente approvato.
Il ciclo compito-artefatto
C’è anche un motivo più
profondo, di natura teorico-concettuale, che fa sì che il modello a cascata non
possa funzionare. Questo motivo è racchiuso in un principio generale, che abbiamo
già incontrato varie volte (Figura 11, Capitolo 1 e, in altra forma, Figura 33,
Capitolo 4) e che possiamo enunciare nel seguente modo:
Ogni nuovo strumento cambia i
bisogni del suo utilizzatore e genera nuovi bisogni, che suggeriscono modifiche
non previste allo strumento stesso.
In altre parole, per soddisfare
le nostre necessità, produciamo strumenti che, a loro volta, generano nuovi
bisogni. Costruiamo allora nuovi strumenti, o modifichiamo quelli già
disponibili, in un ciclo evolutivo infinito, al quale è stato dato il nome di task-artifact
cycle.[4] Questo principio vale per ogni
strumento, semplice o complesso, dal cacciavite al cruscotto di un jumbo jet, a
un sistema informativo (Figura
2).
Figura 2. Il ciclo compito-artefatto
Quando definiamo i requisiti di
un prodotto che non esiste ancora e che vogliamo realizzare, lo facciamo
tenendo conto di determinati bisogni insoddisfatti. Per ottenere questo
risultato, noi progettiamo il prodotto ipotizzando
degli scenari d’uso che ci sembrano plausibili e realizzando quelle funzioni
che, nelle nostre ipotesi, ci sembrano necessarie. Anche se siamo
degli ottimi progettisti, non potremo mai essere certi di avere immaginato
correttamente come i nostri utenti utilizzeranno effettivamente il sistema
negli specifici contesti d’uso e come questo modificherà i loro bisogni. Per
verificare la correttezza delle nostre ipotesi, dobbiamo prima realizzare il
prodotto, farlo usare agli utenti e osservare come lo utilizzeranno
effettivamente, nelle diverse specifiche situazioni. Ci potremo allora
accorgere che gli scenari immaginati corrispondono quasi, ma non completamente, all’uso effettivo. Ma soprattutto
potrà capitare che l’interazione fra utente e prodotto faccia nascere nuovi
bisogni, in modi imprevisti. Tutto questo ci suggerirà di modificare il
prodotto: senza queste modifiche, i nostri utenti non saranno soddisfatti. Come
scrisse Douglas Engelbart, uno dei pionieri della human-computer interaction,
già più volte ricordato, “non appena viene introdotto un nuovo manufatto,
inizia una co-evoluzione del manufatto e di chi lo usa.”
In sostanza, non è possibile
valutare completamente l’adeguatezza dello strumento ai suoi utenti, prima che
questi lo usino effettivamente. Ecco perché il modello a cascata tradizionale
non può funzionare. Esso prevede che gli utenti siano coinvolti nel processo
solo in due momenti: all’inizio, per contribuire a requisiti e specifiche e
alla fine, dopo il rilascio (o tutt’al più per il collaudo). Tuttavia, nella stesura delle specifiche
iniziali, anche gli utenti, come i progettisti, non possono far altro che ipotizzare le caratteristiche
necessarie. Alla fine, quando la correttezza di queste assunzioni può essere
verificata in concreto, è troppo tardi per intervenire: il sistema è già stato
sviluppato.
Modelli iterativi
Se il modello a cascata è
inadeguato, ci serve un modello diverso, che coinvolga gli utenti fin da
subito, non solo nella stesura di requisiti e specifiche, ma anche, e
soprattutto, per sperimentare l’uso di versioni preliminari del sistema e
aiutarci, con le loro reazioni e le loro indicazioni, a correggere il tiro, in
un processo di prove e aggiustamenti successivi.
L’idea è di procedere con la
realizzazione di una serie di prototipi, via via più vicini al sistema
finale. S’inizia con un prototipo preliminare, realizzabile a costi ridotti, e
lo si sottopone all’utente, che prova a usarlo. Questa prima prova sarà
normalmente limitata, perché il sistema sarà molto semplificato, con funzioni
realizzate solo parzialmente, o addirittura simulate in qualche modo. Tuttavia
ci permetterà di verificare alcune assunzioni di partenza ed eventualmente di
aggiustare il tiro. Un po’ come quando un pittore schizza un bozzetto prima di
dipingere il quadro, per averne un’idea di massima ed eventualmente per farlo
approvare dal committente. Si realizza quindi un nuovo prototipo, sempre
incompleto, ma un po’ più somigliante al sistema finale e lo si sottopone
ancora alla prova degli utenti, e così via, per approssimazioni successive,
fino alla conclusione del progetto. In sostanza, le prove d’uso diventano
parte integrante del processo di progettazione. La Figura
3 mostra
una schematizzazione di questo modo di procedere.
Figura 3.
Processo
di progettazione e sviluppo per prototipi successivi
Ovviamente, nelle varie
iterazioni, le diverse attività mostrate in figura avranno pesi diversi. Per
esempio, al primo giro, dopo avere specificato i requisiti, ci si concentrerà
sulle attività di progettazione, mentre le attività di realizzazione del primo
prototipo richiederanno sforzi limitati. Il primo prototipo sarà infatti piuttosto
rudimentale: in molti casi, soltanto un mock-up
con il quale effettuare un primo confronto con gli utenti e, naturalmente, con
il committente. Questo confronto sarà condotto nella fase di test in figura. Al
giro successivo, sulla base dell’esito del confronto, si apporteranno le
necessarie modifiche ai requisiti e al progetto, e si realizzerà un secondo
prototipo, più evoluto. In questo secondo giro, lo sforzo dedicato ai requisiti
– se non sono stati evidenziati grossi problemi – sarà di solito
piuttosto limitato (serviranno solo alcuni ritocchi), mentre la realizzazione
del secondo prototipo sarà più impegnativa. Anche il test effettuato al secondo
giro, con un prototipo più evoluto, richiederà maggiori sforzi. E così via:
all’avanzare del progetto, in sostanza, lo sforzo complessivo si sposta
progressivamente dalle fasi iniziali del ciclo tradizionale (requisiti e
progettazione) alle fasi finali (test e rilascio).
In pratica, tutte le attività
rappresentate in Figura
3 vengono
portate avanti “in parallelo” per tutta la durata del progetto, ma l’impegno
dedicato a ciascuna di esse cambia nel tempo. L’avanzamento del progetto non è
più scandito dal passaggio da un’attività alla successiva, ma dalla
realizzazione dei diversi prototipi. A ogni iterazione un’attività prevale
sulle altre, ma tutte sono comunque portate avanti, anche solo per apportare le
modifiche rese necessarie dai test con gli utenti.
Questa situazione è visualizzata
nella Figura
4, che
mostra, per un progetto ipotetico, l’andamento nel tempo dell’impegno di
risorse sulle singole attività (per esempio, il numero di persone impegnate).[5]
Figura 4.
Allocazione
delle risorse secondo il modello iterativo
Il
processo di progettazione per prototipi successivi è il
modello concettualmente corretto per la realizzazione di sistemi complessi: il
prodotto si vede (anche se in modo parziale), fin dall’inizio e viene
perfezionato per incrementi successivi; le scelte effettuate possono essere
sperimentate anticipatamente e si possono scartare quelle sbagliate.
A
fronte di questi grandi vantaggi, esiste il rischio che il
processo diverga, a causa delle richieste di modifiche che nascono durante le
attività di valutazione dei vari prototipi. Per evitare queste difficoltà, per ogni progetto sarà
quindi necessario pianificare il processo iterativo di progettazione e sviluppo
in modo che, per così dire, non sfugga di mano. Si tratterò, in sostanza, di
prevedere fin dall’inizio la successione dei diversi prototipi da realizzare,
in funzione degli scopi specifici che con ciascuno di essi si desidera
raggiungere. Ovviamente, questa pianificazione dovrà tenere conto degli
obiettivi e caratteristiche del sistema da realizzare: non è possibile
stabilire un modello di processo generale, valido per tutti i sistemi, poichè
ciascun progetto ha esigenze specifiche. Alla conclusione di questo capitolo
vedremo un esempio di pianificazione dello sviluppo iterativo per i siti web.
Il modello ISO 13407
Il modello iterativo,
presentato in Figura 3 in modo del tutto generale, può essere
precisato e perfezionato in vari modi, che in questa sede non è possibile
analizzare. Nell’ambito dell’ingegneria dell’usabilità assume una particolare
autorevolezza, la descrizione che ne dà lo standard ISO 13407, dal titolo Human-centred design processes for
interactive systems, che ha proprio lo scopo, come si legge nella sua
introduzione, di “fornire una guida
alle attività di progettazione centrata sull’essere umano lungo il ciclo di
vita dei sistemi interattivi basati su computer”.
In questo standard, il modello iterativo di Figura
3 è
rappresentato, più specificamente,
come in Figura
5.
Figura 5.
Il
processo di progettazione human-centred secondo l’ISO 13407
L’ISO 13407 non descrive una
metodologia specifica (non può essere questo lo scopo di uno standard), ma
fornisce linee guida ampie dettagliate a chi desideri organizzare un processo
di progettazione human-centred. Nel
seguito di questa sezione riassumiamo la descrizione dello schema di Figura
5
contenuta nell’ISO 13407, facendo riferimento alla versione del 1999.[6]
I vari aspetti del processo di progettazione human-centred verranno quindi
ulteriormente approfonditi nei prossimi capitoli di questo libro.
Comprendere e specificare il contesto d’uso
Il contesto in cui il sistema sarà
utilizzato è definito dalle caratteristiche degli utenti, dei compiti e
dell’ambiente fisico e organizzativo. È importante identificare e comprendere i
dettagli di questo contesto, per orientare le decisioni iniziali del progetto,
e per fornire una base per la loro successiva convalida. Tutto ciò, sia che si
debba progettare un sistema nuovo, sia che si debba modificare un sistema
esistente per migliorarlo. In questo secondo caso, potranno essere molto utili
le informazioni sulle 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.
Le caratteristiche rilevanti potrebbero essere le competenze, le abilità, le esperienze, la formazione, le caratteristiche fisiche, le abitudini, le preferenze. Spesso sarà necessario classificare gli utenti in diverse categorie, per esempio in funzione dei diversi ruoli nei confronti del sistema o dei differenti livelli di esperienza.
· I compiti che gli utenti dovranno eseguire.
Dovrebbero essere analizzati i compiti che possono influenzare l’usabilità del sistema, per esempio indicandone la frequenza e durata. Si dovranno descrivere eventuali implicazioni riguardanti la salute e alla sicurezza degli utenti.
· L’ambiente nel quale gli utenti utilizzeranno il sistema.
Si descriveranno le caratteristiche rilevanti dell’ambiente fisico e sociale, includendo l’ambiente di lavoro, le tecnologie utilizzate, gli eventuali standard adottati, il contesto normativo (per esempio, le leggi e i regolamenti applicabili), la struttura organizzativa e le procedure di lavoro, le abitudini consolidate, ecc.
Lo standard ricorda esplicitamente che tutte queste descrizioni non potranno essere congelate in un documento immutabile, ma dovranno essere raccolte in un documento di lavoro, che sarà revisionato, corretto e ampliato più volte, in accordo con la natura iterativa del processo di progettazione e sviluppo. Dovranno essere sempre verificate e confermate dagli utenti del sistema, o da chi li rappresenta nel progetto.
Specificare i requisiti utente e organizzativi
Nella maggior parte dei processi di progettazione, esiste una consistente attività per la specifica dei requisiti del prodotto o del 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;
· i requisiti normativi e legislativi rilevanti, compresi quelli relativi alla sicurezza e alla salute;
· la comunicazione e la cooperazione fra gli
utenti e gli altri attori coinvolti;
· le attività degli utenti (inclusa la
ripartizione dei compiti, il benessere e la motivazione degli utenti);
· la ripartizione dei compiti fra esseri umani
e sistemi tecnologici;
· le prestazioni dei diversi compiti;
· la progettazione delle procedure di lavoro e
dell’organizzazione;
· la gestione del cambiamento, incluse le
attività di addestramento e il personale coinvolto;
· la fattibilità delle diverse operazioni,
comprese quelle di manutenzione;
· la progettazione dei posti di lavoro e la interfaccia uomo-computer.
I
requisiti e gli obiettivi dovrebbero essere stabiliti, ove necessario, operando
opportuni compromessi fra eventuali requisiti fra loro conflittuali. I
requisiti dovrebbero essere organizzati per livelli di priorità, e formulati in modo da permettere la
loro successiva convalida mediante opportuni test. Dovrebbero essere confermati
o aggiornati lungo tutta la durata del progetto.
Produrre soluzioni di progetto
In questa fase si individuano
le possibili soluzioni di progetto, basandosi sullo stato dell’arte, sulle
conoscenze ed esperienze dei partecipanti e sui risultati dell’analisi del
contesto d’uso. Lo standard identifica le seguenti attività.
· Utilizzare
le conoscenze disponibili per sviluppare proposte di progetto con un approccio
multi-disciplinare.
Esiste
un vasto corpo di teorie e conoscenze scientifiche nell’ergonomia, nella
psicologia, nelle scienze cognitive,
nelle scienze della progettazione e in altre discipline rilevanti, che
possono suggerire possibili soluzioni di progetto. Molte organizzazioni
dispongono di linee guida per l’interfaccia utente, conoscenze sul prodotto e sul
mercato che possono essere utili nelle fasi iniziali del progetto, soprattutto
quando si progettano prodotti di tipo già noto, per esempio versioni
migliorative di un sistema già in uso. Inoltre, esistono linee guida e standard
per l’ergonomia e i fattori umani, elaborati dagli enti di standardizzazione.
· Rendere le soluzioni di progetto più concrete, utilizzando simulazioni, modelli e prototipi di vario tipo.
L’uso di prototipi permette ai progettisti di comunicare più efficacemente con gli utenti, e riduce la necessità di costosi rifacimenti, che possono essere invece necessari quando il prodotto viene sottoposto a revisione soltanto più tardi nel ciclo di vita – addirittura dopo il rilascio finale agli utenti reali. Dedicheremo a questo argomento l’intero Capitolo 9.
L’attività
di prototipazione può essere compiuta in tutte le fasi del progetto, dalle
prime idee basate sulla descrizione del contesto d’uso (per esempio,
utilizzando scenari d’uso), fino ai prototipi di pre-produzione, virtualmente
completi di ogni dettaglio. Un prototipo può essere semplice quanto uno schizzo
a matita, o complesso come una simulazione su computer, quasi indistinguibile dal
prodotto reale.
· Presentare
le soluzioni di progetto agli utenti, permettendo loro di eseguire i compiti che
il sistema è destinato a supportare (eventualmente in modo simulato).
Gli utenti
possono essere coinvolti molto presto nel progetto, mediante l’uso di modelli
statici realizzati sulla carta. È possibile presentare agli utenti le bozze
delle schermate o una rappresentazione del prodotto, chiedendo loro di provarli
in un contesto realistico. In tal modo si possono valutare rapidamente ed
economicamente aspetti del progetto (per esempio, quanto sia facile navigare
attraverso una gerarchia di menu). Per i prodotti hardware, analoghi benefici
possono essere ottenuti con l’uso di modelli tridimensionali statici, costruiti
con materiali semplici. Nelle fasi iniziali, anche i prototipi più rudimentali
possono risultare preziosi, per esplorare soluzioni alternative. Anche se può
essere utile presentare le soluzioni di progetto nel modo più realistico
possibile, è consigliabile evitare di investire troppo tempo o denaro nella
loro realizzazione, anche perché ciò potrebbe produrre una resistenza alle
modifiche da parte dei progettisti.
In un
approccio human-centred, un prototipo non è semplicemente una demo per mostrare
un’anteprima del prodotto agli utenti. Esso serve a raccogliere le loro
reazioni, per poi utilizzarle nell’orientare le attività di progettazione
successive. Quando non fosse consigliabile mostrare i prototipi agli utenti all’inizio
del processo di progettazione (per esempio, per ragioni di riservatezza), le
valutazioni potranno essere condotte da esperti. Queste possono essere utili e
poco costose, e complementare i test con l’utente. In ogni caso, in un processo
di progettazione human-centred, almeno i test finali dovrebbero essere condotti
con utenti reali.
· Modificare il progetto in conseguenza delle reazioni degli utenti, e ripetere questo processo fino a che gli obiettivi della progettazione non siano raggiunti.
La natura dei prototipi e il numero delle iterazioni variano in funzione di numerosi fattori, fra cui l’importanza attribuita alla qualità del progetto finale. Nello sviluppo di software, si può iniziare presentando sulla carta degli schizzi delle schermate, e proseguire attraverso diverse iterazioni, fino a produrre software interattivo con funzionalità sufficienti a supportare un sottoinsieme dei compiti dell’utente. Nelle fasi avanzate della progettazione, i prototipi potranno essere valutati in contesti più realistici. Per ottenere i massimi benefici, è conveniente effettuare numerose iterazioni con l’utente. In seguito, per decidere se gli obiettivi complessivi sono stati raggiunti, dovrebbero essere condotte delle valutazioni più formali in un contesto realistico, per esempio, senza suggerimenti o interruzioni da parte del valutatore. I commenti dell’utente, o le difficoltà osservate durante l’utilizzo del prototipo, suggeriranno modifiche al progetto, per migliorarne l’usabilità. In qualche caso, questi feedback potranno anche essere di aiuto per raffinare gli obiettivi complessivi del sistema.
· Gestire l’iterazione delle soluzioni di progetto.
Per tenere sotto controllo i progressi della progettazione iterativa, si dovrebbero registrare i risultati delle attività precedenti. Questa documentazione potrà essere esclusivamente descrittiva, o includere i prodotti stessi della progettazione, come i prototipi hardware e software. La documentazione descriverà lo scopo dei vari prototipi, le modalità operative del loro utilizzo e i problemi individuati, con le conseguenti modifiche del progetto.
Valutare il progetto nei confronti dei requisiti.
La valutazione è un passo
essenziale in una progettazione human-centred, e dovrebbe essere compiuta in
tutte le fasi del ciclo di vita del sistema, e non soltanto in fase di
progettazione. All’inizio del progetto, l’obiettivo principale sarà la raccolta
d’indicazioni per orientare le attività di progettazione successive. Nelle fasi
più avanzate, con la disponibilità di prototipi più completi, sarà invece possibile
quantificare il livello di raggiungimento degli obiettivi dell’utente e
dell’organizzazione. Dopo il rilascio del sistema, sarà possibile monitorarne
l’adeguatezza ai nuovi contesti di utilizzo.
Lo standard identifica le
seguenti attività:
· Produrre
il piano di valutazione
Il
processo di valutazione dovrebbe essere pianificato, precisando, tra l’altro,
quali parti del sistema devono essere valutati e come; quali prototipi dovranno
essere realizzati e come deve essere eseguita la valutazione e con quali
risorse; quali dovranno essere le interazioni con gli utenti e come dovrà
essere condotta l’analisi dei risultati. 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
Per influenzare la progettazione, la valutazione dovrebbe essere condotta in ogni fase del ciclo di vita del sistema. La valutazione condotta soltanto da esperti, senza il coinvolgimento degli utenti, può essere veloce ed economica, e permettere di identificare i problemi maggiori, ma non basta a garantire il successo di un sistema interattivo. La valutazione basata sul coinvolgimento degli utenti permette di ottenere utili indicazioni in ogni fase della progettazione. Nelle fasi iniziali, gli utenti possono essere coinvolti nella valutazione di scenari d’uso, semplici mock-up cartacei o prototipi parziali. Quando le soluzioni di progetto sono più sviluppate, le valutazioni che coinvolgono l’utente si basano su versioni del sistema progressivamente più complete e concrete. Può anche essere utile una valutazione cooperativa, in cui il valutatore discute con l’utente i problemi rilevati.
· Verificare se gli obiettivi sono stati raggiunti
La valutazione può essere usata per dimostrare che un
particolare progetto soddisfa i requisiti human-centred, oppure per verificare
la conformità a standard internazionali, nazionali, locali, aziendali o legali.
In ogni caso, per ottenere risultati validi, la valutazione dovrebbe utilizzare
metodi appropriate, con un campione rappresentativo di utenti che eseguono
compiti realistici.
· Validazione sul campo
Lo scopo della validazione 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. A questo scopo si possono analizzare i dati raccolti dall’help desk, rapporti dal campo, feedback da utenti reali, dati prestazionali, rapporti sull’impatto sulla salute, richieste di miglioramenti e di modifiche da parte degli utenti.
· Monitoraggio di lungo termine
Dovrebbe esistere un processo pianificato per il monitoraggio di lungo termine dell’uso del prodotto o del sistema, che consiste nel raccogliere input dagli utenti, con modalità differenti, lungo un certo periodo di tempo. Infatti, alcuni effetti dell’utilizzo di un sistema interattivo non sono riconoscibili fino a che il sistema non sia stato utilizzato per un certo periodo di tempo, e ci possono essere effetti che derivano da fattori esterni, per esempio da cambiamenti imprevisti nelle modalità lavorative o nel contesto di mercato.
· Documentazione dei risultati
Allo scopo di gestire il processo di progettazione iterativo, i risultati delle valutazioni dovrebbero essere registrati in modo sistematico. In particolare, dovrebbe esistere un’adeguata evidenza che un numero adeguato di utenti abbia partecipato al test e che questi utenti siano rappresentativi delle categorie identificate nei requisiti, che i test effettuati siano adeguati a fornire indicazioni attendibili per i vari casi e contesti d’uso e, infine, che siano stati usati metodi appropriati per il test e la raccolta dei dati.
Il ruolo dell’utente nel processo di progettazione
Come si è già osservato, il modello dell’ISO 13407 è del
tutto generale, e può essere realizzato concretamente in molti modi diversi. In
effetti, sono stati definiti e applicati vari approcci che, pur rientrando
tutti nell’ambito di un’impostazione human-centred, differiscono fra loro nei
dettagli e, soprattutto, nel ruolo che l’utente assume durante il processo
della progettazione. Infatti, a seconda delle scelte organizzative, l’utente
può essere coinvolto secondo modalità diverse nelle varie attività del
processo, indicate con A, B, C e D in Figura 6.
Figura 6. L’utente può essere coinvolto in una o più attività del processo di progettazione human-centred
L’approccio più conosciuto è noto come progettazione centrata sull’utente, o user-centred design (UCD), proposto da Norman e Draper un quarto di
secolo fa.[7] Secondo questa
impostazione, l’utente viene sostanzialmente coinvolto solo nelle fasi A e C
della Figura
6.
Pertanto, ha un ruolo fondamentale nell’acquisizione dei requisiti del
sistema (A) e nell’effettuazione delle prove d’uso dei diversi prototipi prodotti nelle varie iterazioni del
progetto (C). Non è, invece, coinvolto nelle attività di progettazione e
realizzazione dei vari prototipi (B), condotte dai progettisti e dagli
sviluppatori del sistema.
In
altri approcci, il coinvolgimento dell’utente avviene con modalità diverse. Per
esempio, nella progettazione partecipativa (participatory
design, inizialmente chiamato cooperative design), l’utente viene
coinvolto anche nelle attività di progettazione (B), partecipando attivamente,
con modalità e strumenti opportuni, alla realizzazione dei prototipi. Al
contrario, nello usage-centred design,
proposto da Constantine e Lockwood[8], il centro
dell’attenzione è sull’uso – cioè sulle attività effettuate dall’utente e
sui compiti che egli compie – e non sull’utente, che viene coinvolto nel
processo di progettazione in modo molto limitato.
Questo libro adotta un’impostazione pragmatica, basata
sostanzialmente sulla filosofia dello user-centred design, ma interpretato in
modo flessibile. Infatti, se è vero che l’utente costituisce una fonte
importantissima d’informazioni per la stesura dei requisiti e un attore
primario nella convalida dei prototipi via via realizzati, è tuttavia
indispensabile che i suoi desideri e suggerimenti non siano interpretati come dictat
assoluti. L’utente non è un progettista -
non ne ha l’esperienza né la forma mentis. In molti casi, può non essere
in grado di valutare le implicazioni di suggerimenti che, visti fuori dal
contesto del progetto, potrebbero sembrare del tutto corretti. Può capitare
infatti che alcuni suggerimenti, se attuati, producano degli effetti
collaterali indesiderabili. Oppure, semplicemente, che esistano altri modi, più
convenienti, di ottenere gli stessi risultati. Il progettista esperto, invece, è
in grado di valutare le implicazioni delle indicazioni degli utenti, e di
comprenderne le eventuali controindicazioni.
Chiunque abbia avuto un’esperienza, sia pur modesta, di
progettazione in contesti reali, sa che cosa significa dover “lottare” con i
suoi utenti, per correggere indicazioni che sa fondamentalmente sbagliate. Un
aspetto importante da tenere in considerazione è la naturale resistenza al
cambiamento negli utenti. Le persone non amano cambiare abitudini e modalità
operative, e la prospettiva di dover modificare il proprio modo di lavorare
genera spesso delle resistenze. Ciò fa sì che raramente prodotti realmente
innovativi, che modificano radicalmente le abitudini operative consolidate,
siano proposti dai loro futuri
utenti. Questi prodotti nascono più dalle visioni di designer innovativi
che da proposte originate dai futuri utenti.
Lo stesso Donald Norman, autore della filosofia
user-centred, ha sentito la necessità, più recentemente, di correggere il tiro
spostando l’enfasi dall’utente alle sue attività, in un approccio da lui
chiamato activity-centred design:
Una filosofia di base dello human-centred design è ascoltare
gli utenti, e prendere le loro lamentele e le loro critiche sul serio. Sì,
ascoltare i clienti è sempre saggio, ma accettare le loro richieste può
condurre a progetti eccessivamente complessi. Parecchie grandi società di
software, orgogliose della loro filosofia human-centred, soffrono di questo
problema. Il loro software diventa più complicato e meno comprensibile a ogni nuova
revisione. La filosofia activity-centred tende a proteggerci da questo errore
perché si focalizza sulle attività, non sull’essere umano. Ne risulta un
modello di progetto coerente e bene articolato. Se un suggerimento dell’utente
non rientra in questo modello, dovrebbe essere scartato. Ahimè, troppe società,
orgogliose di ascoltare i propri utenti, lo accetterebbero. Qui, ciò che serve
è un progettista forte e autorevole in grado di esaminare i suggerimenti e
valutarli nei termini dei requisiti dell’attività. Quando è necessario, è
essenziale poter ignorare le richieste. Questo per conseguire coerenza e
comprensibilità. Paradossalmente, il modo migliore di soddisfare gli utenti è,
qualche volta, di ignorarli. […]
A volte ciò che serve è un dittatore che dica “ignorate ciò
che dicono gli utenti: io so ciò che è meglio per loro.” Il caso della Apple è
esemplificativo. I prodotti della Apple sono stati a lungo ammirati per la loro
facilità d’uso. Tuttavia, la Apple ha sostituito il suo famoso e rispettato
team di progetto con un unico, autorevole (dittatoriale) leader. L’usabilità ne
ha sofferto? Al contrario: i suoi nuovi prodotti sono considerati esempi di
grande design. “Ascolta i tuoi utenti” produce design incoerenti. “Ignora i
tuoi utenti” può produrre storie di orrore, a meno che la persona alla guida
abbia una chiara visione del prodotto, ciò che ho chiamato “modello
concettuale”. La persona alla guida deve seguire quella visione e non temere di
ignorare i fatti. Sì, ascoltate i clienti, ma non fate sempre quello che
dicono. [9]
E conclude:
Lo human-centred design garantisce buoni prodotti. Può
condurre a netti miglioramenti di prodotti cattivi. Inoltre, lo human-centred
design evita i fallimenti. Assicura che i prodotti funzionano, che la gente li
può usare. Ma è un buon design lo scopo? Molti di noi desiderano un design
grande. Il design grande, io affermo, deriva dalla rottura delle regole,
dall’ignorare le pratiche generalmente accettate, dal procedere con un chiaro
concetto del risultato finale, non importa quale. Questo design egocentrico e
guidato dalla visione conduce a grandi successi o a grandi fallimenti. Se lo volete
grande piuttosto che buono, questo è ciò che dovete fare.
L’esempio dei siti web
Gli schemi di Figura 3 o Figura
5 sono
ancora troppo astratti per essere realmente utili in un progetto reale. Infatti
nulla ci dicono su come procedere, in pratica, nel caso specifico. Quanti
prototipi (e quindi quante iterazioni) dobbiamo realizzare? Quali obiettivi ci
dobbiamo porre nella realizzazione e nella valutazione di ciascun prototipo? Quali
tecniche di prototipazione dobbiamo utilizzare? Come possiamo realizzarli a
costi ridotti? Come possiamo tenere sotto controllo i costi complessivi del
progetto? A queste domande non è
possibile rispondere in generale, e cioè in modo indipendente dal tipo e dalle
caratteristiche del sistema in oggetto. È, invece, possibile mettere a punto
specifiche strategie per specifiche classi di sistemi.
Per
esempio, è possibile dare indicazioni molto precise su come impostare il
processo di progettazione e sviluppo di un sito Web, specificando quanti
prototipi è conveniente realizzare, in quali fasi, con quali tecnologie e con
quali obiettivi specifici, da valutare attraverso specificate attività di test.
A questo argomento è dedicato un altro libro di chi scrive.[10] Rimandando il lettore interessato a questo libro per
approfondimenti, ci limitiamo qui a indicare che, in questo caso, il processo
iterativo user-centred si può convenientemente sviluppare in sette macrofasi,
con cinque prototipi principali, ciascuno dei quali ha tecniche realizzative e
finalità specifiche (Figura 7).
Figura 7. Processo iterativo per la progettazione e sviluppo di un sito web
In sintesi, dopo la fase di realizzazione del documento dei
requisiti e di avviamento del progetto (il cui documento finale è denominato
Piano di qualità), vengono realizzati i seguenti prototipi:
· Primo prototipo (prototipo di navigazione): ha lo scopo di consolidare l’architettura informativa e di navigazione del sito. Permette all’utente di vedere l’ossatura del sito (ancora privo di grafica e di contenuti informativi, ma dotato delle strutture di navigazione principali, per esempio i menu), e di navigare al suo interno.
· Secondo prototipo (prototipo di comunicazione): ha lo scopo di consolidare l’impostazione grafica del sito e tutti gli aspetti riguardanti la comunicazione. Mancano ancora del tutto i contenuti informativi e le funzioni interattive, ma la cornice grafica è quella finale.
· Terzo prototipo (prototipo funzionale): ha lo scopo di consolidare le funzioni interattive del sito. I contenuti informativi sono ancora assenti, ma il “contenitore” è sostanzialmente pronto, e l’utente può provarne le funzioni interattive, sia pure in un contesto ancora lontano da quello reale.
· Quarto prototipo (prototipo editoriale): ha lo scopo di consolidare i contenuti informativi e la (eventuale) base dati del sito. Il sito è praticamente pronto: i test con l’utente possono svolgersi in un ambiente completo e realistico, anche se su sistemi di sviluppo, e non di produzione.
· Quinto prototipo (prototipo finale): ha lo scopo di permettere di valutare le prestazioni di funzionamento del sito sui sistemi finali di produzione.
Naturalmente,
le prove effettuate su ciascun prototipo potranno suggerire delle iterazioni,
come indicato dalle frecce all’indietro in Figura 7. Normalmente, se il
processo è condotto bene, questi ricicli saranno sostanzialmente confinati
all’interno della macro-fase corrente. Così, per esempio, le prove d’uso del
prototipo di comunicazione produrranno aggiustamenti nella grafica, con
successive iterazioni all’interno della fase 4 in figura, ma solo di rado
richiederanno modifiche alle fasi precedenti (prototipo di navigazione e
requisiti). In questo modo, per così dire, il modello iterativo di Figura 3 o Figura 5 viene, per così dire, sostanzialmente linearizzato, assomigliando, se
tutto va bene, al modello “a cascata”, con notevoli benefici in termini di
controllo dei costi e qualità del risultato finale.
Le professioni dell’usabilità
Nel contesto
dei processi dell’ingegneria dell’usabilità, alcune professionalità
specifiche assumono un ruolo
rilevante. Esse possono venire raccolte sotto la generica etichetta di usability professional, come propone
l’associazione internazionale dei professionisti dell’usabilità (UPA, Usability Professional Association),
che, nel suo sito web (www.upassoc.org),
definisce usability professional…
...in
generale, chiunque lavori per la usabilità di un prodotto, o ne sia un promotore. Alcuni si specializzano nel condurre
test o ricerche sugli utenti, mentre altri praticano l’usabilità come parte
delle loro attività di progettazione di prodotti, servizi, applicazioni
software o siti web.
La formazione e il background professionale dei
professionisti dell’usabilità è altrettanto ampia. Aggiunge infatti la UPA, che
“molti hanno qualifiche in campi strettamente correlati, come la interazione
uomo-macchina (HCI), l’information design o la psicologia. Altri hanno usato il
loro background nella computer science, nel project management, nel
giornalismo, nelle arti, nelle scienze bibliotecarie, o nel business come parte
del loro viaggio verso questa professione.”
Lo spettro di attività nelle quali trova impiego un
professionista dell’usabilità è altrettanto ampio. La stessa UPA, nel suo sito
(che fa specifico riferimento al modello di progettazione dell’ISO 13407 sopra
descritto), menziona le seguenti attività, ripartite fra le fasi del progetto:
In fase
di analisi:
· incontrare gli stakeholder[11] per impostare la visione;
· inserire nel piano di progetto le attività relative all’usabilità;
· organizzare un team multidisciplinare per assicurare un’esperienza completa;
· sviluppare gli obbiettivi di usabilità;
· condurre studi sul campo;
· esaminare prodotti concorrenti;
· creare i profili degli utenti;
· sviluppare analisi dei compiti;
· documentare scenari d’uso;
· documentare i requisiti relativi alle prestazioni degli utenti.
In fase di progettazione:
· effettuare brainstorming sui design concept e sulle metafore;
· sviluppare le sequenze di schermate e i modelli di navigazione;
· revisionare i design concept;
· avviare il progetto con carta e matita;
· creare prototipi a bassa fedeltà;
· condurre test di usabilità su prototipi a bassa fedeltà;
· creare il design di dettaglio per i prototipi ad alta fedeltà;
· effettuare ancora i test di usabilità;
· documentare standard e linee guida;
· creare specifiche di progetto.
In fase di realizzazione:
• effettuare valutazioni durante il processo;
• lavorare a stretto contatto con il team di sviluppo per la rifinitura del design;
• condurre test di usabilità quanto prima possibile.
In fase di avviamento:
• utilizzare questionari per ottenere feedback dagli utenti;
• condurre studi sul campo per ottenere informazioni sull’utilizzo effettivo;
• verificare il raggiungimento degli obiettivi per mezzo di test di usabilità.
Considerando la varietà dei temi
trattati, i professionisti dell’usabilità costituiscono una popolazione
piuttosto variegata, in funzione delle specifiche competenze. Le
specializzazioni più diffuse, ancora secondo la UPA, sono:
- User Experience Practitioner
- Interface Designer
- Usability Practitioner
- User-Centred Design
Practitioner
- Information Architect
- Usability Manager
Altre professioni strettamente
collegate, sempre secondo l’UPA, includono quelle di:
- Web Designer
- Technical Writer
- Business or Requirements
Analyst
- Technical or Software Analyst
- Market Researcher
- Instructional Designer
- Industrial Designer.
Costi e benefici
Nei paragrafi precedenti
abbiamo illustrato le attività necessarie per la progettazione e realizzazione
di sistemi usabili. Da quanto detto è evidente che l’usabilità non nasce “per
caso”. Essa va accuratamente pianificata, progettata e monitorata durante tutto
l’arco del progetto, utilizzando risorse e attività specifiche, secondo i metodi
dell’ingegneria dell’usabilità. Tutto questo, ovviamente, ha dei costi. È
naturale, quindi, chiedersi quale sia il rapporto fra i costi e i benefici
ottenibili.
I costi sono essenzialmente di
due tipi. Innanzitutto, ci sono i costi dell’investimento necessario per
trasformare un’organizzazione di progetto tradizionale in un’organizzazione che
utilizza i metodi dell’ingegneria dell’usabilità. Questo richiede attività di
addestramento (per i progettisti e i responsabili di progetto) e reclutamento
di nuove risorse (per esempio, consulenti esperti di usabilità) da inserire in
quei team di progetto multi-disciplinari di cui abbiamo parlato nel Capitolo 3.
Si tratta quindi di gestire un cambiamento organizzativo e culturale, che nel
caso di grandi organizzazioni di progetto potrebbe essere non banale, e
richiedere una prima fase di sperimentazione attraverso progetti pilota. Come
si possono quantificare i ritorni di questi investimenti?
In secondo luogo, supponendo di
considerare un’organizzazione che sappia già fare dell’ingegneria
dell’usabilità, ci sono i costi
delle specifiche attività finalizzate all’usabilità, e che non verrebbero
eseguite in un processo d’ingegneria tradizionale. Come quantificarne il rapporto
costi/benefici? Com’è del tutto evidente, non si tratta di un’operazione
banale. Come osserva Nielsen, il modo più corretto per quantificare il rapporto
costi/benefici sarebbero quello di realizzare due versioni “equivalenti” dello
stesso prodotto, in un caso senza porre in essere alcuna attività specifica
finalizzata all’usabilità, e nell’altro adottando un processo di progettazione
centrato sull’utente, tenendo traccia dei costi complessivi di progettazione in
ciascuna situazione. In seguito, si dovrebbero far utilizzare in contesti
simili entrambi i prodotti per un periodo di tempo sufficientemente lungo e da
parte di un numero significativo di utenti, misurandone l’usabilità, per
esempio definendo opportune metriche di efficacia, efficienza e soddisfazione,
come abbiamo visto nel Capitolo 1, che si possano tradurre in termini
economici. Per esempio, per quanto riguarda l’efficienza, potremmo quantificare
i tempi medi di esecuzione dei vari compiti in entrambi i casi, valorizzando il
tempo sulla base del costo medio del personale utilizzato. Dovremmo,
ovviamente, considerare nei due casi sia i tempi di apprendimento dei prodotti,
sia i tempi richiesti dal loro uso a regime. Per quanto riguarda l’efficacia,
potremmo poi considerare la frequenza degli errori d’uso in un caso e
nell’altro, e tradurre ancora una volta questi dati in termini economici.
Infine, per quanto riguarda la soddisfazione dell’utente, dovremmo compiere
delle indagini attraverso questionari, ed eventualmente formulare delle
ipotesi, da tradurre ancora una volta in termini economici, sul mercato
potenziale di ciascun prodotto sulla base del gradimento medio.
Tutto questo non è
evidentemente realizzabile in pratica e, anche se lo fosse, le variabili
coinvolte nell’esperimento sono così numerose da renderne comunque le
conclusioni piuttosto discutibili. È tuttavia possibile, e relativamente poco
costoso, condurre per così dire degli “esperimenti concettuali”, quantificando,
sotto opportune ipotesi, i potenziali guadagni di una migliorata usabilità. I
risultati saranno ipotetici, certamente opinabili ma, nel caso di prodotti
destinati a un mercato di massa, spesso convincenti, almeno in termini di
benefici “sociali”.
Per esempio, proviamo a
ipotizzare, per un certo prodotto (per esempio un sistema di word
processing), una determinata Riduzione
del Tempo di Apprendimento medio (RTA), dovuta a una migliorata usabilità, e
una determinata Riduzione del Tempo medio di Esecuzione di un certo compito
importante e frequente c (RTMc), dovuta sia a un’interazione più
agevole, sia a una riduzione statistica del numero degli errori effettuati
dall’utente. Se ipotizziamo, anche senza condurre analisi raffinate, che RTA=4h
(mezza giornata lavorativa) e che RTMc = 10 secondi, e se
ipotizziamo che il compito c venga eseguito, in media, 1 volta al giorno, su
una popolazione di 100.000 utenti il risparmio nel primo anno di utilizzo del
prodotto sarebbe:
(4h x
100.000) + (10 sec x 365gg x 100.000) =circa 400.000h + 100.00h = 500.000h.
Questo corrisponde a un
risparmio complessivo, sulla popolazione considerata, di circa 62.500 giornate
lavorative ovvero, considerando 200 giornate lavorative medie annue pro-capite,
un risparmio di tempo di circa il 3 per mille. Poiché le ipotesi fatte sono del
tutto ammissibili anche senza analisi particolarmente raffinate (e con un
atteggiamento di cautela), il risparmio “sociale” è certamente significativo.
Ovviamente, questo dato non è necessariamente d’interesse per il produttore o
il venditore, che considerano in primo luogo costi e benefici in relazione al
suo bilancio.
Certamente, tuttavia, è
possibile effettuare altri esperimenti concettuali, per quantificare benefici
che più direttamente impattano sul conto economico del produttore. Le voci che
potrebbero essere considerate sono numerose, a partire dai benefici ottenibili già in fase di
progettazione fino ai benefici risultanti da una migliore accoglienza del
prodotto da parte del mercato, per esempio:
· Riduzione dei costi complessivi di progettazione e sviluppo, derivanti da minori rifacimenti o modifiche del prodotto nelle fasi finali del progetto, dovuti all’utilizzo di processi di progettazione iterativi, che permettono di anticipare i problemi di usabilità – e le loro soluzioni. È noto, infatti, che i costi delle modifiche di un prodotto sono tanto maggiori quanto più tali modifiche avvengono nelle fasi finali del progetto, o addirittura dopo il suo rilascio agli utilizzatori.
· Riduzione dei costi di manutenzione, per gli stessi motivi.
· Riduzione dei costi di supporto all’utente, in termini di formazione all’uso e documentazione tecnica più semplici e quindi meno costose e, soprattutto, di supporto post-vendita (es. help desk e assistenza tecnica).
· Maggiore soddisfazione dell’utente, con conseguente miglioramento dell’immagine del prodotto e della credibilità del fornitore sul mercato e, di conseguenza, un incremento dei volumi di vendita.
In conclusione, non è difficile
condurre esperimenti concettuali anche piuttosto raffinati nell’ambito di
prodotti specifici, per sostenere la tesi che una buona usabilità, effettivamente,
ripaga. Esistono peraltro, in letteratura, numerose ricerche che, nell’ambito
di specifici prodotti, forniscono dati convincenti a supporto di queste
affermazioni. Tuttavia è convinzione di chi scrive che tali quantificazioni non
colgano il punto essenziale. I benefici dell’usabilità vanno ben oltre i
risparmi strettamente quantificabili sul conto economico delle aziende. In un
contesto che si fa sempre più complesso, come accennato nell’introduzione,
l’usabilità è un attributo importante, che migliora la qualità della vita degli
utenti e riduce l’entità e le conseguenze del digital divide. Perseguire l’usabilità significa cercare di
costruire un mondo a misura d’uomo e non delle macchine, in cui si viva e si
lavori meglio, che minori sprechi di risorse e con più soddisfazione.
Ripasso
ed esercizi
1. Spiega
che cosa s’intende per ingegneria dell’usabilità.
2. Spiega
quali sono, a tuo parere, i rapporti fra l’ingegneria del software e
l’ingegneria dell’usabilità.
3. Quali
sono i vantaggi e gli svantaggi del modello tradizionale di progettazione e
sviluppo “a cascata”?
4. Quali
sono i vantaggi e gli svantaggi del modello di progettazione e sviluppo per
prototipi successivi?
5. Spiega
che cosa s’intende con “ciclo
compito-artefatto”.
6. Quali
sono le principali caratteristiche del modello di progettazione human-centred
proposto dall’ISO 13407?
7. Che
cosa s’intende per user-centred design?
8. Analizza l’interfaccia utente di Facebook, e
identifica qualche semplice miglioramento auspicabile, quantificandone, in modo
approssimato, il rapporto costi/benefici di tale intervento.
Approfondimenti e ricerche
1. Per approfondire i modelli dei processi di progettazione e sviluppo definiti nell’ambito dell’ingegneria del software puoi consultare uno dei molti libri introduttivi all’argomento, per esempio il classico testo di I.Sommerville, Ingegneria del software (Ottava edizione), Pearson Addison-Wesley, 2007.
2. Lo standard ISO 13407 si trova in rete in http://www.iso.org. Purtroppo è accessibile soltanto a pagamento.
3. Leggi la nota di Norman su Human-Centred Design Considered Harmful,
citata nel presente capitolo (disponibile in rete, in htto://www.jnd.org).
4.
La letteratura disponibile sull’analisi dei costi e
benefici dell’usabilità è vasta, a partire dall’importante libro a cura di R.Bias e D.J.Mayhew, Cost Justifying Usability (Morgan Kaufmann,
1994, seconda edizione nel 2005). Anche in rete esiste abbondante
materiale. Puoi approfondire l’argomento, per esempio, partendo dal sito della
UPA http://www.upassoc.org, oppure da
http://www.usabilityfirst.com dove ci
sono sezioni dedicate all’argomento, oppure cercando in rete “usability ROI”,
dove ROI sta per “Return Of Investment”. Nel sito di Jakob Nielsen http://www.useit.com ci sono interessanti note
sull’argomento, in relazione all’usabilità dei siti web. Tieni comunque
presente che molto materiale presente in rete ha scopo promozionale, e che
spesso le metodologie utilizzate nell’analisi costi/benefici sono approssimate.
Può essere utile leggere le considerazioni di buon senso nell’articolo di Daniel Rosenberg, The miths of usability ROI, in ACM
Interactions, vol.5, 11 (settembre-ottobre 2004).
5.
Puoi divertirti a condurre esperimenti concettuali sul
ritorno degli investimenti sulla usabilità di siti web di e-commerce
utilizzando lo “usability ROI calculator” disponibile online in http://www.usereffect.com/topic/new-tool-usability-roi-calculator.