Progettare l’informazione: intervista con Andrea Resmini

Andrea Resmini è uno dei più stimati architetti dell’informazione italiani. Lavora in FatDUX, una delle principali firm europee di User Experience con sede a Copenhagen ed uffici in giro per il mondo. Ha una formazione da architetto ed industrial designer, ma è attivo da vent’anni nel campo dell’ICT e una decina d’anni che si occupa di architettura dell’informazione (da qui spesso abbreviata con “IA”, Information Architecture”, ndr.).

Ha contribuito alla realizzazione degli ultimi due Summit Italiani di IA ed è uno dei fondatori del network europeo di architettura dell’informazione. Non basta: ha fondato e coordina REG-iA, il working group sull’alta educazione e la ricerca in IA, e dall’anno scorso è nel Board degli Advisors dell’Information Architecture Institute. Con REG-iA e IAI ha lanciato il 21 marzo la prima rivista scientifica di IA, il Journal of Information Architecture, il cui primo numero sarà disponibile a giorni.

Cogliamo l’occasione del suo intervento alla manifestazione fiorentina Better Software dal titolo progettare l’informazione per porgli qualche domanda e introdurre i temi del suo seminario.

Il titolo del tuo intervento del 6 maggio alle 14 è “(Ri)progettare l’informazione”. Di cosa parlerà?

A. Resmini: Della necessità di affrontare la progettazione dell’informazione da una prospettiva rinnovata ed in linea con il dibattito internazionale.
Mi spiego: il mio intervento nasce da una esigenza personale di comunicazione. Negli ultimi anni ho parlato di architettura dell’informazione ad un considerevole numero di seminari, workshop e conferenze: di queste relativamente poche erano in Italia. Al Summit italiano abbiamo sempre pensato che dar voce alla comunità fosse più importante che ritagliarsi un proprio spazio personale: il nostro intervento come organizzatori è limitato all’espressione di un tema e di un taglio critico. E credo che la scelta stia pagando.
Ma partecipando alla discussione internazionale diventa immediatamente ovvio come l’Italia viva una situazione particolare: ad una attiva comunità IA, piuttosto presente anche fuori dai confini, non sembrano corrispondere una appropriata maturità e visibilità interne. Questo riguarda anche il mercato di riferimento.

Perché questa carenza di visibilità, secondo te?

La mia idea è che ancora manchino diffusamente i presupposti per comprendere perché si debba parlare di architettura dell’informazione e che, quando questi ci siano, regni tutto sommato ancora un po’ di confusione. Mi sembrava una buona cosa portare questo tipo di contributo ad una conferenza indirizzata principalmente ai decision makers.

Cosa vuol dire dal tuo punto di vista “progettare” l’informazione? Uno suppone che l’informazione non si progetti, ma si dia come acquisita, come dato di partenza. Perché e come sul web è importante progettarla?

Quando parliamo di progettazione dell’informazione non parliamo del singolo contenuto informativo, della singola notizia per così dire, ma proprio della struttura generale con la quale le informazioni vengono veicolate.
Se pensi ad un giornale, al fatto che esistano regole per avere una prima pagina con l’editoriale, la notizia principale su tre colonne, e poi la cronaca, la pagina delle lettere, la sezione dello sport, e che ognuna di queste obbedisca a precise regole interne riproposte ad ogni edizione, hai un ottimo esempio di architettura dell’informazione. Poi pensa ad un libro: convenzioni diverse. Ed infine pensa agli scaffali di un negozio. Un sito web può essere tutte queste cose, anche insieme, ed altre ancora che non hanno un diretto equivalente nella nostra esperienza quotidiana.
Per questo motivo è necessario progettarne l’architettura dell’informazione: per consentire alle persone di fruirne in modo efficiente. Un giornale organizzato come uno scaffale sarebbe forse interessante, ma probabilmente poco utile alla lettura. Quindi, si progetta l’informazione perché senza progetto non si dà reale comunicazione, ma solo estemporanea trasmissione di rumore.
E consentimi una precisazione: il mio discorso non si limita al web. Sono ormai un paio d’anni che io e Luca Rosati lavoriamo su quelle che sono tecnicamente definite esperienze ponte¹. L’assunto base, citando l’Institute for the Future, è che “il cyberspazio non è un luogo in cui recarsi, ma uno strato saldamente integrato al mondo che ci circonda”.
E’ l’everyware di Adam Greenfield, o se vuoi quello che Morville ha seminalmente descritto dal punto di vista dell’IA in Ambient Findability. L’ultimo libro di Luca (Rosati, ndr.), Architettura dell’Informazione, racconta piuttosto bene questo processo.

Mi pongo dal punto di vista di un lettore qualsiasi e a questo punto mi chiedo: sì, è vero, ma libri, giornali, scaffali (e siti) sono già progettati. Cioè, esistono già figure professionali che da anni si occupano di costruirli per la miglior fruizione, per il miglior effetto. Anche per questo, a mio parere non viene percepita in Italia una funzione specifica dell’architetto dell’informazione. In cosa consiste la sua peculiarità? E’ una questione di metodi? Di ambito di ricerca?

Forse più di ambito che di metodi, per quanto, pragmaticamente, l’IA come definita da Rosenfeld e Morville è un’IA di metodologie e deliverables. Pensa ai wireframes, ai casi d’uso, o ai content inventory. L’ambito dell’IA è sicuramente lo spazio degli hyperlink, che è uno spazio nuovo, con caratteristiche proprie e peculiari, come abbiamo detto. Come esistono figure professionali che da anni si adoperano per il design dello scaffale, esistono e devono esistere figure professionali che si occupano della progettazione di questi nuovi spazi informativi. Gli architetti dell’informazione sono una di queste figure, anche se non certo l’unica.
E’ quindi insieme, forse, sia un problema di comprendere le peculiarità di un nuovo mezzo, sia una questione di maturità. Se centocinquanta anni fa fare il regista aveva un significato univoco, curare un allestimento di tipo teatrale, oggi il termine da solo può non essere sufficiente in alcuni contesti, poiché si può essere registi specializzati in cartoni animati, in programmi televisivi, o registi di clip musicali. Il processo ha richiesto tempo, e lo stesso sta accadendo adesso con il linguaggio della comunicazione in rete.

Il problema ricorda quello dell’usabilità web in Italia 10 anni fa. Quando ho aperto usabile.it, nel 2000, c’era in Italia una diffidenza verso i temi dello user centered design e in generale dell’osservazione dell’utente all’interno del processo progettuale sul web, che era orientato a logiche produttive basate su due grandi binari: quello informatico ingenieristico, e quello pubblicitario/comunicativo, ed entrambi non prevedevano un certo tipo di processo di verifica.
Questa diffidenza oggi in parte resiste, ma in parte, almeno in alcuni ambiti, è superata, grazie ad un lavoro che in molti stiamo facendo pazientemente in tal senso. Per la mia esperienza direi che si riesce a far percepire l’utilità del proprio ruolo, della propria attività, quando si comunica una funzione peculiare, con fondamenti teorici e metodi specifici che lo caratterizzino e che portino un’utilità pratica non altrimenti raggiungibile. Ecco, come pensi si caratterizzi, in questo campo, l’IA? Metodi, teorie, che non sono svolte da altre figure? Non potrebbe più ampiamente essere inserito nel termine cappello di “interaction design”?

Sicuramente non si può parlare di interaction design (spesso abbreviato come IxD, ndr.) come termine cappello. L’IxD è casomai una disciplina sorella, con compiti / metodi parzialmente comuni, nata come la intendiamo oggi nel 2003. Peter Boersma racconta bene la relazione nel suo modello a T (in prima versione leggermente diverso), non il primo (2004-2005) ma sicuramente il più noto. La disciplina contenitore potrebbe casomai essere lo user experience design (o UX, ndr.), come dice Peter (e tanti altri, incluso recentissimamente Jesse James Garrett), se mai questa definizione avesse un senso. Ma questo dell’UX è un discorso lungo e complicato e con poca attinenza a quanto stiamo discutendo.
Come vedi comunque, una certa confusione lessicale esiste, ed era a questa che faccio riferimento quando dico che la situazione non è chiarissima.

E in effetti questo potrebbe essere un problema da risolvere per far percepire l’importanza dell’IA. Intanto, nel tuo intervento a Better Software, parli di “ri-progettazione”. Si intende che un’informazione (o una sua organizzazione) è già stata progettata, e che bisogna tornarci su?

Il senso del titolo, che comunque come tutti i titoli cerca di essere in qualche modo ammiccante ed allusivo ed è per questo almeno parzialmente traditore, è che i tempi sono maturi per riconsiderare la progettazione dell’informazione e portarla oltre il discorso puramente o largamente biblioteconomico che ancora molti considerano prevalente e che stava alla base del famoso Polar Bear di Rosenfeld e Morville (Architettura dell’Informazione per il World Wide Web).
C‘è un ampio dibattito internazionale in corso su quali siano i confini e le rispettive competenze di buona parte delle discipline afferenti alla progettazione del digitale. Spesso non ci si accorda nemmeno sui nomi e sulle definizioni: information architecture, user experience, interaction design, user interface design, content strategy, digital design, La mia posizione personale, suffragata da un minimo di ricerca ed espressa anche in un articolo pubblicato a Febbraio dall’ASIS&T Bulletin e scritto con D. Madsen e K. Byström (IA Growing Roots), è che questo sia insieme un processo naturale nella maturazione del campo, ed anche un riflesso della accelerazione causata dalla conversazione globale in corso sul Web, un medium per sua natura ricombinatorio e non lineare. Andrew Hinton ha scritto cose interessantissime su questo problema.
Comunque sia, per rispondere direttamente alla tua domanda, sì, l’informazione è già stata considerata come progettabile. Come ho detto prima, parliamo di progettazione del contenitore, non del contenuto. Quello che sta cambiando o che è già cambiato, a seconda del dove ci vogliamo collocare nel discorso critico sul Web 2.0, è che questa informazione prima è andata largamente in mano agli utenti, ed ora sta uscendo dai computer ed entrando dovunque, non solo nei cellulari ma anche in tutta una serie di dispositivi che ci portiamo in giro, che troviamo in giro, e che ci fanno interagire costantemente e direttamente con pure informazioni. Se non vogliamo subire il cambiamento, dobbiamo progettarlo.
La seconda anima dell’IA, quella che in un certo senso fa capo a R. S. Wurman e al suo famoso libro “Information architects” e che alcuni vedono più legata all’information design ed al design tradizionale, è secondo me fondamentale in questo processo. D’altronde anche Rosenfeld e Morville nella terza edizione del Polar book sono arrivati a dire che IA è anche una comunità di pratica “focused on bringing principles of design and architecture to the digital landscape.” In questo senso parlo di riprogettazione e non di progettazione tout-court, ed è come ho già detto un discorso che investe sia chi chiede che chi offre, designer e committenti. E per essere chiari su quale sia la mia posizione su tutto questo chiacchierare in relazione al web sociale: un sito come Facebook poggia su un enorme lavoro di IA per la creazione del contenitore. I contenuti, poi, sono ovviamente opera degli utenti. Né più né meno di quello che accade con una casa, direi.

In quali attività consiste questa (ri)progettazione? Chi la svolge?

Una precisazione: intendo (ri)progettazione ad un livello decisamente astratto. Un nuovo modo di approcciare il progetto, non una nuova serie di best practices o di istruzioni punto per punto. Arriveranno anche queste, ma per ora personalmente non mi interessano. Quanto a chi la svolge, sicuramente gli architetti dell’informazione, ma come sappiamo benissimo quando si parla di comunicazione si parla di team di lavoro. Il cambio di prospettiva deve investire tutti gli attori del processo, e torniamo al perché mi sembrava interessante parlarne in una conferenza come Better software.
Come avrai capito, quando si parla di questi temi tendo ad essere piuttosto massimalista. E c‘è un motivo: sono circa 12-15 anni che esiste un’attiva comunità di IA. Molto è stato fatto dal punto di vista delle metodologie empiriche e degli strumenti di controllo della lavorazione. Molto poco o quasi nulla è stato fatto ad oggi per una sistematizzazione della parte teorica e critica della disciplina. Pochi libri, poca ricerca, poca visione d’insieme. Ho scritto di questo in diversi recenti post (ad esempio Big rock, small rock, and chorizo sausage) ed in alcuni articoli. Questo tra l’altro è l’assunto di base che ha guidato la creazione del working group sulla ricerca e l’alta educazione in IA e l’iniziativa del Journal of Information Architecture. I primi architetti dell’informazione con una preparazione universitaria specifica stanno entrando sul mercato statunitense e nordeuropeo oggi: se vogliamo che pratica professionale e disciplina scientifica procedano insieme per lunghi anni, questa revisione è un passo necessario. Quell’articolo dell’ASIS&T Bulletin che ho citato prima riassume molto di questo discorso.

Io lavoro spesso con realtà medie e piccole, tipiche dell’Italia. Quali sono le attività più importanti omesse da enti e aziende piccole e grandi nella gestione dell’informazione su un sito web?

Domanda complessa. Un dato di fatto è che la realtà italiana è sicuramente particolare. Per certi versi viviamo ancora di incertezze e ripensamenti per quanto attiene alla viabilità del web come strumento generalizzato di comunicazione a tutti i livelli, incluso quello istituzionale: noi italiani siamo ancora culturalmente anti-tecnologici ed inclini al pensiero magico ed apotropaico. Come risultato, abbiamo enormi ritardi e inusitate fughe in avanti, e mai una strategia solida. Aggiungo come osservazione personale che mi sembra che la tecnologia penetri solamente dove sostiene la comunicazione immediata, orale, come con la telefonia cellulare. E mi domando se il recente boom italiano dei social network non abbia qualche relazione con questo aspetto della mentalità nazionale.
Detto questo, onestamente non conosco sufficientemente a fondo la realtà imprenditoriale italiana per poter offrire una critica puntuale, ma non credo però di sbagliare molto se sostengo che ancora in larga parte non consideriamo l’informazione via web come una parte integrante ed abilitante delle strategie imprenditoriali. Il telefono? Certo. Il fax? Ovviamente. Il sito? Hm, vediamo. Il dominio lo abbiamo comprato, no? Quindi paghiamo qualcuno per salire nei motori di ricerca, e siamo a posto. Ovviamente è un esempio estremo e non mancano i picchi di eccellenza, ci mancherebbe, ma temo che la situazione generale non sia ancora molto distante da questo ragionare.

Per la mia esperienza, sì, è ancora abbastanza vero, anche se mi pare – lo dico timidamente – di scorgere qua e là, anche in realtà relativamente piccole, qualche segnale di cambiamento di questa mentalità, e un’attenzione crescente per il web all’interno di una strategia di comunicazione più ampia. Ma è chiaro che le realtà piccole non possono muoversi e ragionare come quelle grandi. Prova dunque qui ad abbozzare una qualche idea/strategia per gestire/progettare l’informazione che sia scalabile. Quali strategie possono adottare anche strutture piccole (comuni, associazioni, piccole aziende o addirittura aziende monopersonali), che possano facilitare una miglior progettazione e gestione in genere del loro contenuto informativo sul web?

Un’altra bella domanda, a cui credo però sia difficile dare una risposta concreta e soddisfacente nel corso di una chiacchierata. Direi che sarebbe già un passo fondamentale rendersi conto che il problema non è tecnologico. Non sono certo il primo a dirlo, non sarò l’ultimo, ma il problema non è questo o quel CMS, AJAX sì o no, o microformats. E nemmeno RDF o OWL. Il problema è progettuale. E un problema progettuale deve essere risolto da specifiche figure professionali, che di converso sono solitamente esterne all’azienda. Il ruolo dell’azienda, soprattutto se piccola, dovrebbe essere quello del committente informato e partecipante, e nessuno di questi due aggettivi oggi mi sembra accostabile alla situazione media italiana. Ma ribadisco, è un’opinione filtrata dal confronto con l’estero, e forse troppo pessimista.

Come si pone l’architettura dell’informazione (o la tua particolare accezione di IA) di fronte al fatto che, in quanto basato sulle azioni degli utenti, il web è un ambiente dove, più che in altri campi, il comportamento dell’utente dovrebbe essere preso come punto di paragone e confronto?

Personalmente ritengo tu dica una cosa corretta quando sostieni che i risultati debbano essere in qualche modo valutati e validati, ma non sono sicuro che vediamo allo stesso modo il processo. L’usabilità è una disciplina di valutazione post facto, in larga parte legata a standard misurabili ed a metriche consolidate. L’architettura dell’informazione, così come l’interaction design, è (o dovrebbe essere) una disciplina di progetto.
In ogni disciplina progettuale, il progettista ha il compito ultimo di sintetizzare una visione: in ruoli e momenti diversi, nel campo del digitale questi compiti ad oggi sono assolti dagli architetti dell’informazione e degli interaction designer. Se questa visione sia vincente o semplicemente adeguata, oltre il limite del rispetto di tutta una serie di euristiche e regolamenti (dove questi esistano), credo sia largamente demandato ad altre figure professionali, come ad esempio gli esperti di usabilità.
Se parliamo di metodologie, ad oggi lo UCD è largamente utilizzato in fase progettuale. La sua diffusione è sicuramente un fatto positivo, e non esiste progetto di una certa dimensione che non utilizzi personaggi, o valuti alcune scelte organizzative con freelisting o card sorting.

In Europa, immagino. In Italia un po’ meno. Un po’ più di ieri, ma ancora non in maniera prevalente, purtroppo.

A me personalmente ogni volta che si dice UCD viene in mente il manzoniano ‘adelante con juicio’, anche perché ritengo, in compagnia di Jared Spool, che ci sia molto poco di nuovo sotto il sole. Certamente gli utenti sono una componente del progetto, ma non l’unica, e a volte nemmeno la predominante. L’ergonomia non l’abbiamo inventata ieri, e non è che progettando una forchetta posso ignorare che gli esseri umani hanno certe dimensioni o certi gradi di libertà posturale più di quando progetto menu di navigazione o drop-down box. Se la mia forchetta non entra in bocca, è tagliente, o pesa dieci chili, forse è un’opera d’arte, ma sicuramente non un è oggetto di design. Lo stesso avviene con un menu di cento voci. Sarà la mia formazione, ma io mi occupavo di personas e di rapporti visione-testo già negli anni 80 e non in relazione al web o al software, e senza voler sminuire l’impatto della sola idea di dover ‘pensare agli utenti’ faccio fatica a gridare alla rivoluzione.

Nessuno di noi (specialisti di usabilità) pretende di rappresentare una novità o una rivoluzione. I metodi che usiamo hanno una storia e non sono nuovi, le teorie e le ricerche sono ben fondate, eccetera. Il problema è che nel tradizionale processo progettuale italiano nel web (talvolta anche nel software, specie in realtà piccole) semplicemente questi metodi “non nuovi” non vengono usati. Che siano vecchi o nuovi, dal mio punto di vista è irrilevante, basta che siano efficaci e utili. E, se sono utili, dovremmo utilizzarli…

Io credo che, ed è uno dei temi caldi seguiti all’ultimo IA Summit di Memphis, oggi manchiamo di un linguaggio di critica specifico come invece abbiamo per il disegno industriale o per il cinema, e ci risulta difficile analizzare con una certa chiarezza di significati quanto viene prodotto ed utilizzato. Processo tra l’altro che è uno dei primi gradini di quella valutazione il più possibile oggettiva delle esperienze a cui fai riferimento tu.
In definitiva, credo che tutto torni al processo di maturazione del campo della progettazione del digitale di cui parlavamo prima, e che è alla base della mia partecipazione a Better Software. I ruoli devono diventare più chiari a tutti, progettisti, clienti, ed utenti, e se ci parliamo e ci conosciamo è decisamente meglio.

L’intento di questa intervista è proprio quello di contribuire in tal senso. L’idea che tu proponi di una usabilità “post facto” è ancora molto diffusa, ma io e altri ci stiamo muovendo da tempo per sottolineare come, in realtà, l’usabilità è più utile durante il progetto, quando c‘è tempo di implementarne i risultati, non dopo. A progetto finito o quasi finito, ritengo non abbia nemmeno senso fare usabilità (a meno di non voler mantenere dei benchmark per uso interno). È evidente dunque l’urgenza di far comunicare di più e meglio le diverse discipline coinvolte nella progettazione anche per risolvere queste differenze di visione, e ti ringrazio per la disponibilità. Speriamo che altre occasioni vengano in futuro.

Me lo auguro, e grazie per avermi dato l’opportunità di una bella chiacchierata. Alla prossima.

Il seminario di Andrea Resmini è in programma mercoledì 6 maggio alle ore 14.

Se siete interessati ai temi di Better Software potete leggere anche l’intervista a Gianandrea Giacoma e Davide Casali sulle interfacce sociali e i social network.

¹ A bridge experience is one in which the user experience spans multiple communications channels, document genres, or media formats for a specific, tactical purpose”. Grossman Joel, Designing for bridge experiences. ^

L’usabilità delle tag cloud

Nel web si sono recentemente diffuse le tag cloud (nuvole di tag), una forma di visualizzazione dei dati che mostra un gruppo di parole (tag: cioè etichette relative ad un argomento) di grandezza differente. Le parole o etichette verbali più usate hanno un font più grande, quelle meno usate un font più piccolo. Lo scopo è dunque quello di pesare la grandezza delle parole in base alla loro frequenza. Oltre alla grandezza, le parole possono essere organizzate alfabeticamente, per similarità semantica, oppure casualmente. Le voci sono di solito link che portano ad un elenco di oggetti collegati a quella voce. Le tag cloud vengono dunque spesso usate come strumenti di navigazione.

: La tag cloud dell’autore di questo articolo da delicious.com. In questa visualizzazione i tag sono ordinati alfabeticamente e oltre alla dimensione, viene usato il colore del font per differenziare i tag in base alla frequenza. In pagina sono disponibili controlli per modificare questo ordinamento, per cercare un tag o per modificare il numero di quelli disponibili.

Le parole possono riferirsi a cose diverse: possono essere gli argomenti o categorie usate negli articoli di un sito, oppure le parole che utenti diversi hanno assegnato ad un oggetto, ad esempio una foto. Le tag cloud sono state rese popolari proprio da servizi di User Generated Content (contenuti generati dagli utenti) come Flickr o Delicious. Gli utenti quando salvano o scoprono una risorsa, vi associano dei tag come chiave semantica per un futuro recupero.

I tag possono insomma essere visti esattemente come parole chiave, ma usate in maniera meno sistematica, per nulla gerarchica (anche se questo è un chiaro limite e alcuni servizi iniziano ad offrire un modo per organizzare gerarchicamente i tag) e più casuale.

Una volta assegnati i tag agli oggetti, le nuvole di tag vengono usate per presentarli all’utente quando si vuole ritrovare qualcosa. Il loro uso si è poi esteso su blog e siti in genere. Nonostante il loro ampio utilizzo, solo recentemente si è iniziato a indagare sull’effettiva usabilità delle tag cloud. Sono un buon metodo per ritrovare le informazioni?

Una ricerca sulle tag cloud

Martin Halvey e Mark T. Keane hanno presentato nel 2007 una loro ricerca con sei diversi metodi per presentare elenchi di voci, fra cui le tag cloud. Chiedevano poi agli utenti di trovare e selezionare alcune voci (città europee) in elenchi formati casualmente da una base di dati. Gli elenchi potevano assumere il seguente formato:

Nuvole di tag in ordine alfabetico
Nuvole di tag casualmente ordinati
Elenchi orizzontali alfabetici
Elenchi orizzontali casualmente ordinati
Elenchi verticali alfabetici
Elenchi verticali casualmente ordinati

I pesi alle parole venivano assegnati a caso. Sono stati sottoposti 62 soggetti a 1231 compiti di selezione, e registrati i tempi di esecuzione (i compiti hanno tutti avuto successo). Il risultato peggiore si è registrato proprio per le tag cloud! In realtà tutti i formati di presentazione che presentavano le voci disposte in maniera casuale, presentavano tempi mediamente più alti rispetto a quelli alfabetici. Ma anche fra gli alfabetici le tag cloud portavano a prestazioni peggiori.

Indicazioni meno ovvie sono giunte dall’esame della grandezza dei font nelle parole: sebbene in generale le parole più grandi venivano trovate con maggior facilità, alcuni partecipanti giudicavano complicato trovare parole grandi.

Un altro risultato della ricerca piuttosto interessante riguarda il tempo di selezione di un termine in relazione alla sua posizione. Le parole disposte in alto a sinistra in tutti i formati erano trovate più velocemente, congruentemente con il verso di lettura occidentale. Ma molto rapidi sono stati anche i tempi di ritrovamento di parole poste nell’angolo in basso a destra, o al centro della riga centrale. Questo sembra indicare che tendiamo a scorrere rapidamente gli elenchi o le nuvole di tag, anziché leggerle.

Sono noti anche studi di usabilità (in tedesco, ma vi è un riassunto in inglese in PDF) dove gli utenti giudicano la rappresentazione delle etichette a forma di nube generalmente difficile da comprendere (in particolare chi non è abituato non capisce perché alcune parole siano più grandi di altre) e difficili da usare, caotiche. Chi le conosce può comunque scegliere di usarle per risolvere alcuni tipi di compito particolari.

Una conclusione parziale

Le tag cloud vengono usate sempre di più con vari scopi (per esempio analizzare in maniera rapida un testo, come nel caso di Wordle). Tuttavia non vi sono per ora evidenze che ne supportino l’efficacia come meccanismo di navigazione, di selezione di voci e di impression formation. Resta da capire quanto uno strumento del genere possa fungere da gadget, in un sito, e dunque fornire un elemento di divertimento che possa attrarre alcuni tipi di utenti: non abbiamo dati a riguardo. Anche in quel caso, però, è bene non contare sulla sola tag cloud come meccanismo di navigazione fra i tag.

L’esempio visto nell’immagine sopra tratta da Delicious è emblematico. Anzitutto, la tag cloud non è presentata di default, ma bisogna selezionarla da una serie di link. Nella pagina dedicata, sono poi disponibili molti modi di filtrare e visualizzare i tag. Come dire: una funzionalità avanzata, utile per i più techies degli utenti, ma non in primo piano per l’utenza media.

La discussione qui svolta è necessariamente preliminare e semplificata, in attesa che nuovi esperimenti e nuovi risultati possano offrire alcune indicazioni più precise su quali possano essere i migliori campi di applicazione delle tag cloud.

Progettare la struttura dei siti: ampiezza o profondità?

La struttura ipertestuale di un sito è la forma che assumono i suoi collegamenti gerarchici a partire dalla home page. La struttura organizza il contenuto in più livelli, e può avere varie forme, varie ampiezze e profondità. Solitamente ad una certa struttura corrispondono dei menu che la rappresentano. Uno dei principali problemi progettuali è decidere la struttura ipertestuale e di navigazione migliore affiché gli utenti trovino facilmente ciò che cercano.

È dunque meglio avere menu di poche voci, ciascuna delle quali porta ad altre pagine con altri menu di poche voci, e così via, in molti passaggi (siti poco ampi, ma profondi), o è meglio avere molte voci nei menu fin da subito con un minor numero di passaggi (siti larghi e piatti)? Un esempio è nelle immagini qui sotto.

: Un esempio di struttura ampia e poco profonda: 11 pagine al primo livello, ognuna delle quali ha 5 pagine figlio.
: In questo secondo esempio vediamo la rappresentazione ad albero di una struttura profonda e stretta, con 3 pagine al primo livello, ognuna delle quali ha due pagine figlio, ognuna delle quali ha ancora due pagine figlio, ognuna delle quali ha altre due pagine figlio. Entrambe le immagini sono tratte dalla ricerca (sotto citata) di Bernard.

Privilegiare siti piatti

Le prime ricerche sulla struttura dei menu negli ipertesti risalgono agli anni 80, ben prima dell’avvento del web, e ottengono un risultato chiaro:

È meglio avere strutture ampie e poco profonde (cioè siti piatti, come nella prima delle figure qui sopra).

Con menu di molte voci e minor profondità gli utenti tendono a trovare più rapidamente ciò che cercano (Miller, 1981; Snowberry, Parkinson, & Sisson, 1983; Larson & Czerwinski, 1998; Norman, 1990). Però vi è un livello oltre il quale il numero di voci ad uno stesso livello deve essere contenuto, e la navigazione deve essere estesa in profondità. E’ difficile stabilire quale sia il limite massimo per le voci di un menu, ma, ad esempio, nel pionieristico lavoro di Miller, 64 voci su una stessa pagina portavano ad una performance peggiore rispetto alle condizioni intermedie che prevedevano due livelli di 8 voci ciascuna o 3 livelli di 4 voci ciascuna.

Sul web, dove la mole di pagine può essere molto alta e tende a crescere con il tempo, è necessario trovare dei compromessi, perché non è pensabile avere menu composti da decine di voci solo per mantenere il sito abbastanza “piatto” ed è dunque spesso necessario provvedere ad una articolazione in più livelli.

La struttura dei siti dipende dunque in maniera rilevante da come è costituito il suo contenuto e da come è possibile organizzarlo, tenendo anche conto dei seguenti aspetti:

un’adeguata qualità semantica delle etichette usate per i menu (devono essere sufficientemente precise – non ambigue – da essere correttamente scelte dagli utenti), di cui abbiamo accennato nell’articolo dedicato al profumo dell’informazione.
il tipo di compito eseguito dell’utente: non per tutti i tipi di compito la struttura migliore è la stessa.

L’influenza del tipo di compito

Già negli anni ’80 vi sono ricerche che evidenziano come l’organizzazione ottimale degli strumenti d’accesso ai nodi di un ipertesto fosse differente a seconda che lo scopo per l’utente fosse farsi un’idea generale di un contenuto organizzato come ipertesto, oppure trovare specifiche informazioni puntuali.

Recentemente Bernard ha condotto un’interessante ricerca dove ha comparato due tipi di compiti con 6 diverse strutture ipertestuali di circa 300 nodi ciascuna rappresentanti pagine in un sito di e-commerce. Le strutture andavano da un minimo di due livelli, articolati con un primo livello a 12 link e un secondo livello con 27 link (12 × 27), fino a strutture molto profonde, dove il primo livello consisteva di soli due link, seguito da un livello di 3 link, ancora da uno a 2, poi ancora a 3, ancora a 2 e ancora a 3 (2 × 3 × 2 × 3 × 2 × 3).

Ha osservato che se gli utenti ricevono istruzioni precise (esplicite) su cosa cercare (un orologio) sono in genere più rapidi che nel caso di ricerche basate su scenario o implicite (“devi fare un regalo ad un pilota che è sempre di fretta perché deve costantemente rispettare tabelle orarie precise”). Tuttavia le interazioni con le diverse strutture dei siti non erano significative: nessuna struttura era significativamente migliore o peggiore in relazione a solo un tipo di task.

Oltre la diatriba fra ampiezza e profondità: le forme delle strutture dei siti a confronto

La ricerca di Bernard si sofferma quindi sull’effetto che le 6 diverse strutture ipertestuali hanno su variabili come il tempo di ricerca e altre misure di efficienza, come il numero di deviazioni dal percorso ideale e il numero di ricorsi al tasto “back” del browser.

Con strutture più ampie e piatte (due e tre livelli, cioè 12 × 27 e 11 × 5 × 5) gli utenti commettono significativamente meno deviazioni e compiono navigazioni significativamente più veloci rispetto a quasi tutte le condizioni con un numero maggiore di livelli, in ciò confermando i principali risultati delle ricerche nel settore. La sorpresa sta nel “quasi”: infatti le due strutture più piatte non portano a risultati significativamente migliori di una struttura a 4 livelli, la 6 × 2 × 2 × 12, che ottiene risultati paragonabili.

Ma c‘è un altra scoperta notevole: una delle strutture a 4 livelli, la 4 × 4 × 4 × 4 è risultata meno efficiente non solo di un’altra struttura a 4 livelli, la 6 × 2 × 2 × 12, ma anche di una struttura più profonda, come la 3 × 2 × 2 × 2 × 12!

Ciò che Bernard conclude è che la profondità è almeno altrettanto importante della forma della struttura. Il risultato sperimentale sembra cioè suggerire che, almeno sopra i 2 o 3 livelli di profondità, le strutture convesse siano da preferire a strutture relativamente costanti. Cioè, strutture con un alto numero di link ai primi e agli ultimi livelli, e un minor numero di link (di scelte possibili) ai livelli intermedi sono da preferire a strutture con un costante numero di link su tutti i livelli. Analoga conclusione era stata ottenuta da una ricerca di Norman e Chin, 1988, ma solo per i compiti impliciti (basati su scenario).

La spiegazione offerta per questi risultati è abbastanza intuitiva e congruente con la teoria del “profumo dell’informazione”: offrire all’inizio della navigazione un maggior numero di indizi semantici che rappresentino il contenuto dei livelli successivi aiuta a scegliere la strada giusta. Al livello finale, avere un elevato numero di link aiuta a ridurre l’incertezza della scelta proprio dove è più importante scegliere il contenuto corretto.

Viceversa, ai livelli intermedi avere troppe possibilità di scelta, in un momento in cui la precisione semantica è necessariamente intermedia, aumenta le probabilità di scegliere la strada sbagliata. Potremmo dire che “distrae”.

Oltre l’efficienza

Zaphiris ha pubblicato una ricerca che prende in considerazione anche la percezione di difficoltà, oltre che i tempi di esecuzione, per 5 diverse strutture ipertestuali, e ha notato che non necessariamente le strutture più efficienti sono le preferite. In particolare, sembrano preferite le strutture che lui chiama eterogenee, cioè con maggior diversità: prima pagina con 4 link e seconda pagina con 16, o prima con 16 e seconda con 4, rispetto a strutture dove i livelli successivi avevano un numero di link uniforme. Il suo studio è congruente con quello di Bernard, anche se il tipo di strutture utilizzato da Zaphiris non lo porta a concludere che sono preferibili le strutture convesse, soprattutto perché… lui non utilizza strutture convesse: quelle che chiama eterogenee sono composte da soli due livelli, troppo pochi per la convessità.

Tuttavia viene scoperto che anche a livello di preferenze le strutture omogenee (o costanti, come le chiama Bernard) sono poco gradite, oltre che poco efficienti. Il giudizio soggettivo conferma indirettamente le spiegazioni “psicologiche” tentate sopra delle ragioni di queste prestazioni.

Alcune conclusioni

Le ricerche più recenti sembrano confermare l’idea che, in generale:

per i siti basati sul contenuto strutture ampie e poco profonde siano preferibili a strutture strette e profonde
per siti la cui articolazione dell’informazione è complessa e necessita di un numero maggiore di livelli, è importante usare strutture convesse, con un maggior numero di link all’inizio e alla fine del percorso
l’efficienza non è tutto, perché le preferenze degli utenti non sempre coincidono con le metriche di efficienza: in casi controversi è particolarmente importante verificare le scelte con campioni di utenti
appare comunque assodato che vanno evitate strutture omogenee o costanti.

Rapporti con l’architettura dell’informazione

Ricordiamo che la struttura di un sito non è la sua architettura dell’informazione: è la struttura dell’albero ipertestuale principale. L’architettura dell’informazione va oltre, stabilendo vari tipi di relazioni fra i dati, non solo quella gerarchica. Fra nodi dell’albero possono in altre parole esistere molti modi per accorciare le distanze e saltare di sottoramo in sottoramo, basati sulla correlazione delle informazioni secondo chiavi diverse (o secondo faccette che enfatizzino una descrizione diversa del contenuto rispetto a quella dell’albero gerarchico).

Tuttavia, anche adottando classificazioni multiple delle informazioni, è bene che la struttura gerarchica principale di un sito (ma anche quella eventuale delle faccette o di altri criteri adottati) tenga conto dei risultati qui esposti ogni qual volta sia prevista una navigazione dell’utente attraverso menu successivi, e si preferisca una strutturazione dei menu e delle voci che sia, oltre che semanticamente significativa per gli utenti, ampia soprattutto all’inizio e alla fine del percorso di navigazione. Meglio invece se i livelli intermedi vengono eliminati: ma se non possono venir eliminati, è senza dubbio preferibile che a quei livelli venga ridotto il numero delle scelte disponibili, per evitare di portare fuori strada gli utenti.

Bibliografia

Kiger, J. I. (1984). The depth/breadth tradeoff in the design of menu-driven interfaces. International Journal of Man-Machine Studies, 20, 201-213.

Larson, K. & Czerwinski, M. (1998). Web page design: Implications of memory, structure and scent from information retrieval (Pdf, 1MB circa). Proceedings of the Association for Computing Machinery’s CHI ’98, 18-23.

Miller, D.P. (1981) The Depth/Breadth Tradeoff in Hierarchical Computer Menus, Proc. HFES 25th Annual Meeting, 296-300

Norman, K., L. (1990). The psychology of menu selection: Designing cognitive control of the human/computer interface. Norwood, NJ: Ablex Publishing co.

Norman, K., L. & Chin, J. P. (1988). The effect of tree structure on search performance in a hierarchical menu selection system. Behaviour and Information Technology, 7, 51-65.

Snowberry, K., Parkinson, S., & Sisson, N. (1983). Computer display menus. Ergonomics, 26, 699-712.

Zaphiris, P. (2000). Depth Vs Breadth in the Arrangement of Web Links, Proceedings of the 44th Annual Meeting of the Human Factors and Ergonomics Society, 139-144 (disponibile anche su Scribd).

Verso l’usabilità semantica

L’ingegneria dell’usabilità nasce in ambito software e da quell’ambito si sposta progressivamente sul web portandosi dietro armi e bagagli: ovvero un insieme di tecniche e di metodi già sviluppati per l’analisi dei problemi di utilizzo dei prodotti a base informatica: test con utenti, linee guida, euristiche, metodi formali basati sulla rigida scomposizione dei task in componenti elementari, e così via.

Negli ultimi anni però è andato aumentando il numero di studiosi che ha rilevato che questo armamentario rischia di non essere del tutto adeguato al web. In particolare hanno notato delle differenze nel modo in cui gli utenti si comportano nell’interazione web rispetto a quella con i software.

Paradigmi d’interazione software

Nel campo software i modelli dell’interazione sono basati sul compito (task). In generale hanno in comune una serie di assunti:

l’utente si muove di solito in ambienti noti (i software) e ad alta stabilità (ogni volta che li apriamo, i software si presentano in maniera simile alla precedente, e anche fra diversi software c’è un’elevata uniformità dei meccanismi di funzionamento), dove bisogna compiere una serie di azioni ripetute, che mirano allo stesso risultato nel tempo; è così possibile un apprendimento
solitamente l’utilizzatore ha delle competenze specifiche nello specifico ambito di applicazione di un certo software (l’utente di un programma grafico sa di grafica, un utente di un pacchetto di contabilità conosce la materia, eccetera) e questo rende possibile essere molto precisi nella terminologia o nella progettazione di certe sequenze d’azione che ad un principiante sembrerebbero molto difficili.
grazie alla standardizzazione offerta dal sistema operativo, poi, gli oggetti dell’interfaccia (bottoni, menu, slider, ecc) sono noti e il loro funzionamento è predicibile e costante
i paradigmi d’interazione sono coerenti: funziona sempre il doppio click, si può fare il trascinamento di oggetti, che sono manipolabili per selezione diretta.

In tale ambito è del tutto normale che gli studiosi misurino il tempo di esecuzione, il numero di azioni svolte, diano importanza all’efficienza e ai test con gli utenti. Infatti, se un compito complesso viene ripetuto frequentemente, l’efficienza gioca un ruolo importante, ed è ben tollerabile una certa difficoltà di apprendimento iniziale. Ce lo ricorda anche Andrei Herasimchuk, già progettista d’interfaccia di Adobe:

“Il mio principale obiettivo è quello di creare un prodotto che funzioni nella maniera più efficiente possibile per utenti esperti e ripetuti, poi per i novizi, e infine per gli utenti non esperti e occasionali”.

E del resto è logico. Perché alla fine ad imparare queste interfacce ci riusciremo, ma se il compito ha una struttura intrinsecamente complicata e non a misura d’uomo (se richiede troppi passaggi, o azioni controintuitive, o che non consentano una gestione sicura dei dati, o che obbligano a tenere in memoria molte informazioni su cosa fare in ogni punto), lo stress che ne consegue si ripeterà uguale ad ogni utilizzo del programma, creando un ostacolo all’uso quotidiano soddisfacente del prodotto. Se le cose stanno così, è anche facile identificare scenari d’uso precisi, su cui svolgere test di usabilità con alti margini di attendibilità.

L’interazione sul web

Il web è un ambiente in cui queste premesse non sono più vere. Almeno per quanto riguarda i siti informativi (per quanto riguarda le applicazioni web, valgono almeno in parte altri discorsi).

A differenza del software, vi è una variabilità elevatissima:

nessun sito è identico ad un altro, raramente passiamo su un sito abbastanza tempo da impararne le funzioni avanzate
non svolgiamo compiti ripetuti a parte la ricerca di informazioni
gli argomenti di ogni sito sono diversi e bassa è la nostra competenza nella maggior parte di essi
le pagine hanno una densità informativa (testi, titoli, link) di gran lunga superiore a quella dei software.

Non solo: anche sul piano dell’interazione vera e propria troviamo delle differenze. Molto spesso infatti:

gli oggetti d’interfaccia non sono standardizzati (i bottoni possono essere resi con immagini e non essere facilmente riconoscibili, i menu sono diversi da sito a sito e dobbiamo ricostruire i tratti comuni per capire che son menu, i link non hanno lo stesso colore, in alcuni casi i link visitati sono differenziati e in altri no, e potremmo continuare…)
gli stessi paradigmi d’interazione sono differenti: non vale più il doppio click, ma il click singolo (infatti è molto alta la percentuale di utenti che durante i test di usabilità su siti web cliccano inconsapevolmente due volte invece di una, a dimostrare che la confusione, percepita o meno, c’è)
il trascinamento non è possibile (se non in interfacce evolute, in ajax, flash, java, ecc.)
i tempi disponibili per l’apprendimento sono molto minori che nei software: data l’elevata competitività dell’ambiente, prima si riesce ad usare un sito e meglio è
ed è pure più difficile identificare scenari d’uso precisi per i compiti, che sono spesso vari e differenziati per utenti diversi.

Queste considerazioni hanno incoraggiato a seguire nuovi filoni di ricerca. Le ricerche mirano a costruire nuovi modelli teorici che ci consentano di capire meglio l’interazione degli utenti con il web, ma stanno anche iniziando a svecchiare la tradizionale cassetta degli attrezzi dello specialista di usabilità. Fra le ricerche che hanno dimostrato particolare efficacia ci sono quelle basate sulle valutazioni semantico-lssicali. In particolare si segnalano la teoria dell’Information foraging di Peter Pirolli e Stuart Card e il Cognitive Walkthrough for the web di Kitajima Blackmon e Polson.

Entrambe le teorie si basano sulla considerazione che sul web gli utenti cercano (e seguono) la voce che a loro sembra più corrispondente con i propri bisogni informativi. Danno dunque la prevalenza all’aspetto semantico dell’interazione, ma, e questa è una decisa novità, i modelli riescono a tenere in considerazione anche alcuni degli aspetti contestuali (conoscenze degli utenti, scopi, situazione).

Seguire il profumo dell’informazione

L’information-foraging introduce il fortunato concetto di scent of information, o profumo dell’informazione, definito come:

“la percezione imperfetta che l’utente ha del valore, del costo e del percorso di accesso a fonti di informazione ottenuto attraverso stimoli prossimali, come i link nel web.”

L’information-foraging è una teoria che ha sviluppato un proprio modello computazionale del comportamento dell’utente, lo Snif-act (parlando di profumo, che si può fare se non sniffare?…).

In questo modello sono previste una memoria dichiarativa e una memoria procedurale. Nella memoria dichiarativa viene rappresentato ciò che è attivato e di cui l’utente è avvertito in un certo momento, come ad esempio i link in una pagina web. Essendo basata su un insieme di associazioni fra pezzi di informazioni, la memoria dichiarativa stabilisce ciò che è più probabile attiri la nostra attenzione in un certo momento, stabilendo la rilevanza di certe informazioni rispetto ad un certo fuoco dell’attenzione corrente.

La memoria procedurale decide invece ciò che si può o non si può fare, in termini di condizioni del tipo “Se… allora…”. Sono le regole da applicare in ogni fase durante la simulazione del comportamento. In questo modello le informazioni sono confrontate con un database di “profumi dell’informazione”. Le stime ricavate da questo database sono basate sulle co-occorrenze di parole in un corpus tipico di testi, integrato con parole specifiche provenienti dall’ambito web.

Il modello si dimostra in grado di fare due previsioni:

Decidere quale link, fra quelli disponibili in una pagina, ha la maggiore probabilità di essere selezionato da un utente che abbia un certo scopo attivo nella memoria dichiarativa
Anticipare quale sarà il punto di abbandono del sito (quando il profumo dell’informazione è inferiore ad una soglia minima).

Confrontando il comportamento del modello con quello di utenti reali si è constatato che i link indicati come più probabili dal modello erano quelli che nella realtà la maggioranza degli utenti seguiva. Quando il modello rilevava un basso profumo dell’informazione sulla pagina, allora si verificava nella realtà il più alto numero di abbandoni. Durante i test empirici sul modello è emersa una differenza fra utenti esperti e utenti novizi rispetto alla materia di cui si occupa il sito (competenza di dominio). E’ necessario dunque ogni volta cambiare le regole di produzione del modello a seconda del dominio e del livello di competenza del tipo di utente da simulare.

Una simulazione cognitiva per il web

Nel Cognitive Walkthrough for the web la logica è simile, anche se i dettagli sono diversi. Secondo questo modello, il comportamento dell’utente è diviso in più fasi: dato un certo obiettivo, l’utente fa un parsing (un’elaborazione) della pagina, crea macro-oggetti visivi, si focalizza su uno di questi oggetti e confronta le etichette verbali ivi presenti con il suo obiettivo, fino a scegliere il link che gli sembra più simile al suo obiettivo. La comparazione avviene attraverso un meccanismo di rappresentazione della conoscenza detto LSA, Analisi semantica latente. LSA è un modello di rappresentazione della conoscenza ad elevata dimensionalità, dove per ogni coppia di termini vengono costruiti dei vettori di correlazione basati sulla co-occorrenza di questi termini in un corpus di testi che rappresenta la conoscenza tipica dell’utente (si tratta di testi comunemente studiati a scuola a seconda dell’età considerata). La correlazione è basata sui coseni dei vettori e varia fra -1 e 1.

Anche il CWW è stato testato empiricamente, e si è rivelato in grado di identificare con buona precisione 3 tipi di problemi:

Identificare titoli o link che sono troppo simili fra loro e possono così generare confusione concettuale nell’utente, che non saprebbe distinguerli chiaramente. Ogni coppia che ha un coseno superiore a 0,6 è considerata troppo simile, e viene suggerita la revisione di uno dei due termini.
Identificare termini che sono poco familiari ad un certo tipo di utente, attraverso la lunghezza del vettore di correlazione (che rappresenta la frequenza di quel termine nel corpus di testi considerato).
Identificare titoli e link che non sono simili fra di loro, ma che competono in relazione ad uno specifico obiettivo. Sebbene in generale l’utente non giudicherebbe simili quei due termini, li può giudicare egualmente rilevanti in relazione ad uno specifico obiettivo.

Pregi e limiti dei modelli semantici

Questi modelli sono giovani e promettenti, ma hanno tuttavia dei limiti. Il più evidente è che, essendo stati sviluppati in inglese, attendono una validazione in lingua italiana (e in altre lingue, naturalmente). L’italiano è una lingua meno paratattica dell’inglese, ed è possibile che ci siano delle difficoltà nel confermare i risultati del modello (è capitato anche nell’adattamento degli indici di leggibilità).

Inoltre bisogna fare molta attenzione a come si formulano gli obiettivi dell’utente. Solitamente si usano frasi come: “Ho bisogno di cercare il nome del regista del film con Colin Firth che è uscito qualche anno fa e che si ambientava in epoca vittoriana”. Se ben formulate, queste frasi definiscono anche delle informazioni sulle competenze possedute dall’utente. Un esperto di cinema (o qualcuno con una miglior memoria per i nomi…) direbbe infatti “Chi è il regista del film inglese “L’importanza di chiamarsi Ernesto” uscito nel 2003”?, il che darebbe vita ad associazioni e correlazioni differenti.

Il fatto che lo stesso obiettivo si possa esprimere in maniera verbale, anche con una formulazione complessa, e il fatto che questa formulazione decida le correlazioni con i link e i titoli presenti nella pagina è un punto di forza, perché una formulazione verbale di questo tipo è in grado di incorporare parte delle competenze e delle conoscenze dell’utente, ma può risultare in una debolezza nel momento in cui la formulazione verbale non sia abbastanza precisa, tanto da dare vita a correlazioni e valutazioni sbagliate.

Entrambi i modelli sono poi ancora carenti nella considerazione di altre variabili, come quelle visuali, e per tipi di compiti non basati sulla ricerca di informazioni, ma hanno il merito di porre l’attenzione degli analisti e dei progettisti sull’importanza determinante dei fattori lessicali e semantici nella progettazione di siti. Ormai è chiara una cosa (che non lo era affatto quando l’usabilità si occupava solo di software): la scelta delle etichette verbali è una delle chiavi della facilità d’uso dei siti.

Queste etichette, questi termini andrebbero sempre testati e andrebbe sempre ponderata con attenzione la possibilità che alcuni siano troppo simili, che si confondano fra di loro, o che siano poco significativi per l’utente in rapporto al link di destinazione. Il fatto che si studino strumenti in grado di dare delle stime di queste somiglianze o di questa significatività è una prospettiva senza dubbio intrigante.

Nota: una prima versione di questo articolo è apparsa a marzo 2005 sulla rivista “Internet Pro”. Questa versione è aggiornata e leggermente modificata.

Il design della navigazione

Lo scopo principale degli strumenti di navigazione di un sito, come
abbiamo visto, è quello di fornire all’utente indicazioni su
dove è e su dove può andare. Devono poter contenere informazioni
anche sui contenuti: ‘dove posso andare’ significa infatti ‘verso quali
contenuti/servizi posso andare’. Gli strumenti di navigazione devono
quindi farsi carico di compiti di comunicazione di struttura, contenuti
e funzionalità del sito, in maniera completa e al tempo stesso
flessibile. Vediamo attraverso quali passaggi è possibile ottenere
questi risultati. Al termine verificheremo i vantaggi pratici di un
piano di navigazione ben riuscito con un esempio reale.

Il primo passo: decidere la struttura.

Alla base di ogni scelta di navigazione vi sono accurate decisioni
che riguardano l’architettura delle informazioni, ovvero il modo in
cui avete deciso di suddividere logicamente le informazioni del vostro
sito. L’architettura informativa dà l’indispensabile struttura
al vostro sito, ed è di vitale importanza riflettere bene su
questo aspetto perché inciderà pesantemente su tutte le
scelte successive.

Non vogliamo riassumere in un breve articolo i metodi necessari ad
una buona progettazione dell’architettura informativa. Ci limitiamo
a descriverne uno dei più diffusi: il card sorting.

Secondo questa tecnica, ogni voce o unità informativa che si
intende comprendere nel sito andrà scritta su un cartoncino o
un foglietto, utilizzando una descrizione verbale semplice e significativa
per l’utente finale. Una semplice trasposizione delle attività
aziendali in gergo manageriale può non essere una buona idea,
perché il vostro utente potrebbe non avere le competenze adatte
per capire di che si tratta.

Una volta descritti tutti i contenuti sui diversi cartoncini, bisogna
dare ordine al caos. In una parola: raggruppare le voci. Il card sorting
prevede che questa attività di raggruppamento venga svolta da
diversi soggetti rappresentativi dalla vostra "utenza-tipo".
In realtà è più frequente che venga svolta da colleghi
o da persone di più facile reperimento… Chiedendo agli utenti
di raggruppare e denominare i contenuti nella maniera per loro più
significativa, comunque, vi assicurerete di evitare errori dovuti ad
una visione troppo centrata sulla vostra azienda o sui processi di management,
che solitamente sono troppo specialistici per l’utenza media.

Il vantaggio di utilizzare diversi soggetti tratti dall’utenza reale
è quello di verificare se il criterio di raggruppamento utilizzato
sia comune e condiviso. In caso affermativo, è molto probabile
che quello sia il criterio migliore per la vostra utenza.
In caso di difformità, invece, dovrete chiedervi a cosa possano
essere dovute. Forse i soggetti sono troppo disomogenei fra loro, o
forse i foglietti presentano nomi di difficile comprensione. In tal
caso, dovrete rivedere il processo, meglio se con l’ausilio di un professionista.

Qualunque tecnica utilizziate, è bene non sottovalutare questa
fase, perché un errore a questo punto del processo si rifletterebbe
negativamente sul prodotto finito, che sarà molto più
costoso correggere.

I problemi del labeling

Una volta trovati i criteri di raggruppamento del materiale che comporrà
il vostro sito, trovate i nomi giusti per indicare i diversi gruppi.
Anche siti che hanno una navigazione elementare possono presentare problemi
di labeling. Ad esempio, per la sezione di Usabile che elenca tutti
gli articoli pubblicati, voi quale voce scegliereste? Indice, Archivio,
Articoli, Elenco, o altro ancora?… L’indice può sembrare l’indice
del sito, l’archivio qualcosa che raccoglie documenti imprecisati, articoli
in italiano può richiamare articoli in vendita, mentre elenco
è decisamente generico…

Vogliamo fare un po’ i pignoli, ma non troppo: non sono rari i siti
ricchi di contenuti interessanti che utilizzano label (etichette verbali)
fantasiose ma ben poco significative per l’utente, che quindi non capisce
assolutamente dove cercare le cose che più lo interessano. Ponete
dunque l’adeguata attenzione a questa fase.

Se il raggruppamento è stato condotto appropriatamente, vi troverete
con alcune categorie concettuali di navigazione chiare e coese. Tipicamente,
potrebbero essere:

Categorie nelle quali sono suddivisi i contenuti o i prodotti (ad
esempio: libri, cd, dvd, software, ecc…)
Elementi di community (forum, mailing list, newsletter, caselle e-mail,
aree riservate)
Features del sito (helps, tour guidati, mappe del sito, contatti)

Tenete presente che in alcuni casi potreste aver bisogno di spazio
per una navigazione locale o secondaria: ad esempio, in una categoria
dei prodotti potreste trovar utile inserire ulteriori suddivisioni;
o ancora, potresete dover presentare informazioni accessorie e contestuali.
Accertatevi di prevedere nel layout finale lo spazio relativo.

Stabilire delle gerarchie

A questo punto inizia il processo di gerarchizzazione. Dovete decidere
quale di questi gruppi di link è più importante. In alcuni
casi è possibile che non riusciate a scegliere: ad esempio in
siti molto compositi come quelli delle pubbliche amministrazioni, o
in siti che si sono sviluppati in maniera disomogena nel tempo: volendo
dare importanza a tutto, finite per far competere gli elementi nel catturare
l’attenzione del visitatore. Ricordate: l’attenzione è una risorsa
limitata!

Se non ce la fate a stabilire delle chiare gerarchie, forse è
il segnale che dovete ripetere il processo di raggruppamento e categorizzazione
delle voci. Utilizzate altri criteri: da quello oggettuale a quello
funzionale, per esempio. Invece di elencare i tipi di prodotti, elencate
le possibili azioni che gli utenti possono voler fare. In pratica, se
utilizzando i nomi (es: alberghi, ristoranti, agriturismi, farmacie,
ospedali) non ottenete un risultato sintetico, attraverso una diversa
categorizzazione potreste migliorare notevolmente la vostra navigazione
(es. ospitalità, sanità, ecc.). In questa come in tutte
le fasi, la cosa migliore è chiedersi di cosa può aver
bisogno un utente reale visitando il nostro sito: orientate la navigazione
in maniera che sia un ausilio per le scelte d’azione dell’utente, piuttosto
che perché sia onnicomprensiva dell’azienda o dell’ente. Un sito
non è una brochure: non è fatto per essere guardato, ma
utilizzato con scopi precisi. Solo se non vi è niente che sia
possibile fare sul sito, un approccio ‘da guardare’ può essere
quello più adeguato.

I gruppi di voci istituzionali (relativi all’azienda o al ‘chi siamo’)
dovrebbero essere ben distinti da quelli relativi alle offerte o alla
struttura informativa. Il che non impedisce una certa ridondanza: è
possibile che vi sia un indice complessivo dei prodotti in un gruppo
di navigazione, e un elenco delle diverse categorie di prodotti a costituire
un altro gruppo. Fornire più vie d’accesso ai contenuti è
normalmente un aiuto per l’utente, a patto che i criteri delle diverse
categorizzazioni siano ben distinti e non si possano confondere.
Detto in maniera più semplice: non dovrebbero esserci due voci
possibili per la stessa azione, ma solo due voci per arrivare allo stesso
punto attravero azioni ed intenzioni differenti. Consultare un
indice è ben diverso dal cercare all’interno di una precisa categoria
dei prodotti, ma in entrambi i modi posso giungere al prodotto.

Tuttavia il percorso logico che indicherà la strada delle varie
pagine rimarrà sempre lo stesso (non si modificherà a
seconda della via d’accesso). Infatti il path, o ‘percorso a briciole
di pane’ indica il posizionamento logico del file nella struttura
complessiva: non la strada che l’utente ha fisicamente seguito per
arrivarci.

Strumenti di organizzazione visuale

Comunque venga scelta, la gerarchia dev’essere rappresentata in maniera
visualmente significativa: non lasciate che gruppi di navigazione diversi
competano fra di loro. Gli strumenti visuali che avete a disposizione
sono potenti e ben codificati. In generale interventite su: dimensioni,
forme, posizionamento relativo e colori. Ma il colore dovrebbe essere
l’ultima ratio, un mero elemento di stile: il vostro layout dovrebbe
funzionare anche in grigio, solo con il posizionamento relativo e l’aspetto
delle voci e dei gruppi. Vi sono regole di organizzazione percettiva
che ogni buon grafico dovrebbe conoscere, e che non è questa
la sede per illustrare. Le più importanti comunque sono:

Vicinanza: è il primo criterio di raggruppamento figurale:
voci vicine sono percepite come un’unità. Attenzione però:
le voci non dovrebbero essere così vicine da creare difficoltà
nell’atto di cliccare! E’ bene rinunciare in parte al concetto di vicinanza,
piuttosto che creare menu con voci talmente piccole e fitte che richiedano
molta attenzione per essere correttamente selezionate. L’utenza media
non è così abile nel manovrare il mouse, e spesso neanche
l’utenza esperta…
Somiglianza: voci dall’aspetto simile sono più facilmente
percepite come un gruppo. Pertanto le voci dello stesso gruppo dovrebbero
avere un aspetto simile. Evitare se possibile voci troppo più
lunghe delle altre e disposte magari su due righe: contrastano l’effetto
di somiglianza.

Altre regole di organizzazione percettiva vi saranno certamente suggerite
da un buon grafico web.Guardate il vostro layout: la gerarchia è
chiara? Ci sono elementi che competono fra loro per rilevanza visuale?
Che creano ‘rumore di fondo’ ostacolando la leggibilità? La loro
eliminazione passa per un buon design della navigazione, a cui l’usabilità
e le regole di organizzazione figurale possono offrire un contributo
realmente decisivo.

Un esempio: Adobe.com

Un progetto di navigazione particolarmente ben riuscito è il
redesign (risalente alla scorsa estate) del sito www.adobe.com,
opera di Hillman
Curtis, un noto Flash designer che però dimostra di essere
prima di tutto un designer tout-court. Il lavoro è tanto più
significativo se consideriamo che non è stato modificato il precedente
layout (presumibilmente per non disorientare gli utenti abituali, oltre
che perché, oggettivamente, non se ne evidenziava la necessità).
La pagina si presenta così organizzata:

Notiamo come la software house dedicata alle soluzioni per la grafica
professionale abbia individuato dei sistemi logicamente e visivamente
ben distinti per il proprio sistema di navigazione.

Accanto al logo, nella barra nera che sovrasta le pagine, vi sono due
gruppi di navigazione distinti senza orpelli grafici (cornici, fondini),
ma con il solo variare dei rapporti di vicinanza fra le voci. Vi è
anche una variazione di colore, ma è ridondante: non necessaria
per la comprensione. Il primo gruppo presenta quella che potremmo chiamare
la navigazione principale, istituzionale, costituita da sole 4 voci:
store, products, support e corporate. Queste 4 voci consentono un efficace
instradamento degli utenti sulla base delle categorie concettuali di
informazione cui sono interessati.

Il secondo gruppo consiste in tre voci (due nella versione italiana,
che non presenta la traduzione di Adobe Studio, una sezione del sito
dedicata a consigli d’uso per gli utenti dei propri prodotti, una specie
di magazine con compiti di community) che non sono altro che facilities
del sito: Adobe Studio, ricerca e contatti. In un sito ampio e complesso
come quello della Adobe, la funzione di ricerca testuale è particolarmente
importante per tutti gli utenti che abbiano esigenze molto specifiche.
Da notare che, a differenza del gruppo precedente, in questo secondo
gruppo di navigazione le voci sono divise da una barra verticale ( "|"
). Un vezzo?

Tutt’altro. Si tratta di una scelta funzionale, resasi necessaria proprio
per la presenza della voce "Adobe Studio": si tratta dell’unica
etichetta verbale composta di due parole! Per raggruppare le due parole
in maniera che non sembrassero due link ma uno solo, si è scelta
la barra verticale come spaziatore, dato che la sola vicinanza poteva
in questo caso indurre delle ambiguità.

La parte centrale della pagina è dedicata alle notizie, alle
offerte, alle ultime release. Notiamo ancora all’opera il principio
di vicinanza nel rapporto fra le immagini rotonde e il testo relativo.
Non si fa uso di altri espedienti per il raggruppamento delle informazioni.
Nessuna cornice, nessun fondino colorato (a parte quello che domina
l’intera pagina, e che rafforza la coerenza visiva dell’insieme). Eppure
non vi sono difficoltà nell’attribuire ogni testo alla relativa
immagine.

Sulla destra, infine, un’ulteriore lista di voci categoriali, che rappresentano
le categorie di prodotti: per il web design, per la stampa, l’animazione,
ecc. In questo modo si presume una segmentazione degli interessi dell’utenza
all’interno del più generale interesse per la grafica. Invece
di scegliere la voce ‘prodotti’ nella barra orizzontale, si consente
a chiunque di approfondire la sezione che più gli interessa.
Inoltre viene sdoppiata la voce Adobe Store (già presente nella
navigazione principale): un chiaro segnale che si tratta di una sezione
che sta particolarmente a cuore alla Adobe.

A parte questo sdoppiamento, è da notare che le strade per raggiungere
le informazioni sono logicamente diverso nelle tre sezioni di navigazione:
secondo una rigida struttura ad albero nel primo caso, secondo una modalità
di ricerca testuale nel secondo, attraverso il tipo di prodotto nel
terzo. In più, le novità sono sempre adeguatamente segnalate
nella parte centrale della pagina.

Questo sistema è significativo per molti motivi, fra i quali
sottolineiamo i seguenti:

Economia visiva: non vi sono orpelli inutili
Completezza: tutto è catalogato e raggiungibile in qualche
modo
Ridondanza: vi sono diversi possibili modi di accedere alle stesse
informazioni

L’apparente semplicità del sito Adobe è il risultato
di un attento design della navigazione, che poggia su un’accorta profilazione
degli utenti e su una solida architettura informativa, pur essendo il
sito composto di svariate centinaia di pagine. L’utilizzo di espedienti
di raggruppamento figurale è messo al servizio di una struttura
logica, economica, efficace ed efficiente, senza trascurare uno stile
figurativo elegante e sintetico, perfettamente funzionale agli scopi
del sito.

Non è tutto oro…

Il sito della Adobe presenta tuttavia alcuni problemi minori di usabilità
(non di design) che potrebbero essere risolti per migliorare definitivamente
l’interfaccia. Vediamoli in dettaglio:

La tagline (lo slogan che accompagna il logo e che serve per definire
l’azienda) è: "Everywhere You Look" (ovunque guardi:
è un chiaro riferimento alla fornitura di strumenti per la creazione
di qualunque tipo di prodotto visuale). E’ un ottimo slogan pubblicitario,
ma non spiega di che si occupa l’azienda a chi non la conosce già.
E’ probabile che il target Adobe non risenta di questa carenza, ma si
tratta tuttavia di un aspetto che potrebbe forse essere rivisto.
Le scritte della navigazione sono costituite da immagini gif! Tale
discutibile pratica è una consuetudine deprecabile dello stesso
Hillman Curtis, che la utilizza anche per il suo sito (e la porta addirittura
allo spasimo: là tutti i testi sono immagini!…), forse perché
riesce a ottimizzare le gif in maniera da ottenere immagini meno pesanti
del corrispondente codice. Più probabilmente, il motivo è
da ricercare nel maggior controllo sulla visualizzazione. Ma su web
bisognerebbe tenere separati contenuto e visualizzazione! Se l’utilizzo
di immagini per il testo può essere considerato accettabile nel
caso di titoli che abbiano una particolare cura estetica impossibile
da riprodurre via html (e, per quanto riguarda l’antialiasing, anche
via css), non è spiegabile quando imitano proprio i testi html
come in questo caso! Infatti le voci di menu su campo nero potrebbero
essere fissate attraverso i css, garantendo maggior accessibilità
e maggior standardizzazione del codice attraverso una separazione fra
forma e contenuto. La presenza degli attributi ‘alt’ minimizza comunque
l’impatto di questo problema. Anche i testi della parte centrale della
pagina sono immagini gif, mentre non lo sono le descrizioni relativi
alle voci di menu sulla destra.
Al link per la ricerca testuale è normalmente preferibile
il box di ricerca, nel quale l’utente può direttamente iniziare
la ricerca, risparmiando un click. E’ semmai possibile linkare una voce
dedicata all’eventuale funzione di "ricerca avanzata".

Nonostante questi problemi (peraltro, insistiamo: poco o nulla rilevanti
per il target specifico del sito), il design della navigazione di Adobe
rimane un ottimo esempio di organizzazione logica e visiva di un sito
ampio e complesso attraverso sistemi eleganti e flessibili

Gli strumenti di navigazione

Gli strumenti di navigazione sono gli elementi di gran lunga più importanti in un sito, almeno quanto e per certi versi più dei contenuti stessi. Essi assolvono diverse funzioni e bisogni dell'utente, come spiega egregiamente Steve Krug nel suo "Don't make me think".
Rimandiamo a quel testo per una discussione più approfondita sul senso degli strumenti di navigazione. Per quel che conta qui, diciamo che gli scopi principali sono:

Fornire al visitatore un'idea di cosa presenta il sito
Dare un'idea di come è costruito e strutturato il sito, in modo che possa orientarcisi. "Dove trovo cosa?" è la domanda cui dovrebbero contribuire a rispondere.

Gli strumenti di navigazione dei siti web, esattamente come la segnaletica nel mondo reale, poggiano ormai su alcune convenzioni consolidate. Lentamente anche queste convenzioni evolveranno, ma per ora hanno una relativa stabilità. Vediamole in panoramica, ricordando che come tutte le schematizzazioni, anche questa non va presa alla lettera (vi sono siti che hanno esigenze molto specifiche, per i quali questi concetti vanno molto diversificati). Però è utile per iniziare a introdurre l'argomento e a fissare alcuni punti chiave.

Identità del sito

Costituita anzitutto dal logo, che nelle pagine interne è di solito anche un indispensabile link all'home page (ma attenzione: è una convenzione che non tutti gli utenti conoscono, per cui è preferibile mantenere sempre anche un link testuale 'home'). Ma l'identità è data anche dall'insieme delle scelte di design che coerentemente si ripetono nelle pagine: i colori, il layout, lo stile grafico e tipografico.
Ciò di cui è facile dimenticarsi è che l'identità del sito e il suo scopo dovrebbero essere chiaramente rappresentati anche e soprattutto dai contenuti!

Sezioni principali (o navigazione primaria)

Ovvero le categorie nelle quali è diviso il sito, e all'interno delle quali l'utente può cercare servizi e prodotti. Possono far parte di una barra di navigazione, oppure essere suddivise in directory, come nel caso di alcuni motori di ricerca o portali.

Utilità

Fanno parte di questa categoria alcune opzioni di aiuto, come 'help', tour guidati, mappe del sito o anche informazioni sul sito e su come contattarci. E' bene raggruppare assieme queste voci in un luogo determinato della pagina.

Indicatori di posizione

Il più diffuso è il percorso a briciole di pane, che contiene anche i link cliccabili delle varie pagine percorse, ma potrebbe essere anche un'indicatore grafico.

Titolo di pagina

Uno degli elementi di navigazione più trascurati. Spesso, se siamo in assenza anche di un indicatore di posizione, la mancanza del titolo della pagina è uno degli errori più comuni e disorientanti per l'utente, che non ha modo di ricostruire la sua posizione all'interno del sito.

Navigazione locale o secondaria

Si tratta di menu che appartengono alla specifica sottosezione, e che variano di sezione in sezione nel contenuto, ma preferibilmente non nella posizione.

Navigazione contestuale

Ovvero i link che vengono presentati in prossimità dell'area di contenuto della pagina: articoli correlati all'interno del sito, ma anche esterni.

Menu nel footer

Vi è ormai un'abitudine consolidata nel ripetere in fondo alla pagina (soprattutto in pagine lunghe, dove è probabile che l'utente avrà necessità di scorrerle) una serie di link testuali che richiamano solitamente la navigazione primaria.

Funzione di ricerca testuale

L'alternativa rispetto alla navigazione fra le sezioni del sito, è quella di cercare per via testuale quello che si sta cercando, interrogando con una frase o con alcune parole chiave il sito, proprio come si fa di solito con i motori di ricerca. Questa funzione è particolarmente importante in siti molto ricchi di pagine e con la struttura molto complessa, com'è ovvio. Evitare di inserire nel proprio sito aziendale funzioni di ricerca sull'intero web: se qualcuno ha bisogno cercare nel web, molto meglio lasciarlo uscire dal sito e farlo andare sul suo motore di ricerca preferito. Il risultato sarà certamente migliore della ricerca che può fare sul vostro sito, dove non sarebbe tra l'altro per nulla pertinente.

Ausilii secondari alla navigazione

Si tratta di indicatori che vengono utilizzati soprattutto dagli utenti esperti, specialmente se gli ausilii visti finora non sono sufficienti. Si tratta:

dell'URL che compare nell'apposita finestrella del browser, che indica l'indirizzo esatto della pagina (e che viene di solito mascherato dai frame e dall'uso di Flash);
del titolo di pagina che compare nella barra in alto della finestra del browser;
dell'indirizzo che compare in basso a sinistra nella finestra del browser quando si passa con il cursore sopra ad un link. Questo indirizzo consente alle volte di capire dove si arriverà e di quale tipo sarà il documento (html, pdf, gif o jpeg, ecc). Anche questo ausilio viene vanificato nei link in Flash.

Se tutti questi strumenti sono importanti per fornire all'utente gli appropriati stimoli visivi e logici affinché possa muoversi efficacemente nel sito, va anche detto che il loro uso non è sempre così ovvio come può apparire da questa elencazione. Nei prossimi articoli approfondiremo i singoli argomenti. Prima però affrontiamo alcune questioni più generali.

La navigazione primaria va ripetuta in ogni pagina?

Vi sono opinioni contrastanti. Nielsen riporta alcune osservazioni di altri analisti i quali concludono che ciò che conta in una pagina è il contenuto, non gli strumenti di navigazione. In realtà Nielsen stesso mette in guardia soltanto contro un eccesso di navigazione in ogni pagina (non ha senso linkare tutto con tutto…), ma sottolinea l'importanza di avere sempre almeno il percorso a briciole di pane, in maniera che l'utente possa risalire lungo la gerarchia del sito.

Quasi tutti gli autori concordano che la navigazione principale, oltre a consentire di cambiare rapidamente sezione principale (attività comunque non frequente per gli utenti), fornisce una chiara cornice di riferimento alla pagina, e contribuisce così a darle identità.

Pensiamo al caso in cui un utente entra nel sito da una pagina interna: fornire un po' di contesto può essere molto utile. Non c'è niente di peggio che capitare in una pagina priva di riferimenti, ed è purtroppo una prassi assai comune in molti siti che presentano molti testi, articoli che vengono aggiornati periodicamente, ma con conduzione amatoriale.
Comunque la pensiate (o meglio: comunque la pensino in vostri utenti, visto che saranno loro a giudicare la scelta), è indispensabile che in ogni pagina del sito sia presente almeno un chiaro link all'home page.
Secondo Krug la navigazione principale o persistente non è così necessaria esclusivamente in pagine che presentano soltanto form da riempire.

Labelling system

Tutti gli strumenti di navigazione sono basati su etichette testuali. E' importantissimo che i nomi scelti per ogni elemento e ogni sezione siano il più possibile significativi per l'utente finale, piuttosto che per il programmatore o per i dipendenti dell'azienda. Così come la struttura del sito non dovrebbe ricalcare l'organizzazione interna dell'azienda (che ha spesso ragioni lontane dalle esigenze di un semplice utente, che le giudicherebbe incomprensibili), così anche i nomi scelti non dovrebbero ricalcare i nomi degli uffici, a parte naturalmente nella sezione che spiega proprio com'è strutturata la vostra azienda! Orientate il sito in maniera da facilitare all'utente l'esecuzione dei compiti e delle procedure, e scegliete nomi di azioni o prodotti per lui significativi.

Architettura informativa

Il problema del labelling (e dunque quello della navigazione) è subordinato, com'è ovvio, a quello della strutturazione di fondo del sito. Sfortunatamente, a differenza dei luoghi fisici, dove un visitatore ha almeno un'idea di massima di com'è fatto un'edificio, la struttura di un sito web è sempre invisibile all'utente. L'unica indicazione può venirgli (oltre che dalla mappa del sito), proprio dagli strumenti di navigazione. E' importante perciò strutturare il sito in maniera conforme alle attese di utilizzo da parte degli utenti. Ciò è tanto più difficile, quanto più il sito rappresenta un ente con una lunga storia o una gerarchia consolidata e complessa. I siti di enti come le regioni o le camere di commercio, per esempio, sono piuttosto difficili da gerarchizzare in base all'utente, perché spesso si ragiona in termini di uffici preposti a certi servizi.
E' determinante invece sforzarsi di immaginare (e testare, naturalmente) quali siano le esigenze degli utenti, e strutturare il sito secondo le azioni che l'utente desidererà compiere, magari in maniera ridondante rispetto alla strutturazione degli uffici.

Il problema dell'architettura informativa e dell'analisi delle procedure che l'utente necessita di eseguire è uno dei problemi di base della costruzione del sito, e uno di quelli in cui l'usabilità può dare un contributo più fruttuoso.