Sharepoint, i suoi fratelli e il problema del design

Prendo spunto da un articolo recente di Jakob Nielsen che affronta il tema del design delle intranet e di come esso si combina con la scelta delle piattaforme, ed in particolare di Sharepoint (la quale, ricordiamolo,  occupa oggi solo il 20% del mercato, con una posizione tuttavia dominante rispetto al frastagliato panorama di alternative che crescono come funghi nel tumultuoso territorio delle applicazioni enterprise).

La tesi di Nielsen è condivisibile sia nelle sue premesse sia nella sua conclusione (anche se debole nelle sue argomentazioni): dato che le intranet sia basano principalmente su alcuni precisi task dei dipendenti,  la presenza di piattaforme precostituite non ci esime dall’attività di progettazione e di design. E se esaminiamo alcune intranet costruite a partire da Sharepoint ci accorgiamo immediatamente delle differenze, in barba alle funzionalità native che può presentare l’applicazione.

In realtà le obiezioni di Nielsen all’idea (così come alla perversa aspirazione) che una piattaforma come Sharepoint possa ridurre tutti gli ambienti a cloni di se stessi sono fin troppo lievi: per Nielsen a parità di piattaforma varieranno in modo consistente sia l’architettura informativa (o meglio le label) sia i contenuti in evidenza in home page. Ma questa obiezione non tocca il cuore del problema, perché è scontato che questi elementi saranno diversi da azienda ad azienda e non è su lor che va misurata l’eterogeneità radicale dei due elementi di design da una parte e piattaforma dall’altra.

Il fatto è che le aziende, come ho sottolineato più volte, non operano in un “vuoto di tecnologie” che la intranet dovrebbe occupare. E non operano neanche in un “vuoto di pratiche”, che la intranet sarebbe chiamata ad abilitare. Al contrario, le aziende sono già piene di tecnologie stratificate: email, dischi di rete, client della più diversa natura, bizzarre applicazioni, siti web abusivi, database estemporanei che diventano, anche in mancanza di alternative, elementi strutturali dei processi. A questo caleidoscopico orizzonte dobbiamo aggiungere le pratiche quotidiane delle persone, stratificate in abitudini, comportamenti, processi di fatto e così via.

Progettare una intranet significa guardare in faccia questa situazione, per così dire, spigolosa e disegnare – all’apparenza in astratto, ma in fine dei conti in modo molto più concreto di quanto le piattaforme possano offrire in modo nativo – un’applicazione che ne sia la sintesi. In tutto questo le piattaforme entrano fino a un certo punto e a dire il vero le migliori intranet dissimulano la loro origine, ovvero le piattaforme, perché sono sempre un oggetto ibrido che deve mettere insieme cose assai diverse tra di loro.

Il processo di design riguarda l’architettura informativa, certo, e lo schema delle pagine, ovviamente, ma anche la collocazione dell’ambiente in un ecosistema più ampio, nel quale la piattaforma si colloca come attore al pari degli altri. In alcuni casi certe funzionalità della piattaforma andranno completamente riscritte, in altri casi sarà affiancata da altre applicazioni che si integreranno ad essa. A volte metà della home sarà occupata dal motore di ricerca, in altri casi la presenza di CRM, wiki o sistemi di e-learning dovrà rubare posto ad altri elementi. Per non parlare delle pagine interne o di applicazioni verticali come il cercapersone. In questo Sharepoint o i suoi fratelli non ci possono aiutare e lo dimostrano le tante aziende che si sono portati a casa queste tecnologie per poi ritrovarsi ai dire ” e mo” che facciamo?”.

Anche la migliore piattaforma, in definitiva, resta qualcosa di più astratto del peggior design 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, ovviamente, 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. oggi i menù di navigazione principali tendono ad essere collocati in alto e il design tende ad essere a due colonne; sappiamo dove mettere il motore di ricerca e come, grossomodo, deve essere fatta la scheda di un dipendente.

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.

P.S. Scusate lo stile fortemente ipotattico, ma mi sono accorto di essere ancora in modalità libro. Tornerò in modalità blogger dopo un sano periodo di disintossicazione 🙂