Communicating Design: Improving User Experience Deliverables

User Experience 2008 - 18 Nov

Un bel corso, molto hands-on, tenuto da due persone brillanti:

Dan Brown, Nathan Curtis

Il ciclo di vita della documentazione di User Experience

La documentazione di User Experience (UX) accompagna il progetto di design, dall’inizio alla fine. Svolge diversi compiti e comunica, di volta in volta, ad audience differenti.

Nella prima fase di progetto la documentazione è di alto livello. Serve a raccontare e propagare la storia del progetto, sia al team che agli stakeholders. Tracciare le scelte di design, ratifica le decisioni, a colma i buchi nella storia, con l’aggunta di passi intermedi e dettagli. Il project manager parte da qui per fare la pianificazione delle attività.

Nella fase di sviluppo è la traccia comune per l’intero team di progetto; descrive: le interazioni, gli stati e i comportamenti del sistema, i vincoli sui dati visualizzati e quelli inseriti, l’aspeto visuale delle singole pagine, i contenuti da associare o creare per ogni pagina.

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

Nella prima fase l’uso di flowchart, mappe del sito e storyboard serve a 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 e 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 è Adobe Indesign. Utilizzano alcuni script per la costruzione del documento a partire da una base di template che hanno creato negli anni. Purtroppo questi template non sono tra gli materiali del corso.

Si crea un primo documento di alto livello, con strategia, flow chart e mappe del sito. Questo documento viene successivamente integrato con i wireframe e le specifiche funzionali, entrando in un livello di dettaglio maggiore.

La manutenzione è un processo critico, da tenere presente fin dall’inizio, in modo che non diventi ardua nel tempo. Il processo di design, non lineare per sua natura, crea la necessità di modificare ed eliminare parti del flusso di navigazione, presentare delle varianti di pagina e tener traccia delle decisioni. 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 ci invita ad applicare i principi di user centered design al documento stesso. Se è difficile da leggere, non ha una struttura, non risponde alle domande dell’audience in modo diretto e chiaro, non è un buon documento. Sollecita di fatto gli interaction designer ad applicare le proprie conoscenze alla scrittura della documentazione.

Flow Chart e Mappe del sito

Si parte all’americana, con un esercizio in classe: disegnare a scelta un flow chart che descriva una tra queste attività:

• inserimento nota spese
• aggiunta di un contatto
• tracciamento delle ore lavorate

Discussi alcuni flow chart fatti dai partecipanti viene data la 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 a “come fanno gli utenti a fare X?”, fornita in termini di visualizzazione di come portare a compimento una specifica azione oltre che essere uno strumento per l’individuazione dei requisiti funzionali.

Un flow chart racconta il flusso tra ha un punto iniziale e uno finale. Un esempio che è entrato nella storia è la carta figurativa che descirve il percorso fatto da Napoleone con le sue truppe durante la campagna di Russia:

Fig 1. Carta figurativa, Minard.

In una singola pagina Minard, l’autore della carta figurativa, comunica dati relativi al numero delle truppe, la direzione, le distanze, 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
• chi è l’audience
• quanto dettaglio andremo a inserire
• 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 presetate
• come strutturarlo in forma narrativa

Dan Brown ha una sua metodologia:

• individua il punto di ingresso e i punti di uscita
• definisce quali sono gli elementi: i singoli passi (boxes), i momenti di decisione (diamonds), i percorsi (paths / arrows)
• elabora gli elementi: differenzia tra diversi scenari (compresi quelli di errore), variazioni, dettagli, e gruppi di azioni
• raffina gli elementi: aggiunge note di rpoduzione, dettagli tecnici, eventi che scatenano determinate situazioni

Il vocabolaro di simboli da cui si attinge spesso non permette di raccontare nel migliore dei modi la nostra storia. Siamo liberi di inventare nuovi simboli, metterli in legenda e ricordarci sempre del nostro target.

Fig 2. Esempio di flow chart.

Il flow chart serve in particolar modo per raccontare delle azioni, è lo strumento di base dell’interaction design. La mappa del sito invece è utile a descriverne 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 bene raccontati da una mappa del sito e in alcune parti, particolari azioni, possono essere illustrate tramite flow chart.

Annotated Wireframes e Specifiche funzionali

L’ultima parte del corso riguarda la creazione dei wireframe con annotazioni e le specifiche funzionali. Nathan Curtis ci mostra diversi wireframe creati in Indesign. C’è una separazione netta tra il layer contenente l’artwork da quello con le annotazioni.

Anche in questo caso si parte con un esercizio: disegnare il wireframe di un momento specifico del flow chart creato in precedenza. Scelgo di creare il wireframe per l’inserimento della nota spese e lo discutiamo in aula. Non ne si discute tanto la bontà del design quanto la capacità documentativa.

Si arriva di seguito alla definizione di wireframe: un diagramma che rappresenta il contenuto dello schermo e le priorità/importanza degli elementi. In modo meno astratto: è la risposta a “cosa vedono gli utenti sullo schermo?”, un modo per illustrare funzionamento e comportamenti.

Operativamente occorre chiedersi:

• chi è l’audience
• quanto aderente all’aspetto finale deve essere
• che livello di dettaglio si deve raggiungere
• in che formato finale viene presentato
• qual è il numero di persone che lavorano al documento (sviluppatori, IxD, information architect, copywriter, ..)
• qual è il minimo necessario che posso fare per le diverse audience?

Con ogni probabilità questo è il documento più dettagliato e comprensibile che gli stackeholder e l’intero team di progetto avranno sotto mano per diverso tempo, finchè non si iniziano a vedere 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 presentantdo, ovvero assicurarsene la fattibilità sia tecnica che a livello di orgranizzazione

Anche Nathan Curtis ha una sua metodologia operativa:

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

Il documento di UX, contenente il flow chart, mappa del sito e 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 la quantità di dettaglio alla quale si desidera arrivare, che annotazioni e artwork devono stare vicini e che deve esserci un formato standard per tutto il documento. Scegliere i template che si utilizzano per presentare variazioni di pagina o di componenti,  piuttosto che altri tipi di imamgine o di struttura.

Nathan Curtis prende in rassegna diversi tipi di annotazioni: overlay, callout e markers. In pratica negli esempi che mostra 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.

Fig 3. Notched marker e corrispondente annotazione.

La notazionè è numerata se si sta decrivendo una lista di oggetti, per favorire la lettura, mentre invece utilizza le lettere quando indica dati e tabelle, variazioni di pagina e componenti. Il marker deve essere posizionato con precisione in modo da non risultare ambiguo. Quando si mostrano variazioni di pagina, è bene non diplicare 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
• ne si identificano gli attributi, tipicamente:
  1. comportamento (es. onclick, onmouseover, …)
  2. stato (es. visibile|nascoso)
  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 è stato un momento importante del pomeriggio. Riassumendo quanto detto:

• 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, anche se si deve fare attenzione che non rappresentano visivamente il dato e quindi possono trarre in inganno come dimensioni (es: [codice fiscale], [nome], [cognome], …). Inoltre se si intende fare dei test di usabilità è meglio usare dati fittizzi/reali

Integrazione dei contenuti

Una delle sfide più ardue è l’integrazione deicontenuti 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, processi di approvazione e livello di dettaglio.

Se pensiamo a un progetto come composto 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 mododo da consentire:

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

Infine abbiamo commentato alcuni wireframe prodotti in aula. A scopo puramente dimostrativo prendo un già buon wireframe annotato e provo a commentarlo sulla base di quanto appreso durante il corso.

Fig 4. wireframe annotato esemplificativo. Fonte: ethnographic-consulting.com

Questo wireframe presenta una divisione in tre aree:

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

il wireframe descrive il contenuto delle quattro aree in cui è diviso lo schermo, anche se “get started” e il footer con l’about us non sono tenuti in considerazione. La scelta dello spazio riservato alle annotazioni mi fa pensare a un documento non particolarmente dettagliato, che descrive gli elementi funzionali e la navigazione. Per la scelta dei marker Nathan avrebbe preferito i notched marker, e un’enumerazione a lettere (A, B, C, …).

I marker non vengono ripetuti sul lato destro, con i contenuti, perdendo un po’ di leggibilità. Non sono visibili gli elementi interattivi, per i quali si dovrebbe utilizzare il colore blu (link, bottoni, …) . Le aree indicate dai marker sono omogenee e pertanto non è stato necessare usare un outline per indicarle.