CHI SIAMO | CONTATTACI | PUBBLICAZIONI
 
 
 
    stampasegnala a un amico
  DISCOVERY

  ANALYSIS

  ARCHITECTURE
    Categorie
    Mappa
    Labeling
    Tassonomia
    Task Design
    Flussi
    Navigazione
    Pagine
    Prototipi
  DEVELOP



 

TASK DESIGN

Per procedere con il redesign di un task, o la trasposizione di un task dall'offline all'online, è necessario definire quali sono gli obiettivi qualitativi e quantitativi. Per fare questo, si parte dagli obiettivi individuati durante l'attività di Task Analysis, e si modificano o si riducono in base ai limiti di tempo, budget o alle decisioni di marketing sul sito/servizio.
Per elaborare la lista di obiettivi qualitativi e di obiettivi misurabili si può partire dagli elementi emersi durante l'inquiry e in base al valore che gli utenti attribuiscono al task. Questi elementi o valori vanno tradotti in obiettivi, ad esempio gli utenti vogliono essere certi di avere a disposizione informazioni su un libro per decidere se acquistarlo. L'obiettivo qualitativo è: gli utenti sono soddisfatti quando hanno accesso facilmente a tutte le informazioni che riguardano un libro per prendere una decisione. L'obiettivo quantitativo è: il 100% degli utenti deve essere in grado di arrivare alle informazioni sul libro in 5 passaggi-click.


Associazioni

Partendo dai task flow, dal task scenario e dagli artefatti di cui avete preso nota durante la Task Analysis, ora potete tracciare una lista dei verbi (azioni) e nomi (oggetti) che devono essere inseriti nel task che state riprogettando, a cui poi potete associare gli attributi che emergono dall'analisi.
Potete poi legare le azioni agli oggetti (es. nel task di acquisto di un libro online all'oggetto libro si possono associare le seguenti azioni: guardare il prezzo, guardare l'anno di pubblicazione, guardare chi sono gli autori, sfogliare l'indice, leggere le prime righe etc). Nello stendere questa lista di associazioni, cercate anche di capire quali sono ripetizioni (eventualmente con sfumature diverse, da considerare però due attributi diversi più che due azioni diverse) e quali invece le azioni che veramente si differenziano tra di loro.


Metafore

Nella stesura della lista, è probabile che emerga una metafora visiva. In questo caso, non legatevi immediatamente ad essa, ma prendete nota e valutatela in un secondo momento. Spesso le metafore prese dalla vita quotidiana sono molto efficaci ma possono limitare o non permettere di esprimere aspetti importanti degli oggetti o azioni su cui state lavorando. Utilizzando esperienze ed oggetti della vita reale, è necessario che la metafora sia più aderente possibile alla realtà, senza cercare di adattarla e modificarla in base alle esigenze del task.
Oppure, è possibile adottare una metafora, o meglio progettare la User Experience in modo da richiamare esperienze della vita quotidiana, senza per questo legarsi alla metafora di un oggetto (es. un form molto complesso può essere presentato domanda per domanda, facendo quindi selezionare le domande successive al sistema, in base alle risposte fornite dall'utente. In questo modo si può riproporre l'esperienza di un'assistente che aiuta a compilare un modulo).

E' da ricordare che una buona metafora non necessariamente si richiama strettamente agli oggetti del mondo reale o ad un solo oggetto (es. l'interfaccia Windows è in realtà un misto di metafore: le scroll-bar richiamano la metafora del rotolo di carta, i radio button richiamano la bottoniera delle prime radio etc). In ogni modo, una volta scelta la metafora (anche se solo per un'interazione), essa deve essere mantenuta integra e rispondente alla realtà: ad esempio il cestino usato nell'interfaccia Apple confonde solitamente gli utenti inesperti, che associano al cestino solo l'azione di buttare e non quella di espellere (cd o floppy).
Una volta individuata ed elaborata la metafora, provate ad applicarla al task, al workflow e agli obiettivi che avete identificato. Testate la vostra idea applicandola agli scenari (sintetico, vignetta, task scenario) che avete sviluppato sui dati raccolti dagli utenti, mettendo in evidenza le azioni e i punti decisionali che vanno inseriti.


Scenari d'uso

Successivamente, provate a scrivere uno scenario d'uso, cioè rivedete le azioni del task scenario e decidete quali azioni saranno ancora svolte dall'utente e in quali punti invece verrà supportato dal sistema e come l'interfaccia supporterà l'utente. (es, inserimento di un cap o selezione di città dalla lista presentata un menu a tendina). Se riuscite, durante l'elaborazione dello scenario d'uso, solitamente molto descrittivo, potete preparare degli schizzi sull'interfaccia a cui state pensando. Inoltre, lo scenario deve contenere anche le eccezioni o le possibilità di errore a cui avete assistito durante la Task Analysis.


Sequenze d'uso

Dallo scenario d'uso poi si passa alla sequenza d'uso, trasformando la descrizione in una serie di step successivi, indicando chiaramente le azioni associate allo step, le decisioni da prendere e le azioni eseguite dal sistema.
La sequenza deve essere rivista da tutti i membri del team ed eventualmente anche dagli utenti che partecipano alla progettazione, e all'interno della sequenza devono trovare spazio le eccezioni, i percorsi di errore etc.
I diagrammi di flusso emergono dagli scenari d'uso e dalla sequenza d'uso e mostrano i movimenti attraverso l'interfaccia del sito. A questo punto, è necessario considerare anche eventuali altri utenti che interagiscono con il sistema, sviluppando il diagramma del flusso di lavoro. Questo diagramma è molto utile per illustrare in maniera visuale un insieme di complesso di interazioni, permettendo di tenere traccia delle informazioni, controllare la loro evoluzione e modificazione, e di individuare le aree di interazione che possono essere modificate per migliorare il processo.


Gerarchie d'uso

In ultimo, tutte le azioni possono essere suddivise in gruppi o sottogruppi, creando delle gerarchie d'uso, che permettono di capire come i task o sottotask sono distribuiti all'interno del gruppo di lavoro. Può essere molto utile confrontare le gerarchie di task elaborate durante l'analisi e metterle a confronto con le gerarchie emerse dal nuovo design.
Combinando insieme gli scenari d'uso e le gerarchie d'uso, il team di lavoro deve verificare che la possibilità di aggiungere nuove features integrate con l'insieme. Inoltre, la metafora scelta deve permettere l'introduzione di nuove funzionalità.