Oltre l'organigramma. Appunti per l'architettura informativa delle intranet
Sto partecipando ad una gara per la riprogettazione di una grande intranet pubblica, e questa occasione mi ha dato modo di riflettere in modo più approfondito sull’architettura informativa di intranet di grandi dimensioni, in special modo legate alle pubbliche amministrazioni ma non solo.
Mi riferisco in particolare alla costruzione dell’architettura di primo livello, la quale è naturalmente solo una parte dell’architettura informativa più generale. Tuttavia, come ovvio, rappresenta una scelta fondamentale, che orienterà l’andamento di tutto lo spazio nel tempo e che richiede particolare una cura progettuale.
Spesso però in questo campo si commettono molte leggerezze, che si trasformano rapidamente in errori decisivi. I motivi di questi errori sono legati a molti fattori:
- fretta realizzativa (intanto andiamo online, poi magari modifichiamo in corso d’opera)
- presunzione organizzativa (conosco bene l’azienda, i contenuti vanno organizzati attorno ai processi di marketing)
- abitudini consolidate (noi in genere negli archivi cartacei le cose le organizziamo per codice matricola)
- sottovalutazione strategica (architettura informativa? E che cosa c’entra con il web? Piuttosto, ti hanno mandato la bozza grafica?)
- Approssimazione metodologica (ne ho parlato al bar con il Dirigente e ha detto che la mia ipotesi va bene)
- Scarsa attenzione agli utenti (non la trovano? Ma se sta proprio lì, sotto la sotto-sezione “Funzioni Operative!)
- Pulsioni megalomane (fate come volete, ma la mission aziendale deve apparire prima di tutto)
E molti, molti altri non facilmente classificabili. Il risultato di questa leggerezza progettuale è in genere un guazzabuglio in rapida crescita che provoca frustrazione, mal di testa, depressione cosmica; effetti soggettivi che si trasformano, nel migliore dei casi, nella dolorosa consapevolezza che bisognerà, prima o poi, “rimettere mano” a qualcosa che a prima vista sembrava funzionale, e che ora è diventato un mostro inavvicinabile.
Eppure l’architettura di primo livello di una intranet, per quanto complessa, non è un oggetto così enigmatico. Anzi, è possibile con facilità individuare alcune tipicità nella costruzione, ciascuna delle quali presenta una serie di vantaggi e di svantaggi.
Vorrei provare ad elencarle, identificandone le caratteristiche distintive. Come vedrete alcune sono assai ingenue, e inadatte a quasi tutte le situazioni tipiche che possono presentarsi. Ma vale la pena passarle comunque in rassegna.
Modello 1: Architettura per settori aziendali
Metafora: organigramma
Vantaggi
– Facilità nell’individuare gli owner di sezione. In alcuni casi possono coincidere con i rappresentanti del gruppo di lavoro.
– Relativa velocità nella costruzione dell’architettura. E’ sufficiente basarsi sull’organigramma aziendale già definito, proseguendo in profondità con le sotto-strutture e associandole alle sottosezioni.
Svantaggi
Sono tantissimi. Ne elenco qualcuno, ma ce ne sono sicuramente altri
– Difficile gestione delle trasversalità. Molto contenuti non appartengono in specifico a un settore aziendale, e diventa difficile collocarli in questa architettura.
– Cambiamento continuo. I settori, così come l’azienda, cambiano continuamente, e l’architettura rischia di invecchiare molto velocemente.
– Scarsa trovabilità. Molti argomenti, servizi e contenuti della intranet sono percepiti dai dipendenti in modo dissociato rispetto ai settori, e rischiano quindi di non essere trovati con facilità.
– Scarsa scalabilità. E’ molto facile che le sezioni di primo livello diventino troppe, e ingestibili
– Appiattimento contenutistico. Mettere sullo stesso piano H.R. e, poniamo, Legale, significa, in genere, non tenere conto delle esigenze degli utenti, mediamente più interessati al primo che al secondo
– Scarsa visibilità dei servizi. Tutti gli elementi di servizio e operativi, legati a precisi task degli utenti vengono mesi in secondo piano
Quando usarla
L’unica maniera sensata di usare un’architettura del genere è quando siamo in presenza di tante intranet separate, una per ogni settore e abbiamo la necessità di fornire comunque un unico punto di accesso alle diverse sezioni., In questo caso il “portale” non altro, appunto, che una porta introduttiva ad altre intranet di settore, con architetture proprie.
…………………………………………………………………………………………
Modello 2: Architettura per aree tematiche
Metafora: biblioteca
Vantaggi
– Identificazione precisa dei temi. E’ abbastanza facile identificare i diversi temi e i contenuti e raggrupparli secondo uno schema razionale.
– Content owner. Anche in questo caso è abbastanza facile identificare i content owner e i gestori delle sezioni.
Svantaggi
– Overflow. Questa architettura rischia molto rapidamente di deragliare verso un affollamento di temi che la rende a lungo andare inservibile.
– Labeling. In lacuni casi il labeling diventa difficile e richia di asssbassare l’intelegibilità dell’architettura dal lato degli utenti. In alcuni casi l’informazione diventa difficile da trovare fin dal primo clic.
– Appiattimento dei contenuti. In questa architettura i vari temi rischiano di oscurare i concreti task utenti: in alcuni casi diventa difficile evidenziare che in alcune aree sono presenti servizi interattivi o contenuti generati dagli utenti.
Quando usarla
E’ un’architettura ottima per ambienti molto legati alle informazioni e con un tasso di crescita contenuto. In ambienti con molti servizi interattivi e con un forte tasso di crescita delle informazioni rischia di trasformarsi in un boomerang.
…………………………………………………………………………………………
Modello 3: Architettura per formati
Metafora: FNAC (?)
Vantaggi
– Lerneability. E’ un’architettura con una curva di apprendimento piuttosto bassa, che facilita mediamente la vita degli utenti nell’ambiente.
– Stabilità. E’ un’architettura che resiste ai cambiamenti organizzativi.
Svantaggi
– Profondità. E’ un’architettura che rischia di essere molto profonda, a causa dei sottolivelli che spesso è necessario creare.
– Invisibilità dei settori. Al contrario della prima, è un’architettura che rende invisibili i settori aziendali e non prevede spazi specifici per loro dal primo livello. In alcuni casi questo può essere un problema.
Quando usarla
Personalmente è una delle architetture che prediligo, per il buon compromesso che offre tra scalabilità, intelleggibilità, completezza. Va molto bene per intranet ricche di contenuto, con contenuti diversificati in termini di formato, ed è in grado di ospitare le espansioni di contenuti e servizi abbastanza facilmente conservando un’eleganza di fondo. Anche se in alcuni casi è necessario associare navigazioni parallele per aspetti legati ai progetti o ai settori.
…………………………………………………………………………………………
Modello 4: Architettura per eventi
Metafora: sportelli pubblici
Vantaggi
– Architettura stretta. E’ un’architettura che non rischia di esplodere, almeno al primo livello
– Focus sull’attività. Il richiamo a una qualche attività che gli utenti possono compiere è certamente attrattivo.
Svantaggi
– Contenuti multiappartenenza. Alcuni contenuti non appartengono in specifico a evento della vita aziendale e diventa difficile collocarli in questa architettura. Servizi come un forum di help desk tecnico appartengono a “informarsi”, “lavorare”, o “collaborare”?
– Scarsa trovabilità. Molti argomenti, servizi e contenuti della intranet sono percepiti dai dipendenti in modo dissociato rispetto agli eventi e rischiano quindi di non essere trovati con facilità.
– Inserimento di formati diversi. In uno stesso contenitore possono finire contenuti molto diversi per formato (notizie, documenti, servizi interattivi, applicazioni ) e per tipo di attività richiesta (lettura, scrittura, collaborazione ecc).
Quando usarla
Certamente è un passo in avanti rispetto ad un’architettura per organigramma o per semplici aree tematiche, ma l’uso di questa architettura è un rischio qualora non sia associata ricerche sugli utenti e sulla loro “mappa mentale” rispetto informazioni aziendali. Dopo un serio lavoro di ricerca può essere una valida alternativa ai modelli precedenti.
…………………………………………………………………………………………
Modello 5: Architettura per appartenenze
Metafora: notiziario locale – Buffet
Vantaggi
– Focus sui singoli. Le informazioni sono molti più focalizzate sulle esigenze del singolo.
– Personalizzazione. E’ molto più facile costruire un proprio palinsesto.
Svantaggi
– Difficile gestione dei contenuti extraprofilo. Diventa difficile gestire contenuti e servizi che non si associano direttamente al profilo della persona.
– Rischio di overflow nella parte generale. La parte generale rischia di essere sovraccaricata di contenuti e servizi eterogenei
Quando usarla
Quasi tutte le intranet di grandi dimensioni si possono giovare di un’architettura di questo tipo, perché permette con facilità di abbinare contenuti generali e contenuti specifici o personali. Richiede una certa curva di apprendimento e l’abbinamento ad una architettura di secondo livello più “convenzionale” (poer aree tematiche o formati).
…………………………………………………………………………………………
Modello 6: Architettura per servizi
Metafora: Cassetta degli attrezzi
Vantaggi
– Distinguibilità dei servizi. Ogni servizio è facilmente distinguibili e immediatamente disponibile.
– Relativa velocità nella costruzione dell’architettura. E’ sufficiente basarsi sull’insieme di servizi disponibili
– Relativa facilità di coordinamento. Non è necessario individuare persone specifiche per la gestione delle singole sezioni, ma lavorare con il bacino esteso dei contributori
Svantaggi
– Perdita di controllo redazionale. Questo tipo di architettura lascia molto autonomia agli utenti nell’occupazione dello spazio spazio, perdendo la possibilità di fare “pushing” su determinati temi/servizi
– Dissociazione dai contenuti. Essendo legata ai servizi sezione può contenere contenuti più disparati (il blog di progetto assieme a quello dell’A.D., la modulistica assieme alle presentazioni, il forum di cazzeggio assieme a quello dell’help desk)
Quando usarla
Questo tipo di architettura è abbastanza flessibile da contenre praticametne tutto e permette con facilità l’individuazione dei servizi disponibili. E’ ottima quasi esclusivamente per intranet che si pongono come “gateway” di servizio, ovvero come piattaforme “neutre” che gli utenti possono poi utilizzare a loro piacimento in tanti modi diversi. E’ insomma un’architettura da Intranet As A Service (IaaS), nelle quali la redazione, o il gruppo di lavoro, si incarica unicamente di animare lo spazio e di fornire dei servizi, che vengono poi fatti propri da gruppi di utilizzatori.
…………………………………………………………………………………………
Modello 7: Architettura per task
Metafora: Consolle di comando – Stanze di casa
Vantaggi
– Eleganza. Questo tipo di architettura ha il pregio dell’eleganza e di una certa armonia di fondo.
– Brevità. In genere questo tipo di architettura di primo livello tende ad essere breve, con pochi task ben identificati, a vantaggio della facilità d’uso.
– Focus sulle azioni delle persone. Per definizione questa architettura è ben focalizzata sulle azioni che gli utenti possono compiere, evitando ambiguità e orientando l’ambiente ferso uno scenario attivo e partecipativo.
Svantaggi
– Poco “profumo dell’informazione“. Questa architettura, ottima per semplici task utente, perde valore man mano che i contenuti crescono,PErdendo “profumo informativo”.
– Contenuti “intrattabili”. Con questo tipo di metafora alcuni contenuti saranno difficili da trattare, non riuscendo ad esprimerli con un verbo adeguato
– Mescolamento. Alcuni contenuti rischiano di finire tutti in un unico contenitore, che a poco a poco si snatura.
Quando usarla
Come tutte le architetture tipiche dei servizi “2.0”, questo tipo di impostazione riflette fortemente una logica di “azione” che l’utente deve compiere su di una applicazione. Pertanto è controindicata in intranet di grandi dimensioni, che offrono una molteplicità di servizi e altrettante “situazioni” nelle quali è necessario presentare informazioni. E’ un ottimo tipo di architettura per singole applicazioni, per intranet piccole e molto centrate su task specifici o per sotto-sezioni specifiche, ma rischia di non riuscire a cogliere tutti gli effettivi “task utente” per intranet di grandi dimensioni.
…………………………………………………………………………………………
Osservazioni conclusive
Scordatevi la purezza. La maggior parte delle architetture concrete che si incontrano nella realtà non possono, né devono essere costruite secondo un modello P”uro”, scelto tra i 7 che ho elencato. Piuttosto, quello che funziona veramente è un sapiente dosaggio che ad un’architettura prevalente è capace di aggiungere elementi presi da altre architetture capaci di integrarsi con gli usi prevalenti e le mappe mentali degli utilizzatori. A volte è necessario inserire in un’architettura per Aree tematiche la funzione “H.R., altre volte è opportuno inserire la voce “Blog” in un’architettura per appartenenze. non sarà elegante, ma funziona.
Associate più architetture. Nelle intranet di grandi dimensioni è sempre una buona regola associare più architetture, in modo da offrire una visione alternativa dello stesso tipo di informazioni. In alcuni casi possono essere due architetture parallele, in altri delle architetture secondarie che si aprono sotto l’architettura principale. Quasi mail, nel caso di grandi progetti, un’unica metafora è in grado di cogliere tutti i contenuti. Nella maggior parte dei casi le architetture si alternano a seconda del livello di profondità. Per esempio:
– in superficie architetture per formati o appartenenze
– in profondità architetture per task o aree tematiche
Sono solo degli esempi: in realtà le cose vanno valutate caso per caso.
Ascoltate gli utenti. Nessuna architettura può funzionare senza un ascolto costante e attento degli utenti, ovvero dei colleghi. Se avete dei dubbi potete stare certi che loro ve li toglieranno. Usate gli strumenti a disposizione (card sorting, interviete ecc) e fatene tesoro prima di costruire l’architettura.