Archivio > Architettura dell'Informazione, Design > Singolo: Page Description Diagram: cosa sono e come funzionano

Page Description Diagram: cosa sono e come funzionano

Introduzione

[Immagine] Esiste il giusto equilibrio fra design e contenuti? Se sì, quale strumento permette a designer e architetti dell'informazione di lavorare in parallelo senza influenzarsi a vicenda? Segue l'articolo sui Page Description Diagram.

Dovendo ridisegnare un intero sito web, spesso ci si chiede quale sia il metodo più efficace per permettere a designer e architetti dell’informazione di lavorare assieme sullo stesso progetto senza che un mestiere prevalga prepotentemente sull’altro. L’architetto decide quale contenuto sarà presente sulla singola pagina, il webdesigner prende questo contenuto e lo mette in risalto con un layout funzionale. In realtà questi due compiti presentano dei seri problemi sul piano pratico: innanzi tutto, come lavorare in cooperazione senza limitare il campo d’azione dei due ruoli? E in secondo luogo, come presentare al cliente lo stato del lavoro senza creare false aspettative?

In questo articolo mi propongo di illustrare gli strumenti utilizzati da designer e architetti dell’informazione per coordinare efficacemente i lavori all’interno di un team senza necessariamente costringere l’ambito dei due mestieri entro confini troppo risicati.

Wireframe

Quelli che nel gergo tecnico sono definiti wireframe, nel gergo comune non sono nient’altro che prototipi in forma di griglie. Queste griglie, che Andy Clarke nel suo libro chiama diagrammi in bianco e nero, sono composte da elementi geometrici semplici in grado di rappresentare quella che sarà la struttura del layout finale. In ambito 3D i wireframe vengono usati per schematizzare attraverso linee che sembrano fili di ferro (da qui l’origine della parola) la superficie di un oggetto tridimensionale. Wikipedia ne mostra alcuni esempi.

In ambito webdesign, i wireframe rappresentano in maniera molto chiara i lineamenti di una pagina, come fossero quelli di un volto. Nelle prime fasi di sviluppo del sito diventa così possibile illustrare quale sarà la resa del layout in cantiere in maniera semplice ed economica.

Su web.without.words ogni settimana […] un popolare sito web viene ricostruito rimpiazzando testi e immagini con blocchi colorati. Stile fase di concept (segnalazione di ). Questa galleria può essere di esempio per comprendere come effettivamente funzionano questi prototipi.

[Immagine] Esempio classico di wireframe: ogni elemento è contornato da una riga e ricalca più o meno fedelmente quello che andrà a costituire il layout del sito.

Ecco come apparirebbe l’homepage di LineHeight se fosse rappresentata tramite un wireframe.

Tuttavia, i wireframe presentano molti lati oscuri. Innanzi tutto, il loro significato è stato travisato col passare del tempo. Oggi abbiamo wireframe che mostrano contenuti testuali e tentano di descrivere l’interazione dell’utente con i vari elementi del layout.

Qui sorge il secondo problema importante: come valutare sin dall’inizio l’usabilità di una pagina attraverso anteprime statiche? E’ ovvio che un’immagine non può descrivere con efficacia l’interattività di un layout e, di conseguenza, ogni tipo di valutazione a livello ergonomico diventa impossibile. In più molte decisioni a livello visuale vengono prese in fasi successive, di fatto limitando di molto la creatività dei designer.

Infine, da parte del cliente si acquista la tendenza a dare per scontato che il prodotto finale coincida più o meno precisamente con i prototipi, creando false promesse e aspettative. In realtà il processo di sviluppo di un sito web è altamente dinamico e coinvolge un numero di fattori tale da impedire ogni tipo di previsione sul risultato finale.

Una soluzione al problema ce la suggerisce Jason Santa Maria nel suo articolo Grey Box Methodology.

Greybox

I greybox (letteralmente box grigi) nascono con l’intento di delinare un layout senza pensare all’estetica. Suona un po’ contraddittorio, ma l’idea di fondo consiste nel rappresentare un layout colorando ogni sezione di grigio senza aggiungere alcun tipo di contenuto testuale. In pratica, l’approccio è molto simile a quello dei wireframe ma consente più libertà dal punto di vista visuale, poiché le forme sono ulteriormente semplificate al fine di far emergere esclusivamente lo scheletro del layout. Rispetto ai wireframe c’è meno possibilità di fraintendimenti perché il livello di dettagli è ancora più basso. Se da una parte si hanno meno indicazioni, dall’altra si fanno anche meno promesse. Jason Santa Maria mette a disposizione alcuni esempi concreti di greybox.

[Immagine] Esempio classico di greybox: ogni elemento è colorato di grigio, senza contorni o indicazioni sul contenuto testuale.

Ecco come apparirebbe l’homepage di LineHeight se fosse rappresentata tramite greybox.

I greybox ereditano dai wireframe una certa staticità e al tempo stesso aggirano il problema dell’ergonomìa e dell’interazione rendendo il prototipo ancora più spoglio. Tuttavia, il problema delle false promesse persiste. Delineando la struttura generale di una pagina si ha ancora il concetto di spazi e posizionamento. L’essere umano si comporta in maniera molto specifica nei confronti delle distanze, poiché viviamo immersi in un modo apparentemente tridimensionale dove il collocamento di oggetti e persone può influire pesantemente sulla vita quotidiana.

Come fare dunque per astrarre di un livello ancora la rappresentazione schematica delle pagine? In pratica, come fare a descrivere la presenza di contenuto senza presentarlo effettivamente in maniera ordinata?

E’ in questo contesto che entrano in gioco i page description diagram.

Page Description Diagram

I page description diagram sono documenti in formato testuale che letteralmente elencano il contenuto presente su ogni singola pagina. La differenza rispetto a wireframe e greybox è che qui non c’è alcuna rappresentazione. In pratica si passa da immagini con un po’ di testo a testo con un po’ di immagini. Chiamarli specifiche sarebbe esagerato, ma quello che si ha davanti è esattamente la descrizione in formato testuale degli elementi che comporranno la pagina. Sostanzialmente siamo passati da un livello di dettaglio medio, ad uno basso, ad uno pressoché nullo.

Generalmente gli architetti dell’informazione scrivono questi documenti impaginandoli in orizzontale su tre colonne, come mostrato dagli esempi. Ogni colonna simboleggia un particolare livello di priorità, dal più alto a sinistra al più basso a destra. Il contenuto descritto nella prima colonna, quindi, è il contenuto importante, quello a cui i designer devono dare maggior risalto. Il contenuto descritto nell’ultima colonna, invece, va posizionato in modo tale da essere considerato solo in un secondo momento.

Il punto di forza dei page description diagram è che, eliminando completamente spazi e misure, essi consentono di descrivere perfettamente la storia dell’utente, affinché l’utente stesso raggiunga l’obiettivo specificato. Il vantaggio è che rimangono le aspettative, ma a discapito delle false promesse.

Scrivere questo tipo di documenti aiuta a focalizzarsi sugli obiettivi e sulle strategìe, per poi in un secondo momento dedicarsi agli aspetti estetici e a quelli più tecnici di sviluppo. La parte fondamentale in un sito web non la fa il design, ma il contenuto. Il contenuto è il Re, i page description diagram il suo trono.

[Immagine] Esempio classico di page description diagram: ogni elemento è descritto per via testuale in base all'importanza del contenuto che esso racchiude.

Ecco come apparirebbe l’homepage di LineHeight se fosse rappresentata tramite un page description diagram.

Caso studio: LineHeight 2

Ritrovandomi a dover disegnare il layout del nuovo LineHeight, la mia inesperienza mi ha portato a commettere alcuni errori di fondo.

  1. Lavorare direttamente su computer alla prima bozza di layout mi obbligava a considerare sin da subito schema di colori e tipografìa. A schermo si ha subito l’impulso di creare griglie perfette costruite con estrema precisione e rigidità. Tutte queste regole limitavano di molto la mia creatività, allungando e rallentando drasticamente i tempi di lavoro. A partire dell’header, mi sentivo costretto a considerare sin da subito l’aspetto del logo e della navigazione, allontanandomi da quello che era il mio obiettivo prinicipale: delinare la struttura del layout che avevo in grembo.

  2. Disegnare delle bozze su carta del layout ha semplificato di molto il lavoro, tuttavia ereditando dal primo punto alcuni problemi. Continuavo, cioè, a pensare sin da subito all’estetica, considerando il contenuto in funzione degli spazi a disposizione. Per esempio, avendo lasciato sulla destra più o meno un terzo della larghezza totale del foglio A4, ho pensato di sfruttare il poco spazio disponibile aggiungendo un box di ricerca con la lista delle ultime richieste al database. Le misure hanno cioè influenzato la mia scelta sui contenuti.

  3. Realizzando che i contenuti variavano troppo in base alle modifiche sul layout, ho provato a descrivere tramite una mappa concettuale il modo in cui gli utenti interagivano con la pagina: immediatamente è emerso il problema dei contenuti, e solo quello. Questo mi ha permesso di rispondere con facilità alla maggior parte delle domande importanti che mi ponevo nella mia mente:

    • Quali sono i contenuti importanti?
    • Che relazioni vi sono fra di essi?
    • Tali contenuti aiutano l’utente a raggiungere il proprio obiettivo?

Ed ecco che in un colpo solo risolvevo questioni di usabilità, reperibilità dell’informazione e interazione. Come tocco personale, oltre all’inidicatore di priorità ne ho messo uno che dirige l’azione: a partire da un elemento sulla sinistra si arriva con un percorso guidato ad un elemento a destra che dovrebbe portare l’utente a compiere una mossa (approfondirò questo argomento nei prossimi articoli).

La strategìa e ultime considerazioni

A partire dagli errori commessi, l’esperienza dell’astrazione mi ha permesso di costruire un sistema efficace per concretizzare lo sviluppo di siti web.

Si parte con i page description diagram, passando in un secondo momento per i primi schizzi su carta di quello che dovrà essere layout (paragonabili a dei greybox), fino ad arrivare alle rappresentazioni millimetriche su computer (wireframe) che daranno il via a prototipi dinamici, test d’usabilità e questioni tecniche che in questo articolo non vengono coperte.

E’ ovvio che questo sistema funziona bene per me e subisce pesanti variazioni all’interno di un team coordinato che lavora in parallelo. Tuttavia, il punto importante è comprendere che wireframe e greybox sono strumenti efficaci solo in un secondo momento, quando il problema dei contenuti è stato affrontato indipendentemente dalle disgressioni sul design. Fondamentale era capire quali fossero gli strumenti a disposizione per evitare collisioni fra mestieri fondamentalmente diversi come quelli dell’architetto dell’informazione e del designer. Una strategìa che volge in primo luogo ai contenuti è senza dubbio una strategìa vincente per tutti.

Approfondimenti

L'articolo è stato di tuo gradimento? Puoi controllare che vi sia altro di tuo interesse nelle categorie e , oppure iscriverti al notiziario RSS e seguirmi su per restare sempre aggiornato sulle ultime pubblicazioni.

Pubblicato mercoledì 14 gennaio 2009.

Discuti

Il blog è in sola lettura.

Paginatura: