Web Design  »  Articoli  »  Architettura dell'informazione 

Pensare all'architettura delle informazioni e disegnare il modello dati del sistema non basta. Che si tratti di un programma progettato per funzionare in rete locale, di un'applicazione web o di un sito, occorre definire anche i criteri di navigazione tra le informazioni gestite.

Troppo spesso si vedono applicazioni gestire migliaia di informazioni che poi si possono consultare solo a fatica e con percorsi rigidamente codificati a priori. Per esempio:

Necessità di specifiche

Alla fase di disegno del modello dati, deve seguire la descrizione di come l'utente potrà navigare tra le informazioni. In particolare occorre:

• descrivere le regole generali. Ad esempio, le tendine di selezione devono consentire l'apertura delle schede corrispondenti ad ogni voce?

• descrivere i percorsi agevolati più importanti. Ad esempio, la visualizzazione del numero telefonico del riferimento principale del cliente;

• descrivere i punti principali dai quali occorre poter arrivare ai dati;

• descrivere i collegamenti obbligatori;

• descrivere i simboli rappresentativi dei dati più importanti;

• principali report da estrarre;

• principali filtri già disponibili con l'avvio dell'applicazione.

Chi progetta l'interfaccia, infatti, deve conoscere i criteri di navigazione necessari all'utente e questi sono spesso ovvi nel momento in cui si defiscono i dati. Allo stesso modo, i simboli che rappresentano gli oggetti più importanti o i dati elementari (es: il numero di telefono) devono essere scelti da chi usa l'applicazione e non fissati dal progettista.

Per la rappresentazione dei criteri di navigazione tra i dati vi sono vari simbolismi. Tra questi:

• la notazione OO (Object Oriented) di Yourdon/Coad;

• le mappe mentali o, nei casi più complessi, quelle cognitive;

• i CFD (Control Flow Diagram);

• un albero strutturale delle parti attive della HIC (Human Interface Component).

Alcuni problemi di navigabilità

Tra i problemi che spesso si riscontrano nelle applicazioni, sia web sia client/server, si notano:

• spesso si può passare da un livello al successivo del menu, senza poter tornare indietro di uno;

• sulle tendine, in mancanza di una voce non è possibile inserire al volo un elemento, anche dove avrebbe senso;

• non è possibile aprire le schede di dettaglio delle descrizioni di decodifica;

• non è possibile usare alcuni campi nei filtri;

• i pulsanti hanno icone che non si accordano con l'oggetto richiamato, secondo gli utenti;

• i menu non sono raggiungibili in alcune fase o sono parziali.

In generale, le interfacce applicative sembrano non tenere conto delle reali necessità di navigazione che l'utente ha nel corso del proprio lavoro. Si considera l'estetica, il rigore formale degli alberi funzionali, i dettami tecnici e si dimentica che l'utente non ha necessità di capire perchè una certa cosa non si può fare o come lo si debba fare, ma semplicemente che sia possibile farla.

Non a caso, sempre più di frequente nei team di progettazione delle interfacce sono presenti psicologi e sociologi come garanti che i processi mentali degli utenti non siano violentati da applicazioni che tendono a modificare iter collaudati, solo perchè progettisti troppo tecnici che ignorano la base del modo operativo, realizzano sistemi che piacciono a loro, prima che agli utilizzatori. Non chiederti, insomma, se l'interfaccia che stai progettando è bella. Chiediti se piacerà e non per la sua estetica, ma per le possibilità di navigazione che consente tra i dati. Non pensare a ciò che è giusto, ma a ciò che secondo l'utente è giusto, anche se per te non lo è. L'applicazione non la progetti per te!

Altri articoli

Altre guide

Altre newsletter