Un modo di esporre una progettazione dell'interfaccia utente è fare in modo che un analista del sistema o del business
siano seduti insieme di fronte all'interfaccia. Si supponga uno scenario comune; ad esempio, un flusso di base del caso
d'uso con valori tipici descritti in uno storyboard del caso d'uso. Si consiglia di incoraggiare la persona a porre
domande e a fornire commenti.
La sfida con questo approccio è accertarsi che le informazioni ottenute siano il più possibile obiettive. A tale scopo,
è necessario accertarsi che le domande poste siano libere dal contesto. Trascrivere il maggior numero possibile di
note. Se possibile, delegare qualcuno per questa attività, in modo che non venga interrotto il flusso naturale
dell'utente. (Per linee guida utili sulla conduzione delle interviste utente e dei workshop, consultare Linee Guida: Interviste e workshop
dei requisiti).
Un altro modo di esporre la progettazione dell'interfaccia utente è l'esecuzione dei test d'utilizzo. Tali test vengono
spesso condotti come laboratori o workshop con rappresentanti della comunità di utenti finali. In un test d'utilizzo,
gli utenti reali eseguono attività vere e proprie con l'interfaccia e lo staff di sviluppo software, generalmente,
assumono un ruolo passivo di osservazione.
E' possibile ottenere un ottimo risultato da questo tipo di verifica dell'utilizzo, tuttavia, esistono numerose sfide
da affrontare e compromessi da accettare per ottenere risultati affidabili ed economici:
-
Come regola generale, questo approccio è il più valido se la comunità di utenti finali è grande, varia e dispone di
un elevato grado di controllo nella selezione del proprio sistema di software. In presenza di tali fattori, il
rischio della mancata esecuzione dei test d'utilizzo aumenta. Spesso, maggiore è il valore nell'esecuzione di tali
test e più difficile è ottenere accesso, coordinare e gestire questa attività con l'utente finale.
-
E' importante identificare i modelli di utilizzo più comune, ridurre i risultati anomali ed eccezionali, per
accertarsi che le decisioni di progettazione dell'interfaccia utente si basino sulle necessità della maggioranza. A
tale scopo, sono necessari dati di esempio vasti e approfonditi, che generalmente richiedono un ingente impegno di
raccolta e di ordinamento.
-
Nei casi in cui gli utenti devono migrare da un sistema vecchio già esistente a uno nuovo, la preoccupazione è
spesso che il nuovo fornisca una funzionalità minore rispetto a quella fornita dal vecchio. Sfortunatamente, questa
problematica viene sollevata direttamente in rari casi ed è spesso legata a commenti del tipo "Vorrei che il nuovo
sistema sia esattamente uguale al vecchio".
-
Quando una modifica significativa nella tecnologia viene proposta a una comunità di utenti finali, potrebbe
essere necessario fornire un addestramento nell'uso basilare della tecnologia prima di acquisire un valore
significativo dalla verifica di utilizzo. Ad esempio, è possibile che gli utenti del vecchio sistema non abbiano
alcuna esperienza precedente di utilizzo di un mouse o di gestione di una GUI.
Ogni team del progetto deve considerare queste sfide rispetto all'ambiente di progetto univoco in cui sta lavorando per
arrivare alla sincronizzazione, al metodo e all'approccio alla verifica dell'utilizzo.
E' molto importante esporre l'interfaccia utente ad altri. Man mano che la progettazione dell'implementazione
dell'interfaccia avanza, la progettazione viene esposta a un numero crescente di esaminatori, compresi:
-
altri membri del progetto
-
esperti esterni di utilizzo
-
utenti
Per ottenere un feedback valido, non è sempre necessario eseguire test d'utilizzo formali in cui gli utenti reali
eseguono attività reali. Una classe importante di difetti dell'interfaccia utente è causata dalla "cecità
nativa" del progettista dell'interfaccia utente, ciò significa che è più probabile che qualcuno non coinvolto nella
progettazione dell'interfaccia utente riesca a identificare la maggior parte di tali difetti.
Questo è un modo di esposizione della progettazione sottovalutato. Ha un tempo di inversione molto rapido: i membri del
progetto hanno già familiarità con l'applicazione e, generalmente, sono disponibili per una sessione di utilizzo
spontanea priva di quella terribile formalità. I progettisti dell'interfaccia utente dovrebbero farlo continuamente
durante l'attività di progettazione per "curare" la propria cecità nativa.
Un buon esperto di utilizzo può essere di supporto nella riduzione dell'impegno di sviluppo, evidenziando errori comuni
di utilizzabilità e, generalmente, offre altre prospettive sull'interfaccia utente, basate sull'esperienza. Potrebbe
essere una buona idea coinvolgere presto gli esperti di utilizzo esterni nel lavoro di progettazione dell'interfaccia
utente, in modo che ci sia tempo sufficiente per eseguire il refactoring della progettazione per incorporare i loro
consigli.
L'esposizione dei prototipi agli utenti è generalmente un ottimo modo per utilizzare il proprio tempo. Dal momento che
l'accesso per gli utenti è spesso limitato, vale la pena ottenere un feedback sui prototipi, qualora ce ne fosse la
possibilità. Eseguire tale operazione tutte le volte che è necessaria per conquistare l'approvazione degli stakeholder
e per correggere qualsiasi interpretazione errata delle esigenze degli stakeholder (portatori d'interesse). Ciò
potrebbe avvenire durante la cattura dei requisiti o la progettazione dell'interfaccia utente. Laddove possibile,
evitare di esporre più volte lo stesso utente all'interfaccia; la seconda volta, l'utente verrà influenzato dalle
precedenti proposte di test (in modo simile alla cecità nativa), e, come conseguenza, il valore dell'attività
diminuisce.
Inoltre, quando si espone un prototipo software agli utenti, impostare correttamente le aspettative. In caso contrario,
è possibile che gli utenti si aspettino di sperimentare la funzionalità completa del sistema corrente dietro
l'interfaccia utente.
Ulteriori letture
Consultare [CON99] e [GOU88] per
informazioni sulla progettazione per l'utilizzo.
|