Da tempo discuto con il mio intranet-guru Giacomo Mason se abbia senso o meno progettare le intranet, visto che ci sono dei software preconfezionati (che lui chiama “Sharepoint e i suoi fratelli”) che sono belli e pronti (almeno così dicono le brochure).
Molte aziende infatti si rivolgono ai designer dopo che è stato acquistato Sharepoint dicendo che adesso bisogna customizzarlo. Ma il lavoro dei designer non è customizzare Sharepoint, bensì progettare una intranet che sia efficace e facile da usare (e che venga utilizzata).
Qualche giorno fa, Giacomo ha scritto un bell’approfontimento su questo tema, da cui riporto queste frasi:
Anche la migliore piattaforma resta qualcosa di più astratto del peggior design (geniale, ndb) perché, mentre quest’ultimo si confronta comunque con i reali problemi dei dipendenti di un’organizzazione, la prima definisce uno standard buono per tutti e per nessuno, a cui bisognerà, nel migliore dei casi, “rimettere mano”.
Ciò non toglie che molte intranet si assomiglino tra di loro, ma questo avviene meno per la presenza di piattaforme che uniformano i contenuti e più per il ricorrere di problemi comuni alle aziende, che, fortunatamente, possono essere trasformati in pattern di design. (…)
Questo rende più semplice, ma non elimina il problema del design. Che eccede sempre le piattaforme per collocarsi in un territorio neutro nel quale tecnologie, pratiche, esigenze e pattern diventano progetto concreto.
Basterebbe questo a chiudere il discorso.
Purtroppo spesso il mandato per il rifacimento della intranet viene assegnato al reparto IT, il quale per prima cosa sceglie una piattaforma software. Anche se questa tendenza sta cambiando, è una forte limitazione al design delle intranet con la quale ci troviamo quotidianamente a fare i conti. Con evidenti ricadute sull’usabilità e sull’adozione della intranet da parte dei dipendenti.
Aggiungo infine quello che ho scritto nell’appendice sullo user-centered design che apparirà in fondo al libro di Giacomo sulle intranet 2.0 (in libreria da settembre, a quanto mi dice):
Molte persone ritengono che non sia necessario progettare le singole pagine di una intranet, poiché spesso le intranet vengono costruite partendo da software già disponibili. Questo è un chiaro errore: i software si basano su un concetto di “funzionalità”, che è molto diverso dal concetto di “bisogni umani”. Nella mia esperienza, l’impiego di software preconfezionati (spesso installati e configurati alla buona) è un rischio perché risultano molto difficili da essere compresi e utilizzati. Ricordiamoci che se non vengono usate dalle persone, le intranet rimangono solamente delle cattedrali abbandonate nel deserto.
E dio solo sa quante cattedrali abbiamo in Italia. E quante ancora ne stiamo costruendo.
Segui i post del blog (feed rss)
9 commenti ↓
hahah grazie albert!
dieri i figli del drag&drop …
con un ottimo framework si fanno intranet 2.0 mille volte migliori di quelle che si trovano ‘già comfezionate’ ..
calca, ma così parliamo sempre e solo di software, mentre il problema è che le intranet vanno progettate (questo perlomeno era il senso del mio post). in realtà, sharepoint pare faccia tutto, ma è proprio questo “tutto” che non ci serve: ci servono le cose giuste, ma che funzionino. ciao
si forse era compressa come frase.
la scelta di una un tool che faccia tutto non fa progettare le intranet in base alle esigenze specifiche. si utilizza quello che offre.
al contraio pensando progettando e sviluppando una intranet (utilizzando anche framework) permette di crare il sw *adatto* all’azienda.
(credo che l’informatica sia più vicino all’artigianto, in alcuni ambiti, che alla catena di montaggio)
E’ da anni che si considerano le intranet solo dal punto di vista tecnologico come strumenti di comunicazione, informazione, formazione e i risultati di partecipazione, produzione di contenuti e knowledge management scarseggiano. Credo che lo UCD sia una componente importante ma non basta. Sempre più le intranet si devono confrontare con le sfide di engagement non solo legate ad una buona progettazione dei bisogni funzionali ma di resistenze della cultura organizzativa a farsi carico dei cambiamenti che certe prassi collaborative sollevano. Spesso allora si finisce col colludere con il cliente che delega magicamente alla visione tecnologica ogni soluzione, rischiando di rivedere per l’ennesima volta cattedrali nel deserto o quasi. Se, oggi ancora, nelle aziende c’è un eccesso di conseso ad un “monoteismo tecnologista” (sia interno che a favore di certa consulenza) non è dovuto ad un mancato riconoscimento che non basta costruire un canale perché gli utenti lo usino ma perché è difficile farsi carico di certi cambiamenti in prassi, scale di valori, libertà, ecc.. Delegare alla piattaforma a volte vuol semplicemente dire non voglio cambiare e in questi frequenti casi non bastano nè le competenze tecnologiche, nè quelle di design per quanto fondamentali.
ma il design cambia i prodotti e, nel caso delle intranet, i processi. non c’è niente da fare, una parte del nostro lavoro è introdurre il cambiamento (in anzienda, nella ux, etc).
Assolutamente, spesso un buon design cambia l’interazione, le prassi, i processi e molto altro. Per quanto riguarda un prodotto interno alla cultura organizzativa come una intranet sono necessarie anche azioni e competenze di change management.
si chiaro, quando vai a toccare i processi entri nel change management. però è una cosa di cui solitamente io non mi occupo e nemmeno giacomo. tu ci hai mai lavorato (“da dentro” intendo)?
Si