bitmama

Nell’ambito della User Experience 2008 Conference, di cui è già stato riportato l’incontro dedicato alle Linee guida fondamentali per la Web Usability, si è tenuto un seminario inerente la documentazione di User Experience. 
I relatori erano Dan Brown e Nathan Curtis.

 

In questo articolo abbiamo integrato consigli e suggerimenti dei due relatori con le best practices di Aware. Lo scopo dell'articolo, oltre alla divulgazione di quanto recepito, è fornire un esempio della nostra offerta e del nostro modo di lavorare.

Di seguito definiamo gli elementi che compongono un documento di User Experience (mappe del sito, flow chart, wireframe e wireframe annotati) e il loro ruolo durante il ciclo di vita di un progetto.

 

Il ciclo di vita della documentazione di User Experience

La documentazione di User Experience (UX) accompagna il progetto di design dall’ideazione al completamento, svolge diversi compiti e comunica, di volta in volta, ad audience differenti.

Nella prima fase di progetto la documentazione è di alto livello. Suoi scopi principali sono:

• Raccontare e divulgare la storia del progetto, sia al team sia agli stakeholders.
• Tracciare le scelte di design, ratificare le decisioni, colmare le lacune della storia con la definizione di passi intermedi e di dettagli.

Il project manager basa su questo documento la pianificazione delle attività future.

Nella fase di sviluppo è la traccia comune per l’intero team di progetto; I suoi obiettivi sono:

• Descrivere le interazioni, gli stati e i comportamenti del sistema.
• Determinare i vincoli sui dati visualizzati e quelli inseriti, l’aspetto visuale delle singole pagine, i contenuti da associare o creare per ogni pagina.

 

L’audience di un documento di UX è ampia: executive, product manager, site strategist, visual designer, developer, QA e copywirter.

Nella prima fase l’uso di flow chart, mappe del sito e storyboard è utile ad executives, product manager e site strategist a comunicare e tracciare le decisioni prese.
Nella fase di sviluppo visual designer, developer, QA e copywirter hanno invece bisogno di wireframe annotati (ossia wireframe con specifiche funzionali).

Brown e Curtis consigliano di partire con un documento che sia facile da estendere, mantenere nel tempo e presentare in modo diverso a diverse audience. La loro scelta aziendale come software di riferimento per la documentazione di User Experience cade su Adobe Indesign. Di norma, per la loro documentazione, utilizzano alcuni script per la costruzione del documento sviluppati a partire da una base di template creata nel corso degli anni.

 

Come procedere

durante la prima fase di progetto è opportuno creare un documento preliminare di alto livello comprendente strategia, mappa del sito e flow chart. Questo documento, nella fase di sviluppo, viene successivamente integrato con i wireframe e le specifiche funzionali, entrando in un livello di dettaglio maggiore.

Il processo di design, non lineare per sua natura, crea la necessità di modificare ed eliminare parti del flusso di navigazione, e comprende la possibilità di presentare numerose varianti di pagina, oltre che di tener traccia delle decisioni.
La manutenzione è di conseguenza un processo critico, da tenere presente fin dall’inizio della progettazione, in modo da non creare nel tempo eccessive difficoltà di gestione. Se si organizza il documento di UX in due macroparti e se si usano delle convenzioni, si diminuisce drasticamente l’overhead dovuto alla manutenzione.

Nella preparazione di un documento di UX Dan Brown suggerisce di applicare i principi di user centered design al documento stesso. Se infatti risulta difficile da leggere, è privo di una struttura, o non risponde alle domande dell’audience in modo diretto e chiaro, non è un buon documento. Di fatto è preferibile che gli interaction designer applichino le proprie conoscenze specifiche alla scrittura della documentazione.

 

Mappe del sito e Flow Chart

La Mappa del sito rappresenta l'organizzazione gerarchica, organizzata su più livelli, dell'Informazione sul sito. Offre una catalogazione dei contenuti e li divide in aree distinte.

 

Fig 1. Esempio di Mappa del sito.

 

I flow chart rappresentano invece i processi. Come esemplificazione di flow chart prendiamo in considerazione il processo di acquisto di uno Skipass “Espace san Bernardo” tramite CartaSi inviando un SMS.

 

Fig 2. Esempio di flowchart (Scarica l'intero esempio di flow chart CartaSì - PDF).

 

Partendo da questo esempio si può dare una definizione di flow chart: un diagramma che mostra come una persona (o un gruppo di persone) cambi lo stato di una situazione, tipicamente manipolando e trasformando l’informazione. In modo meno astratto: è la risposta alla domanda “come fanno gli utenti a fare X?”, fornita in termini di visualizzazione della modalità in cui viene realizzata una specifica azione oltre che essere uno strumento per l’individuazione dei requisiti funzionali.

Un flow chart descrive  il flusso tra un punto iniziale e uno finale. Un esempio che è entrato nella storia è la carta figurativa che descrive il percorso fatto da Napoleone con le sue truppe durante la campagna di Russia (vedi Fig 3.):

 

Fig 3. Carta figurativa, Minard.

In una singola pagina Minard, l’autore della carta figurativa, comunica i dati relativi al numero delle truppe, la direzione, le distanze, oltre che latitudine, longitudine, il tempo, la temperatura, i fiumi principali attraversati.

Prima di disegnare un flow chart ci si deve chiedere:

• come utilizzarlo, quale sarà il suo scopo
• qual’è il destinatario
• quale livello di precisione raggiungere
• se è sufficiente usare un vocabolario standard o se ne si deve inventare uno nuovo
• come definire il contesto, ovvero quante informazioni di background vanno inserite nel flow chart
• come trattare i diversi scenari, ovvero quante variazioni vanno presentate
• come strutturarlo in forma narrativa

Dan Brown ha una sua metodologia:

• individuare il punto di ingresso e i punti di uscita
• definire quali sono gli elementi: i singoli passi (boxes), i momenti di decisione (diamonds), i percorsi (paths / arrows)
• elaborare gli elementi: differenzia tra diversi scenari (compresi quelli di errore), variazioni, dettagli, e gruppi di azioni
• raffinare gli elementi: aggiungere note di produzione, dettagli tecnici, eventi che scatenano determinate situazioni.

Il vocabolaro di simboli utilizzabili spesso non permette di raccontare nel migliore dei modi la storia che deve essere raccontata. C’è perciò la libertà di inventare nuovi simboli, metterli in legenda, tenendo sempre a mente il target.

Scopo primario del flow chart è la narrazione delle azioni, lo strumento di base dell’interaction design. La Mappa del sito invece è utile a descrivere la classificazione dei contenuti ed è connessa all’information architecture. A meno che non si abbia a che fare con una web application i siti di informazione vengono ampiamente descritti da una Mappa del sito e alcune particolari azioni possono essere illustrate tramite flow chart.

 

Wireframe Annotati e Specifiche funzionali

Un wireframe può essere appena abbozzato, disegnato a mano (vedi Fig 4.), specialmente nelle primissime fasi del progetto, oppure essere molto fedele all'aspetto definitivo dell'interfaccia, in tal caso si parla di wireframe hi-fidelity.

 

Fig 4. Wireframe (bozza). Descrive tool di collaboration per la gestione a distanza di progetti.

 

Quando ad un wireframe aggiungiamo delle note/ specifiche funzionali, otteniamo un wireframe annotato. In questo caso la separazione tra il layer contenente l’artwork (il wireframe) da quello con le annotazioni deve essere netta.
L’esempio in questo caso riguarda un sistema di gestione dei contenuti (CMS) per la sezione lavora con noi/careers di un sito.

 

Fig 5. Wireframe annotato (Scarica l'intero esempio di wireframe - PDF).

Ora è possibile delinerare la definizione di wireframe: un diagramma che rappresenta il contenuto dello schermo e le priorità/importanza degli elementi. Più concretamente, è la risposta alla domanda “cosa vedono gli utenti sullo schermo?”, è un modo per illustrare funzionamento e comportamenti dell'interfaccia utente, quali gli elementi dinterattivi, il tipo di interazione e la conseguente cambiamento dell'interfaccia utente.

Operativamente bisogna stabilire:

• l’audience
• quanta aderenza alla versione finale bisogna tenere
• che livello di precisione si deve raggiungere
• il formato finale della presentazione
• quante persone lavorano al documento (sviluppatori, IxD, information architect, copywriter, ..)

Con ogni probabilità si tratta del documento più dettagliato e comprensibile che gli stackeholder e l’intero team di progetto avranno sotto mano per diverso tempo, finchè non verranno creati i primi prototipi o addirittura il sito/applicazione funzionante.

E’ importante perciò che questo documento sia utilizzato per ratificare le decisioni di design, che Dan Brown ricorda non debbono essere motivate da “la mia opinione è che…” quanto piuttosto da ricerche, letteratura e user data. Una delle trappole più insidiose è quella di trovarsi a discutere in una riunione basandosi solo sulle opinioni.

Durante una presentazione è importante fare domande per:

• validare quanto fatto
• chiarire se manca qualcosa
• scegliere tra le diverse alternative presentate (e quindi eliminarne alcune variazioni)
• comprendere le implicazioni a livello funzionale e organizzativo di ciò che si sta presentando, ovvero assicurarsi della fattibilità sia tecnica sia a livello di organizzazione.

Nathan Curtis propone la sua metodologia per la realizzazione della documentazione di UX:

• definire quali sono gli elementi: aree di contenuto, descrizione, priorità
• elaborare gli elementi: elementi interattivi, annotazioni, scenari e varianti, razionali
• raffinare gli elementi: layout e visual design, contesto e contenuti d’esempio

Il documento di UX, contenente il flow chart, la Mappa del sito e i wireframe annotati deve avere una struttura rigorosa. In particolare per la sezione relativa ai wireframe annotati i consigli sono: proporzionare bene lo spazio per l’artwork e quello per le annotazioni, tenendo in considerazione il livello di precisione a cui si desidera arrivare, che annotazioni e artwork devono stare vicini e che il formato deve essere standard per l’intero documento. È necessario scegliere i template che si utilizzano per presentare variazioni di pagina o di componenti, di immagine o di struttura.

Esistono diversi tipi di annotazioni: overlay, callout e markers. L’uso dei marker (in particolare dei notched marker e dei margin marker) è quello prevalente. Si tratta quasi sempre di annotazioni puntuali. I callout a square braket e outline servono invece a raggruppare il soggetto delle annotazioni (Nelle figure 6, 7 e 8 sono forniti degli esempi).

 

Fig 6. Overlay.

 

Fig 7. Callout.

 

Fig 8. Markers.

In una lista di oggetti, per favorire la lettura, è preferibile la notazione numerata; è possibile invece utilizzare le lettere per dati e tabelle, variazioni di pagina e componenti. Il marker deve essere posizionato con precisione in modo da non risultare ambiguo. Nel caso di variazioni di pagina, è bene non duplicare le parti che rimangono invariate, ma concentrarsi sui componenti o gli elementi che variano. Questo per motivi di convenienza in fase di manutenzione.

Per l’annotazione di un wireframe si procede come segue:

• si inserisce il wireframe nella pagina
• lo si divide in elementi, che vengono marcati
• si dettaglia ogni elemento
• si identificano gli attributi di ogni elemento, tipicamente:
  1. comportamento (es. onclick, onmouseover, …)
  2. stato (es. visibile|nascosto)
  3. dati (es. [nome cognome], o l’uso delle {parentesi graffe} per descrivere un contenuto opzionale)
  4. eventuali guide editoriali per i copywirter e per il SEO

La rappresentazione dei dati all’interno di un wireframe può seguire queste linee guida:

• il “lorem ipsum” va bene solo per testi lunghi
• i dati reali rischiano di sviare l’attenzione degli stakeholder, che si concentrano sui dati invece che sull’interfaccia
• i dati fittizzi (es. Mario Rossi) hanno lo stesso problema, possono essere confusi per dati veri e posso essere interpretati in modo ambiguo.
• le [label] sembrano essere il migliore compromesso nella maggior parte dei casi, sebbene non rappresentino visivamente il dato e le loro dimensioni possano trarre in inganno (es: [codice fiscale], [nome], [cognome], …).
• Perciò per i test di usabilità è sicuramente meglio usare dati fittizzi/reali.

Integrazione dei contenuti

Una delle sfide più ardue è l’integrazione dei contenuti con l’interfaccia utente in modo che la User Experience risulti seamless. Una delle prime difficoltà è dovuta al fatto che contenuto e interfaccia di solito hanno diversi responsabili, diversi processi di approvazione e consegeuentemente diversi livelli di dettaglio.

è possibile pensare a un progetto come a un’unità composta da:

• struttura: relazioni e reperibilità - responsabili: information designer
• contenuto: voce, linguaggio e leggibilità - responsabili: copywriter, content strategist e SEO
• interazione: comportamento e usabilità - responsabili: interaction designer

Queste tre aree devono cooperare in modo da mostrare:

1. istruzioni e feedback tra contenuto e interazione
2. tassonomie e metadati tra contenuto e struttura
3. flusso e dati tra interazione e struttura

Per mostrare tutte le relazioni esposte nei tre punti precedenti ci si avvale di un documento come il wireframe in fig. 9, che presenta una suddivisione in tre aree:

• header e il footer contengono documentazione amministrativa
• artwork (il wireframe)
• le annotazioni (sul lato destro)

 

Fig. 9 Struttura di un documento UX: header, footer artwork e annotazioni.

In questo esempio la scelta dello spazio riservato alle annotazioni rimanda all’idea di un documento non particolarmente dettagliato, che descrive soltanto gli elementi funzionali e la navigazione.

 

Si potrebbe obiettare che la metodologia e gli strumenti descritti in questo articolo siano eccessivamente onerosi. In Aware sosteniamo invece che l'economia dell'intero progetto ne guadagni. Il progetto diventa tangibile per tutto il team fin dalla sua prima fase, in questo modo i costi di modifiche e ripensamenti vengono sono confinati nella fase progettuale piuttosto che ricadere su quella di sviluppo, tipicamente notevolmente maggiorati. La documentazione di UX permette infatti da un lato al Cliente di partecipare maggiormente alle decisioni di design, minimizzando il numero di incomprensioni e di conseguenza di insoddisfazioni finali, dall'altro ai Programmatori di risolvere le altrimenti numerose ambiguità di un semplice documento di testo (documento di specifiche funzionali) e di avere quindi un'utile guida in fase di sviluppo.