Non esiste una linea comune sulla definizione di cosa costituisce una progettazione incentrata sull'utente. Tuttavia,
John Gould ed i suoi colleghi in IBM hanno sviluppato un approccio negli anni 80 denominato Progettazione per
l'utilizzabilità [GOU88], che comprende
la maggior parte delle definizioni comunemente accettate. Si è sviluppato dall'esperienza pratica su diversi sistemi
interattivi, il più noto il sistema IBM di messaggistica delle olimpiadi del 1984 (IBM Olympic Messaging System) [GOU87]. L'approccio è formato da quattro componenti principali, descritti di
seguito.
Gould suggerisce che gli sviluppatori devono decidere chi saranno gli utenti e di coinvolgerli alla prima
opportunità possibile. Suggerisce diversi modi per familiarizzare con gli utenti, le loro attività ed i loro
requisiti:
· Parlare con gli
utenti.
|
· Visitare le ubicazioni
del cliente.
|
· Osservare gli utenti che
lavorano.
|
· Videoregistrare gli
utenti che lavorano.
|
· Informarsi
sull'organizzazione del lavoro.
|
· Mettersi alla
prova.
|
· Fare in modo che gli
utenti pensino ad alta voce mentre lavorano.
|
· Progettazione
partecipativa.
|
· Includere gli utenti
esperti sul team di progettazione.
|
· Eseguire un'analisi
dell'attività.
|
· Utilizzare le
valutazioni e i questionari.
|
· Sviluppare obiettivi
testabili.
|
Nel RUP (Rational Unified Process), i workshop vengono utilizzati in diverse fasi chiave, ma
devono essere completati dai tipi di attività descritte da Gould, qualora si desiderasse creare una descrizione
precisa. (Fa parte dell'argomento anche il fatto che la gente descrive spesso le proprie azioni in modo abbastanza
diverso rispetto al modo in cui le esegue. Le attività comunemente eseguite e i dettagli apparentemente insignificanti
come la collocazione del lavoro o l'esistenza di "misteriosi" pezzi di carta vengono spesso dimenticati o omessi perché
non fanno ufficialmente parte del processo corrente).
Si consiglia di eseguire le attività di utilizzo in parallelo all'inizio dello sviluppo. Tali attività includono
la creazione di bozze dell'interfaccia utente e delle guide per l'utente o della guida in linea. Gould sottolinea
inoltre che l'utilizzabilità dovrebbe essere responsabilità di un gruppo.
Una caratteristica importante della progettazione integrata è che l'approccio generale - il framework - per
la progettazione dell'interfaccia utente dettagliata viene sviluppato e testato in una fase iniziale. Questa è
una differenza importante tra la progettazione incentrata sull'utente e altre tecniche puramente incrementali. Essa
assicura che la progettazione incrementale attuata in fasi successive si adatta facilmente al framework e che
l'interfaccia utente sia consistente in aspetto, terminologia e concetto.
All'interno del RUP, è possibile stabilire questo framework utilizzando un modello di dominio per assicurare che
tutta la terminologia e i concetti che verranno visualizzati nell'interfaccia utente sono conosciuti e vengono compresi
all'interno del business in generale e dagli utenti in particolare. (Vi saranno anche sottoserie del modello di dominio
rilevanti solo per specifici gruppi di utenti. Prestare attenzione per assicurare che il modello del dominio sia
organizzato in modo che tali sottoserie possano essere identificate con facilità). Con l'avanzamento della
progettazione dell'interfaccia utente, molte delle classi di dominio verranno rappresentate come elementi
dell'interfaccia utente. Tali elementi e le relazioni tra di loro dovrebbero essere coerenti con il modello del dominio
e dovrebbero essere rappresentati coerentemente per tutte le parti del sistema in fase di progettazione. (In questo
modo non solo si fornisce assistenza agli utenti, ma si migliora anche il riutilizzo dei componenti dell'interfaccia
utente).
Verifica iniziale dell'utente indica la creazione iniziale di uno storyboard e lo sviluppo iniziale dei prototipi
poco fedeli. I prototipi più fedeli compariranno in un secondo momento del processo.
E' possibile utilizzare gli storyboard insieme ai casi d'uso per scrivere scenari concreti da utilizzare per il sistema
in fase di progettazione. Tali storyboard possono acquisire il formato narrativo o narrativo illustrato (utilizzando i
modelli dell'interfaccia utente come esempi). Essi, insieme ai sondaggi (con gli utenti) e ai gruppi di focalizzazione
degli utenti, sono approcci che potrebbero non risultare familiari per molti sviluppatori di software. Tuttavia, sono
chiaramente più efficaci in termini di costi rispetto alla rilevazione di una progettazione inappropriata o dei
requisiti fraintesi una volta che l'implementazione è in corso.
Lo sviluppo OO (Object-oriented) è diventato sinonimo di un processo iterativo. La progettazione iterativa è
adatta a problemi che necessitano di un perfezionamento di conoscenza e presentano requisiti mutevoli. Senza alcuna
sorpresa, la progettazione iterativa è un componente chiave della progettazione incentrata sull'utente. Ciò è, in
parte, dovuto alle esigenze variabili degli utenti nel tempo, ma anche alla complessità inerente della produzione di
soluzioni di progettazione che possano soddisfare diverse richieste.
Tenere presente che in metodi incentrati sull'utente, le progettazione iterativa avviene all'interno di un
framework integrato. Viene deliberatamente evitato uno sviluppo incrementale, al di fuori di un framework concordato,
che potrebbe condurre a una soluzione temporanea.
I sistemi interattivi affidano il proprio successo alla capacità di soddisfare le esigenze degli utenti. Ciò significa
non solo identificare diverse comunità di utenti, ma anche riconoscere la gamma di skill, esperienza e preferenze dei
singoli.
Sebbene sia allettante per sviluppatori e responsabili percepire di avere compreso le esigenze dell'utente, ciò avviene
raramente nella pratica. L'attenzione è, spesso, incentrata sul modo in cui gli utenti dovrebbero eseguire le
attività, anziché su come preferiscono farlo. In diversi casi, la questione delle preferenze è molto più che
avere il pieno controllo, sebbene sia importante in se stessa. La preferenza verrà anche determinata dall'esperienza,
dalla capacità e dal contesto d'uso. Tali questioni sono considerati sufficientemente importanti per il processo di
progettazione, al fine di garantire uno standard internazionale, [ISO 13407],
intitolato human-centered design processes for interactive systems. Le questioni standard e correlate vengono
discusse in termini generali nel resto della presente pagina.
Gli utenti comprendono e interagiscono con un sistema tramite la relativa interfaccia utente. I concetti, le immagini e
la terminologia presentata nell'interfaccia deve essere adeguata alle esigenze degli utenti. Ad esempio, un sistema che
consenta ai clienti di acquistare i propri biglietti sarà completamente differente rispetto a uno utilizzato
professionalmente dallo staff di vendita dei biglietti. Le differenze principali non sono nei requisiti o nei casi
d'uso dettagliati, ma nelle caratteristiche degli utenti e negli ambienti in cui opera il sistema.
L'interfaccia utente deve inoltre provvedere a una gamma potenzialmente ampia di esperienze almeno lungo le due
dimensioni, esperienza del computer e del dominio, come viene mostrato nella figura 1, riportata di seguito.
L'esperienza del computer include non solo la familiarità generale con i computer, ma anche l'esperienza del sistema in
fase di sviluppo. Gli utenti con scarsa esperienza dei computer o del dominio del problema, mostrati nel vicino angolo
sinistro della figura, richiederanno un approccio sostanzialmente differente nell'interfaccia utente rispetto agli
utenti esperti, mostrati nel lontano angolo destro.
Figura 1: Gli effetti dell'esperienza del computer e del dominio sulla facilità di apprendimento
rispetto alla facilità d'uso
Considerare che non è scontato affermare che gli utenti inesperti diventeranno esperti con il tempo. Diversi fattori
potrebbero contribuire ad impedire ciò, ad esempio una frequenza scarsa di utilizzo, una scarsa motivazione o
un'elevata complessità. Di contro, è possibile che alcuni sistemi dispongano di utenti generalmente esperti. In questo
caso i fattori potrebbero essere addestramento, elevata frequenza di utilizzo o buona motivazione (dipendenza dal
lavoro). Alcune di tali questioni e i relativi effetti sulla progettazione dell'interfaccia utente sono mostrati nella
Tabella 1.
|
Scarsa
|
Elevata
|
Esperienza del computer
|
Stile dell'interfaccia di menu o web (con collegamento ipertestuale) semplice, con compilazione
moduli e domanda e risposta semplice
|
Stile dell'interfaccia di menu o web (con collegamento ipertestuale) complesso, compilazione moduli
complessa (la compilazione moduli semplice o a domanda e risposta sarebbe molto frustrante per
utenti esperti)
|
Esperienza del dominio
|
Concetti e terminologia comuni
|
Concetti e terminologia specifici del dominio
|
Addestramento
|
Incentrato sulla facilità di apprendimento (coerente, prevedibile, memorabile)
|
Incentrato sulla facilità d'utilizzo (diretto, personalizzabile, non invadente)
|
Frequenza di utilizzo
|
Semplice da imparare e da ricordare, stile dell'interfaccia semplice
|
Semplice da utilizzare, tecniche e collegamenti multipli per consentire il controllo dell'utente
|
Motivazione
|
Soddisfacente da utilizzare, potente senza sembrare complesso.
|
Sofisticato con numerose funzioni avanzate e personalizzabili.
|
Tabella 1, Alcuni fattori che influiscono sulla progettazione dell'interfaccia utente
I sistemi interattivi devono essere progettati per soddisfare una gamma apposita di circostanze e di esperienze
dell'utente o è necessario effettuare alcune fasi per restringere l'universo della progettazione. Ad esempio, è
possibile utilizzare l'addestramento per ridurre il requisito per la semplicità di apprendimento in un sistema
complesso. In alternativa, è possibile ridurre l'ambito di un sistema affinché soddisfi meglio i requisiti principali
dei relativi utenti (un suggerimento viene fornito da Alan Cooper nel suo libro The Inmates Are Running the
Asylum [COO99]).
Come parte della progettazione incentrata sull'utente, occorre considerare gli skill e gli attributi fisici degli
utenti. Tali questioni stanno diventando sempre più parte della legislazione. Essa si rivolge principalmente agli
utenti con particolari esigenze. Tuttavia, rendere il sistema accessibile a una gamma più vasta di utenti è vantaggioso
per l'intera comunità di utenti.
La tabella seguente mostra le risorse e la legislazione di rilievo per diverse parti del mondo:
Tabella 2a, Legislazione relativa alle inabilità per paese,
regione o gruppo di nazioni
A parte la legislazione, la progettazione incentrata sull'utente e dell'interfaccia utente stanno diventando
sempre più il soggetto della standardizzazione, come mostrato di seguito.
Descrizione
|
Standard/Siti Web
|
ANSI
|
www.ansi.org
|
ANSI
ANSI-HFES
ANSI-NSC
|
ANSI e Human Factors and Ergonomics Society hanno pubblicato diversi standard congiunti. ANSI
dispone inoltre di un ANSI-NSC Z365 correlato al controllo e alla prevenzione dei disturbi di
stress cumulativi (noti anche come RSI o (repetitive strain injury)).
ANSI sta creando delle bozze di standard relativi all'interazione computer-uomo come parte
dell'IISP (Information Infrastructure Standards Panel).
|
ISO
|
www.iso.ch
|
ISO 9241
|
Una vasta serie di standard attinente principalmente con l'ergonomia delle workstation, ma che include
anche una guida all'utilizzo. Inoltre, le basi per ANSI-HFES 200, in fase di sviluppo.
|
ISO 10075: 1991
|
Principi ergonomici relativi al carico di lavoro mentale
|
ISO 17041-1: 1995
|
Controllo del cursore per la modifica del testo
|
ISO 11581
|
Serie nello sviluppo per la gestione di icone e puntatori.
|
ISO 13407: 1999
|
Standard per processi di progettazione incentrati sull'utente, per i sistemi interattivi.
|
Tabella 2b, interfaccia utente ISO e ANSI e
standard di progettazione incentrata sull'utente
Lo sviluppo di sistemi adeguati alle esigenze dell'utente significa un impegno notevole nell'analisi dei requisiti. In
una progettazione incentrata sull'utente, questo impegno è incentrato sugli utenti finali.
La disciplina Modellazione business include la modellazione dei dipendenti (per coloro che si trovano
all'interno del business) e e degli attori del business (per coloro che sono all'esterno del business).
Un punto di enfasi sostanziale nella progettazione incentrata sull'utente è che si comprendono i requisiti della
gente reale che assume i ruoli descritti nei prodotti di lavoro menzionati in precedenza. In particolare, occorre
evitare la progettazione di persone ipotetiche per cui conviene progettare i sistemi software. I prodotti di lavoro che
descrivono gli utenti devono essere scritti solo dopo un sostanziale contatto diretto con gli utenti. Nella
progettazione incentrata sull'utente, il contatto diretto fa parte di un processo chiamato, a volte, richiesta
contestuale. Hugh Beyer e Karen Holtzblatt (nel loro libro Contextual Design, [BEY98]) descrivono la premessa della richiesta contestuale come:
"...andare dove lavora il cliente, osservarlo mentre lavora e chiedergli informazioni sul lavoro che fa."
(Alcuni esempi concreti di tale situazione sono già stati elencati in Focalizzazione
sugli utenti). Questo approccio viene utilizzato per avere non solo una migliore conoscenza dei requisiti di
sistema, ma anche degli utenti stessi, delle loro attività e dei loro ambienti. Ognuno ha i propri attributi che, nel
complesso, vengono indicati come contesto di utilizzo. Essi sono dettagliati nello standard ISO per la progettazione
incentrata sull'utente, descritta di seguito.
Human-centered design processes for interactive systems di ISO [ISO13407] identifica
il primo passo nella progettazione come comprensione e specifica del contesto di utilizzo. Gli attributi suggeriti
sono:
Contesto
|
Attributi
|
Attività
|
Gli obiettivi di utilizzo del sistema, la frequenza e la durata delle prestazioni, le
considerazioni sullo stato e sulla sicurezza, assegnazioni di attività, le fasi operative tra le
risorse umane e tecnologiche. Le attività non dovrebbero essere descritte esclusivamente in
termini delle funzioni o caratteristiche fornite da un prodotto o da un sistema.
|
Utenti (per ogni differente tipo o ruolo)
|
Conoscenze, skill, esperienza, istruzione, addestramento, attributi fisici, abitudini, preferenze,
capacità.
|
Ambienti
|
Materiali hardware, software; ambienti fisici e sociali, standard pertinenti, ambiente tecnico,
ambiente generico, ambiente legislativo, ambiente sociale e culturale
|
Tabella 3: Contesto di utilizzo dallo standard ISO per una progettazione incentrata
sull'utente
E' utile suddividere il contesto dell'utente in due parti costituenti (ruolo e tipo di utente) e, quindi, considerare
le relazioni tra tutti e quattro di contesti:
Figura 2: Relazioni tra contesti
La figura 2 mostra che ogni attività viene eseguita in un ruolo eseguito da un utente all'interno
di un ambiente. Tali contesti corrispondono ai prodotti di lavoro del RUP, come mostrato nella Tabella 4.
Contesto ISO 13407
|
Prodotti di lavoro del RUP
|
Ambienti
|
|
Utenti
|
|
Ruoli
|
-
Livello elevato:
-
Attore di business (utenti esterni),
-
Lavoratore o sistema di business (utenti interni)
-
Dettagliata:
|
Attività
|
-
Livello elevato:
-
Dettagliata:
-
|
Tabella 4, contesti standard di progettazione
incentrata sull'utente ISO e relativi prodotti di lavoro del RUP prodotti di lavoro
Ognuno di tali contesti potrebbe avere un impatto significativo sulla progettazione di un'apposita interfaccia utente.
Come risultato, ci si trova di fronte a un numero potenzialmente elevato di permutazioni. Anche per un sistema piccolo,
è possibile che esistano 2 ambienti (ad esempio un sito ufficio e un sito del cliente), 3 tipi di utente (neofita delle
vendite, esperto delle vendite e gestione) e 6 ruoli (assistente telefonico alle vendite, rappresentante delle vendite
esterno, ecc.) . Ciò significa fino a 36 variazioni potenziali per attività, sebbene la serie di combinazioni
realistiche è, generalmente, molto più limitata.
Chiaramente, occorre descrivere le attività singolarmente, ma è improbabile che una descrizione singola sia appropriata
per tutte le permutazioni. Un approccio è la scomposizione dei contesti utente e ambiente nella descrizione del ruolo.
Questa è la soluzione adottata da Constantine e Lockwood [CON99]. Esso
comprende la fornitura di un "ruolo utente" separato per ogni permutazione di ruolo, utente e ambiente significativa,
quindi la denominazione del ruolo utente risultante con una frase descrittiva, anziché con un semplice nome.
Confrontare, ad esempio, il ruolo "Cliente" con i ruoli utente "Cliente casuale", "Cliente Web", "Cliente consueto" e
"Cliente avanzato".
Ogni descrizione del ruolo utente include i dettagli del ruolo stesso e i relativi utenti (denominati titolari dei
ruoli) e ambiente. E' possibile adottare questo approccio con il RUP, selezionando gli attori che corrispondono ai
ruoli utente.
I termini Scenari, Casi d'uso e Casi d'uso essenziali presentano un grado di sovrapposizione confusionario e vengono
utilizzati in approcci di progettazione differenti per indicare concetti lievemente differenti. Ad esempio, all'interno
del RUP, "scenario" indica un'istanza del caso d'uso; semplicemente un percorso specifico attraverso i possibili flussi
alternativi e di base. Tuttavia, è frequente trovare metodi di progettazione dell'interfaccia utente e incentrata
sull'utente che descrivono gli scenari come storie di utilizzo, contenenti sostanzialmente più dettagli rispetto al
semplice flusso di eventi. Sebbene queste informazioni aggiuntive possano essere irrilevanti in fasi di progettazione
successive, non fanno parte della comprensione di utenti, attività e ambienti. Di conseguenza, è possibile utilizzare
gli scenari in modo estensivo (in Creazione di
storyboard e Interpretazione del
ruolo) nella disciplina Modellazione business, ma l'attenzione si sposta verso i Casi d'uso nella disciplina
Requisiti.
La figura 3 mostra la natura di questa sovrapposizione. La scala nella parte superiore incorpora una serie di fattori
differenti che tendono a variare insieme. Ad esempio, man mano che lo scopo si sposta verso i requisiti, la
struttura diventa, generalmente, più formale. I casi d'uso essenziali vengono mostrati a destra dei casi d'uso
generici, perché i ruoli dell'utente li rendono più specifici (consultare la sezione precedente) e hanno una struttura
più formale.
Figura 3: Sovrapposizione nei concetti tra scenari e casi d'uso nella progettazione incentrata
sull'utente
Le differenze tra i casi d'uso di sistema e i casi d'uso essenziali vengono illustrate meglio tramite un esempio.
La tabella 5 mostra un caso d'uso dal Software for Use di Constantine e Lockwood [CON99]:
Azione dell'utente
|
Risposta del sistema
|
inserimento della carta
|
lettura della striscia magnetica
richiesta codice pin
|
immissione PIN
|
verifica PIN
visualizzazione menu di opzioni transazione
|
pressione tasto
|
visualizzazione menu del conto
|
pressione tasto
|
interrogazione del conto
|
immissione dell'importo
|
visualizzazione dell'importo
|
pressione tasto
|
restituzione della carta
|
prelievo della carta
|
distribuzione dei contanti
|
acquisizione dei contanti
|
|
Tabella 5: Caso d'uso generico per il prelievo di contanti da uno sportello automatico
Questo esempio descrive in dettaglio la sequenza di eventi tra l'attore e il sistema, con la linea verticale tra le due
colonne che rappresenta l'interfaccia dell'utente. Tenere presente che Constantine e Lockwood consigliano questo stile
per casi d'uso essenziali e questo caso d'uso particolare non è uno essenziale. La ragione è che si basa sul
dettaglio sintattico dell'interazione. Ossia, su come avviene l'interazione. Un caso d'uso essenziale è
incentrato su cosa riguarda l'interazione (indicato come semantica). La tabella 6 è la versione essenziale
dell'interazione.
Intenzione dell'utente
|
Responsabilità del sistema
|
identificazione di se stesso
|
verifica dell'identità
offerta di opzioni
|
selezione
|
distribuzione dei contanti
|
acquisizione dei contanti
|
|
Tabella 6: Caso d'uso essenziale per il prelievo di contanti da uno sportello automatico
Questo caso d'uso acquisisce l'essenza dell'interazione di acquisizione contanti. Le intestazioni Azione
dell'utente e Risposta del sistema sono state sostituite da Intenzione dell'utente e Responsabilità del sistema per
rispecchiare la modifica di enfasi. Una buona progettazione dell'interfaccia è incentrata sulle intenzioni e sugli
obiettivi dell'utente; questi sono spesso nascosti nei casi d'uso convenzionali. I casi d'uso essenziali
sono particolarmente utili nelle seguenti situazioni:
-
esistono pochi vincoli di progettazione (ad esempio, il vincolo di progettazione implicato dell'utilizzo delle
carte di credito è falso)
-
il sistema può essere migliorato per utilizzare altri mezzi di identificazione (ad esempio un tipo di accesso
internet sicuro)
-
vi è la volontà di creare casi d'uso senza vincoli di progettazione, per un potenziale riutilizzo in progetti che
mancano di tali vincoli
Tuttavia, i casi d'uso essenziali hanno i propri svantaggi. I casi d'uso perfettamente lineari, come quello della
tabella 5, possono essere soggetti a un dibattito considerevole quando succede di estrarne l'essenza. Ad esempio,
l'inserimento di una carta identifica il cliente o il conto? Nella maggior parte degli sportelli automatici esistenti,
è il secondo, sebbene Constantine e Lockwood abbiano scelto di interpretare ciò come identificazione del cliente. Ciò
potrebbe essere stata una decisione deliberata alla luce di una tecnologia più recente, come ad esempio
l'identificazione delle impronte digitali o la scansione della retina o potrebbe essere stata una disattenzione. Le
conseguenze, in questo caso, consistono in una ulteriore scelta che deve essere attuata dai clienti che posseggono più
di un conto.
Un'altra difficoltà presentata dai casi d'uso essenziali è che non sono adatti per l'analisi con utenti e altri
stakeholder, a causa della loro natura astratta. Una parte di questo problema deriva dalla necessità di convertire i
casi d'uso essenziali in una forma completa che rappresenti le azioni dell'utente. Una volta che un modello di
progettazione è disponibile, ciò può essere effettuato scrivendo scenari che descrivano l'interazione in termini
concreti (simili in concetto a una realizzazione del caso d'uso, sebbene attinenti all'interazione del
sistema dell'utente anziché alla collaborazione interna dell'oggetto.
Riepilogando, la creazione di casi d'uso essenziali potrebbe non essere una buona idea nelle seguenti situazioni:
-
le tecnologie dell'interfaccia utente sono intenzionalmente forzate (ad esempio, il sistema deve accettare le carte
di credito)
-
il tempo necessario affinché gli utenti comprendano i casi d'uso più astratti è più importante rispetto ai vantaggi
previsti.
Il RUP non si riferisce esplicitamente ai casi d'uso essenziali, ma nell'Attività:
Progettazione dell'interfaccia utente, i casi d'uso essenziali vengono utilizzati come punto di partenza,
quindi sviluppati e aumentati con i requisiti di utilizzo per creare degli Storyboard, come spiegato nella Linea guida:
Storyboard.
Ciò significa la rimozione di tutti i dettagli di implementazione correnti o di progettazione, in modo che rimanga solo
la semantica, il significato dell'interazione. Quindi, dal momento che vengono esplorate varie alternative di
progettazione, i dettagli sintattici, ossia la modalità con cui l'interazione ha luogo, vengono aggiunti al caso d'uso
essenziale come tipo di realizzazione. (Ogni progettazione alternativa è, in effetti, una realizzazione dello
stesso caso d'uso essenziale).
E' quindi possibile utilizzare gli storyboard come input per l'Attività: Creazione di prototipi dell'interfaccia utente per
sviluppare il Prototipo dell'interfaccia utente.
|