Bentornato. Accedi all'area riservata







Non ti ricordi i dati di accesso?Recupera i tuoi dati

Crea il tuo account

2 SHARES

9 - Design dell'interazione: Le fasi di un processo di interaction design

07/12/2006 23794 lettori
5 minuti

Design dell'interazione. Un'esperienza di progettazione: www.comunitazione.it :-)

Le fasi di un processo di interaction design

Il processo di interaction design, per semplicità, lo dividiamo in quattro fasi, seguendo le indicazioni di Preece[1]:

1) identificare i bisogni e definire i requisiti: è importante in questa fase analizzare le esigenze di un segmento del mercato, stabilire quali siano le aspettative degli utenti e quindi definire i requisiti dell’artefatto. Per esempio: il mercato degli studenti universitari, evidenzia una forte richiesta di informazione scientifica. Il requisito è che le informazioni siano fruibili in modo personale.

2) sviluppare una serie di proposte alternative in grado di soddisfare i requisiti individuati: continuando il nostro esempio, si potrebbero sviluppare un motore di ricerca su una lista di siti ristretta, solo quei siti che trattano informazioni scientifiche ad esempio; ma si può anche sviluppare un agente intelligente che, conoscendo a fondo l’utente, va a rintracciare le informazioni che presumibilmente l’utente potrebbe volere, e quindi gliene propone la lettura.

3) costruire dei prototipi interattivi che permettano una valutazione: a questo punto bisognerà valutare tra le diverse proposte, e all’interno di una proposta come gli utenti riescono a rapportarsi con l’artefatto: soddisfa la domanda iniziale? Risponde ai requisiti? Gli utenti, riescono ad usarlo?

4) valutare il processo man mano che il lavoro va avanti: in modo iterativo. La fase di valutazione conviene, per ovvie ragioni economiche, ma non solo, che abbia un processo iterato nel tempo, continuativo, di fiancheggiamento allo sviluppo del progetto.

Come si è visto, la progettazione di artefatti interattivi è caratterizzata da quattro aspetti:

1) gli utenti dovrebbero essere coinvolti lungo tutte le fasi di sviluppo del progetto;

2) specifici obiettivi di usabilità ed esperienza d’uso dovrebbero essere identificati, concordati e chiaramente descritti fin dall’inizio del processo di design;

3) il processo di design è iterativo.

4) Coinvolgere gli utenti: user centered design.

Gli obiettivi di usabilità

Gli obiettivi di usabilità sono cruciali per la progettazione di sistemi commerciali rivolti al sostegno di attività lavorative all’interno di organizzazioni che adottano nuove applicazioni o aggiornano quelle esistenti sui loro sistemi e sulle loro reti.

Gli obiettivi di usabilità implicano l’ottimizzazione dell’interazione che le persone hanno con i prodotti per svolgere le loro attività; più in dettaglio il livello di soddisfacimento dei requisiti di usabilità di un sistema è rappresentato dal raggiungimento dei seguenti obiettivi:

· efficacia ed efficienza;

· sicurezza d’uso;

· facilità di apprendimento;

· facilità di ricordo.

Efficacia ed efficienza

Prendiamo ad esempio uno studente di Scienze della Comunicazione che voglia approfondire l’argomento trattato oggi a lezione. Ha a disposizione il proprio computer e un collegamento alla rete d’internet. Tra le opzioni possibili, sceglierà di utilizzare il motore di ricerca di Google per approfondire l’argomento “interaction design” e con questa chiave di ricerca chiederà al motore di trovargli dei risultati compatibili. Il sistema risulta efficace se aiuta l’utente a raggiungere l’obiettivo. L’efficienza invece, riguarda il modo in cui il sistema aiuta gli utenti a portare a termine il proprio lavoro. Se, tornando all’esempio precedente, Google fosse in grado di trovare i risultati coerenti non solo alla stringa di ricerca “interaction design” ma anche “design dell’interazione” il sistema sarebbe certamente più efficiente, in quanto i due termini non hanno alcun differenziale semantico e per tanto potrebbero essere usati in modo indistinto.

Sicurezza d’uso

Il problema della sicurezza riguarda la protezione dell’utente da situazioni pericolose o indesiderate. Questo principio combacia con la prima legge di Asimov[2] Un robot non può recar danno a un essere umano ne può permettere che, a causa del proprio mancato intervento, un essere umano riceva danno. Quindi da un lato gli artefatti non devono costituire un fattore di rischio per gli esseri umani, dall’altro lato i sistemi non devono mai esporre a rischi incidentali gli utenti per un loro mancato funzionamento.

Secondo Preece rendere i sistemi basati su computer più sicuri implica:

• impedire che l’utente compia errori irreparabili riducendo il rischio che tasti sbagliati vengano attivati per errore;

• fornire all’utente un modo per porre rimedio a eventuali errori commessi.

Un sistema interattivo sicuro dovrebbe generare fiducia e permettere all’utente di esplorare l’interfaccia per scoprire nuove funzionalità, fra i meccanismi di sicurezza rientrano tutte le opzioni di annullamento dell’input e le finestre di dialogo che richiedono conferma di un’azione, fornendo all’utente una possibilità di riconsiderare le proprie intenzioni

Facilità di apprendimento

Riguarda la semplicità con cui un sistema viene appreso. E’ noto che le persone non amano dover dedicare troppo tempo a capire come usare un sistema. Tutti desiderano essere in grado di operare fin da subito e di acquisire le competenza necessarie a svolgere tutte le azioni senza grande sforzo.

Facilità di ricordo

E’ la capacità di un sistema legata alla facilità di ricordarne le modalità di utilizzo, dopo che sono state apprese. Questo è particolarmente importante per sistemi interattivi che vengono usati saltuariamente. Anche se un utente non usasse un sistema o una funzione del sistema per qualche periodo, dovrebbe essere in grado di ricordare come usarlo o per lo meno rispolverarlo facilmente. Gli utenti non dovrebbero continuamente imparare come compiere gli stessi task. Sfortunatamente questo accade spesso quando le operazioni da compiere sono confuse, senza logica o mal disposte in sequenza.

Gli utenti non hanno bisogno che gli si ricordi cosa devono fare, ci sono diverse strategie per progettare un’interazione che permetta di soddisfare questo bisogno. Per esempio si potrebbero aiutare gli utenti a ricordare una sequenza di operazioni lungo le diverse fasi di processo, fornendo icone, comandi e voci di menu chiaramente significative. Anche strutturare icone e opzioni in categorie rilevanti può aiutare l’utente a ricordare dove trovare un particolare strumento in corrispondenza in un certo passo dell’attività.

Gli obiettivi riguardanti l’esperienza d’uso

Gli obiettivi legati all’esperienza d’uso si distinguono dai più oggettivi obiettivi di usabilità per il fatto che i primi riguardano il modo in cui l’utente vive l’esperienza di interazione con un certo prodotto, mentre i secondi hanno a che fare con la misurazione di quanto quel prodotto è utile e produttivo. Se i primi obiettivi sono fortemente soggettivi, i secondi sono oggettivi: un oggetto è sicuro o meno; la bellezza, il piacere che ne deriva dall’uso invece è implicabile all’utente e pertanto unici.

Nel campo dell’esperienza d’uso molte sono le ricerche che le industrie portano avanti, soprattutto l’industria dell’intrattenimento, che impiegano molte risorse per indagare il ruolo del piacere nell’interazione con gli artefatti.

L’aver compreso che le nuove tecnologie offrono un numero crescente di opportunità per sostenere le persone nel quotidiano, ha portato sia i ricercatori che gli operatori di settore a prendere in considerazione nuovi obiettivi. L’affermarsi di tecnologie come la realtà virtuale, l’internet e la tecnologia mobile, in diversi domini di applicazione, dal divertimento all’apprendimento, dall’home entertainment agli spazi collettivi, ha scoperto una serie di questioni molto più ampie. Oltre a concentrarsi sull’innalzamento dell’efficienze e della produttività in ambito lavorativo, l’interaction design sempre di più si confronta con la progettazione di sistemi di varia natura e debbano rispondere a queste personalissime esigenze:

a) soddisfazione;

b) piacevolezza;

c) divertimento;

d) utilità;

e) capaci di sostenere le motivazioni delle persone;

f) esteticamente gradevoli;

g) capaci di alimentare la creatività delle persone;

h) gratificanti;

i) in grado di soddisfare bisogni legati alla sfera delle emozioni[3].

La possibilità di progettare sistemi interattivi divertenti, godibili ed esteticamente piacevoli è essenzialmente legata alle caratteristiche dell’esperienza d’uso, vale a dire al modo in cui gli utenti vivono l’interazione con il sistema.

Progettazione e vincoli di usabilità

Un artefatto dovrebbe essere progettato in modo da fornire all’utente un riscontro adeguato rispetto alle sue azioni per aiutarlo a procedere nelle sue attività. I principi di progettazione derivano da un mix di conoscenze teoriche, esperienza e buon senso; tendenzialmente vengono proposti in modo normativo. Questi principi nascono con l’intento di fornire una guida al team di progettazione e sono utili dal momento in cui ci si accorda sul fatto che l’essere umano possiede risorse limitate per l’esecuzione dei compiti e, diversi compiti, comportano un utilizzo differente delle risorse[4]. Camminare è un compito relativamente semplice e soprattutto svolto in maniera automatica[5]; moltiplicare a mente due numeri a tre cifre richiede uno sforzo ed un’attenzione completamente diversi. Se il primo compito è automatico (camminare), e con Raskin potremmo definirlo un processo inconscio, il secondo è un compito conscio (far di conto), che richiede l’attenzione dell’essere umano. Siamo in grado di camminare e contemporaneamente mangiare, senza inciampare o correre il rischio di affogarci, e contemporaneamente ancora fare un calcolo a mente. Questo è possibile poiché portiamo il fuoco della nostra attenzione[6] solo sul calcolo matematico. Ma se nel cibo che siamo mangiando ci fosse un sapore sgradito il fuoco della nostra attenzione verrebbe spostato dal terzo compito al secondo.

I compiti eseguiti molto spesso (camminare, mangiare, leggere, utilizzare la tastiera del computer) ingenerano delle abitudini, che lo si desideri o no. Dal punto di vista del progettista questo è un elemento essenziale, perché da una parte può eliminare un carico eccessivo dell’utente, dall’altro può essere utilizzato per attirare l’attenzione dell’utente su operazioni irreversibili o complesse.

E’ per questo che nelle fasi di progettazione del design dell’interazione diventa importante stabilire ed identificare i bisogni ed i requisiti dell’artefatto.

Identificare i bisogni e stabilire i requisiti

L’artefatto (cognitivo, tecnologico, organizzativo) deve seguire ciò che Norman definisce design naturale, ovvero deve essere visibile cosa si può e cosa non si può invece fare con l’oggetto.

Questo richiede una comprensione degli utenti e delle loro capacità, dei compiti che affrontano quotidianamente e dei loro obiettivi, delle condizioni in cui verrà utilizzato il prodotto e dei vincoli sulle prestazioni del prodotto stesso.

Identificare i bisogni significa dunque conoscere a fondo le persone che utilizzeranno l’artefatto, i loro scopi e i loro obiettivi finali, senza tralasciare i requisiti del sistema[7].

Cosa sono i requisiti?

Un requisito è un’affermazione relativa ad un prodotto che specifica cosa esso deve fare e come lo deve fare. Uno degli scopi dell’attività di definizione dei requisiti è quello di renderli specifici, disambiguandoli, e rendendoli chiari.

Per esempio, un requisito per un sito web potrebbe essere che la home page racconti in modo veloce e diretto cosa si possa trovare all’interno del sito[8], rientrare in uno standard di navigabilità, offrire affordance. Nell’ingegneria del software sono stati individuati due tipi di requisiti: i requisiti funzionali, che indicano quello che il sistema deve fare; i requisiti non funzionali che indicano quelli che sono i vincoli sul sistema e il suo sviluppo.

Ad esempio un requisito funzionale per un word processor, potrebbe essere quello di supportare diversi tipi di formattazione e permettere all’utente di stabilirla nel modo più semplice ed efficace.

Un requisito non funzionale, invece, del word processor, potrebbe essere quello di dover girare su diverse piattaforme (pc, mac, Unix).

Anche questo requisito rappresenta un vincolo sull’attività di sviluppo dell’artefatto da tenere in considerazione.

L’interaction design richiede una comprensione delle funzionalità richieste e dei vincoli che limitano il funzionamento e lo sviluppo del prodotto.

Preece identifica una lista indicativa di alcuni requisiti che travalichino le frontiere rigide della distinzione tra requisiti funzionali e non funzionali. In particolare i requisiti individuati si referiscono a:

requisiti funzionali: ovvero quello che il prodotto deve fare;

requisiti riguardanti i dati: ovvero come conservare i dati, ogni quanto aggiornarli e archiviarli e come manipolarli.

requisiti ambientali: si riferiscono al contesto d’uso, alle circostanze in cui ci si aspetta che opererà il prodotto;

requesiti utente, individuano le caratteristiche del gruppo di utenti di riferimento;

requisiti di usabilità.

Come identificare le attività che l’utente svolgerà con l’artefatto?

Ancora una volta facciamo riferimento a Preece che identifica tre modalità per la descrizione delle attività umane:

1) gli scenari;

2) i casi d’uso;

3) gli essential use case.

Ciascuna di queste modalità può essere utilizzata sia per descrivere le attività esistenti, sia per descrivere attività immaginate in interazione con nuovi dispositivi.

Gli scenari

Per Carrol[9] gli scenari sono una descrizione narrativa informale. Descrive attività umane o compiti in una storia che permette di esplorare e discutere i contesti, i bisogni e i requisiti. Raccontare storie è un modo naturale per le persone di spiegare ciò che fanno ed il modo in cui raggiungono le mete prefissate. Si tratta di qualcosa con cui tutti si sentono facilmente a proprio agio. L’elemento centrale delle storie tende ad essere collegato a quello che queste persone cercano di ottenere, ovvero i loro obiettivi finali. Capire perché le persone fanno le cose in un certo modo e cosa aspirano di ottenere con le loro azioni, permette di concentrarsi sull’attività umana piuttosto che sulla tecnologia.

I casi d’uso

Anche i casi d’uso si concentrano sugli obiettivi dell’utente, ponendo l’enfasi sull’interazione tra l’uomo e il sistema. Se con gli scenari quindi l’accento viene posto al compito che l’utente deve raggiungere, in questo caso l’enfasi viene spostata sull’interazione. Con questa tecnica il caso d’uso principale individua la modalità privilegiata di interazione con il sistema, ovvero l’insieme delle azioni che l’analista ritiene vengano compiute più frequentemente. Così, per esempio, se per mezzo di una fase di raccolta dati si rilevasse che la maggioranza degli utenti compie una determinata operazione, allora si dedurrebbe che il corso normale dell’interazione sia quello, le altre sequenze verrebbero così definite corso alternativo.

Il vantaggio del caso d’uso è la conseguenza che essendo una lista di task, potrebbe esser facilmente raffigurato con un diagramma di flusso; la presentazione diventa quindi più formalizzata e la struttura di un buon caso d’uso è stata discussa da molti[10].

Gli essential use case

Gli essential use case sono stati sviluppati da Constantine e Lockwood (1999) in contrapposizione a quello che gli autori individuavano essere un limite sia degli scenari che dei casi d’uso, in quanto entrambi potrebbero nascondere questioni più ampie che hanno a che fare con una visione organizzativa del contesto, mentre i casi d’uso partono dal presupposto che una tecnologia esista e quindi prendono in analisi quella data tecnologia.

Gli essential use case sono una struttura narrativa suddivisa in tre punti:

1) un nome che esprime l’intenzione principale dell’utente;

2) una descrizione analitica delle azioni dell’utente;

3) una descrizione delle responsabilità del sistema.



[1] Preece, op. cit. p. 203 e succ.
[2]  Nata dal romanzo di Isaac Asimov, (Io Robot, Mondadori 1946), la prima legge di Asimov, o della robotica, sembra essere stata universalmente accettata dagli studiosi di robotica, intelligenza artificiale e interaction design. Anche a noi sembra un ottimo principio, soprattutto perché aiuta a capire la rilevanza dell’obiettivo di sicurezza d’uso.
[3]  Preece, op. cit.
[4]  Di Nocera, F., Che cos’è l’ergonomia cognitiva, Carocci, Torino 2004. p. 37.
[5]  Raskin, J., Interfacce a misura d’uomo, Apogeo, Milano 2003, p. 10.
[6]Ivi, p. 17.
[7] Preece, op. cit.
[8] Nielsen, J., Home page usability, Apogeo, Milano 2002, p. 36.
[9]
 Carroll, J. M., Introduction to the special issue on “Scenario-Based System Development”, Interacting with Computer, 13, pp.41-42.
[10] Cockburn A., Structuring use cases with goals, 1999, disponibile on line all’url: member.aol.com/acockburn/papers/usecases.htm - Gough, P.A. (e altri) Scenarios an industrial case study and hypermedia enhancements. In Proceedings of 2nd IEEE symposium on requirements Engineering, IEEE Computer Society, 1996, 10-17 - Ben Achour C., Extracing Requirements by Analyzing Test Scenarios, Thése de Doctorat de Université Paris 6, 1999.

Luca Oliverio
Luca Oliverio

Luca Oliverio è il founder e editor in chief di comunitazione.it, community online nata nel 2002 con l'obiettivo di condividere il sapere e la conoscenza sui temi della strategia di marketing e di comunicazione.

Partner e Head of digital della Cernuto Pizzigoni & Partner.

Studia l'evoluzione sociale dei media e l'evoluzione mediale della società.