Ricerca e design per le intranet
Transcript
Ricerca e design per le intranet
Ricerca e design con utenti: metodi e pratiche per le intranet di Alberto Mucignat Versione 1.1 Questa opera è rilasciata sotto licenza Creative Commons Versione 3.0 Attribuzione - Non commerciale - Condividi allo stesso modo http://creativecommons.org/licenses/by-nc-sa/3.0/deed.it 1 Premessa Ho scritto questo contributo a giugno 2010, per il libro Intranet 2.0 1 di Giacomo Mason2, che è uscito da pochi giorni. L’idea era di creare un compendio metodologico per i lettori del libro, che può quindi apparire semplificato ai designer più esperti. Ho cercato di illustrare come si può progettare una intranet coinvolgendo gli utenti nel design: ho presentato le principali tecniche che costituiscono lo stato dell’arte del design digitale, trascurando appositamente alcune nuove pratiche emergenti che avrebbero potuto sembrare troppo pretenziose in questo contesto e che necessitano probabilmente un dettaglio maggiore. Le esigenze di un’appendice mi hanno richiesto di non superare le 20 pagine, motivo per cui alcuni argomenti li ho spiegati sinteticamente, cercando comunque di arricchire l’esperienza di lettura con opportune note. Inoltre, a causa di alcuni fattori temporali (leggi “il mio ritardo cronico rispetto ai tempi di stampa”) non ho sicuramente avuto il tempo di rivederlo come avrei voluto. Tuttavia da qualche tempo ho accettato l’imperfezione del mondo digitale, che Weinberger diceva essere una traccia dell’umanità delle persone che stanno dietro ai prodotti digitali. Per questo ho deciso di rilasciare subito questo prodotto sotto licenza Creative Commons e di cercare di arricchirlo in futuro. Non è un impegno, ma spero di riuscirci. Magari con l’aiuto dei lettori, i quali ringrazio fin da ora per il feedback che mi vorranno dare. Alberto Mucignat Roma, 11 Novembre 2010 1 Intranet 2.0: http://www.tilibri.com/libri/intranet_2_0.html 2 Giacomo Mason è un consulente intranet di notevole qualità. Il suo blog (http://www.intranetmanagement.it) è una vera miniera di esperienza e conoscenza. 2 Intranet e persone: progettare con gli utenti C'è voluto un po' di tempo, ma da qualche anno anche i nuovi prodotti digitali hanno iniziato a essere realizzati attraverso pratiche di design centrato sugli utenti. Tali tecniche sono ben note da diverso tempo sotto il nome di User-Centered Design (UCD) 3, o HumanCentered Design, il cui processo è uno standard consolidato 4. Lo User-Centered Design è una filosofia di progettazione che prevede di tenere in considerazione i bisogni e le caratteristiche degli utenti in ogni fase del processo, per aumentare l'efficacia e l'usabilità del prodotto finale. Alcune attività tipiche dello UCD possono essere, a titolo di esempio: • • • • • interviste con utenti ricerche sul campo (o etnografiche) definizione di scenari di utilizzo e task design partecipato test di usabilità Sebbene questa impostazione venga dichiarata da molte aziende operanti nel settore, lavorare con gli utenti è un approccio piuttosto fuori dal comune, specialmente in Italia. Il più delle volte le aziende che fanno web design lavorano sulla base delle proprie convinzioni e conoscenze, interfacciandosi poco o niente con i veri utilizzatori del prodotto. Nel caso delle intranet, il coinvolgimento degli utenti è strategicamente importante per diversi motivi: • attinge da una base utenti già disponibile, diminuendo i costi e i tempi del recruiting • consente di coinvolgere sia il personale dell'azienda (dipendenti, tecnici, amministrativi) sia gli stakeholder (manager, responsabili): entrambi sono utilizzatori finali della intranet • garantisce il committment da parte di tutti, aumentando le possibilità di riuscita della intranet Esistono alcuni approcci allo User-Centered Design che seguono lo stesso standard, ma ai quali corrisponde un diverso coinvolgimento degli utenti. Non è mia intenzione dettagliare tutti questi approcci, ma ritengo importante distinguere in generale tra due livelli di coinvolgimento: • utenti come generatori di feedback • utenti come co-designer Nel primo caso, gli utenti e gli stakeholder partecipano al processo di design allo scopo di fornire feedback utile ai designer per la realizzazione del prodotto. Nel secondo caso, gli 3 http://en.wikipedia.org/wiki/User-centered_design 4 Mi riferisco allo standard ISO 13407:1999. Un riferimento ben dettagliato a proposito: http:// www.usabilitynet.org/tools/13407stds.htm 3 utenti sono visti come veri e propri co-designer, che decidono l'interfaccia al pari dei designer. Personalmente ritengo che coinvolgere gli utenti sia importante, ma trovo sbagliato fidarsi totalmente del loro parere sulle soluzioni di design, perché spesso ragionano in base a schemi e pattern che riconoscono e ai quali sono abituati: il ruolo del designer è infatti quello di ragionare fuori dagli schemi (o "super partes") e di produrre delle soluzioni che mettano assieme le esigenze dei diversi gruppi di utenti. Tuttavia è importante riconoscere come il coinvolgimento degli stakeholder, sia nel caso delle intranet sia per gli altri prodotti digitali (siti web, servizi online, community), è importante per ottenere il committment da parte degli owner di progetto. Coinvolgerli attraverso pratiche di co-design li porta a spendersi in prima persona a difendere e promuovere il prodotto intranet, con evidenti ricadute sulla riuscita del progetto. Infine, voglio sottolineare che la progettazione delle intranet ha molti punti in comune con il cosiddetto social web design5, che proietta il design classico verso la terza dimensione: la progettazione delle relazioni che si instaurano con gli altri utenti. Negli ultimi anni si è proprio passati dal paradigma "utente-computer" al nuovo paradigma "utente-computerutente"6 , le cui interazioni avvengono attraverso interfacce il cui vero valore percepito è sempre più legato alla facilità e immediatezza piuttosto che alla tecnologia. Design con gli utenti: un metodo per le intranet In generale, mi piace distinguere il lavoro di design di una intranet in due ambiti di attività differenti, ma ugualmente importanti: • ricerca con gli utenti • design dell'applicazione Il primo raccoglie tutte le pratiche che forniscono un feedback per il design, mentre il secondo è il vero e proprio lavoro di progettazione dell'interfaccia. Per le intranet, il processo di ricerca è volto a capire quali sono gli scenari d'uso, i task che i dipendenti compiono quotidianamente, le loro frustrazioni, i problemi, ecc. Il processo di design si concentra invece sulla realizzazione dell'interfaccia della intranet, per favorire e supportare al massimo le esigenze degli utenti. Esistono diverse possibilità di mettere assieme i due ambiti, che descrivo brevemente. Approccio a cascata In questo caso, la ricerca con utenti viene fatta all'inizio e successivamente si passa a una fase di design. Purtroppo questo approccio non tiene conto del fatto che spesso non si 5 A proposito di community e social web, un libro che consiglio è Designing for the social web di Joshua Porter: http://www.amazon.com/Designing-Social-Web-Joshua-Porter/dp/0321534921 6 Si veda anche Motivational Design degli italiani Giacoma e Casali: http://www.scribd.com/doc/16508655/ Motivational-Design-15-IT 4 riesce a sapere subito tutto sugli utenti. Soprattutto, il feedback tra ricerca con gli utenti e design dovrebbe essere continuo o perlomeno periodico. Approccio iterativo Chiamato spesso "Approccio agile" per analogia con il corrispondente nello sviluppo software 7 , prevede che le diverse attività vengano organizzate all'interno di cicli di lavoro di alcune settimane. A ogni iterazione o ciclo si fa ricerca e design, anche per avere la possibilità di ricevere feedback su quanto realizzato in precedenza e consentire di correggere gli errori. Approccio parallelo In questo caso8, la ricerca e il design procedono paralleli su due livelli diversi: da una parte vengono collezionate informazioni sugli utenti, i loro bisogni e i loro comportamenti, dall'altra viene prodotto il prototipo dell'interfaccia. In pratica, la ricerca e il design proseguono su due strade indipendenti e legate dai momenti di confronto, verifica del feedback, ecc. Questa soluzione richiede sicuramente più frequenza e precisione nei momenti di contatto, perché altrimenti è difficile garantire una coerenza del progetto. Inoltre, per procedere in parallelo si dovrebbero avere tempi più lunghi, per consentire sia periodi di elaborazione sia momenti di condivisione. Sebbene non sia facile scegliere quale approccio seguire, il mio consiglio per ogni progetto è di non rinchiudersi in un processo waterfall, ma di iniziare a stabilire dei cicli di lavoro ragionevolmente ampi (release) e di suddividerli in cicli di lavoro di alcune settimane (iterazioni), in cui fare ricerca e progettare solo determinate funzionalità o scenari degli utenti. Lavorare iterativamente porta dei benefici soprattutto a livello di limitazione dei rischi: la possibilità di correggere continuamente gli errori evita che il prodotto finale sia completamente diverso da quello che si aspettano gli utenti e nel contempo consente di realizzare prodotti efficaci e più usabili. Di seguito analizzo le principali attività per ognuno dei due ambiti (ricerca con utenti e design), descrivendo pratiche e consigli sulla realizzazione. Ricerca con gli utenti Anche se può sembrare costoso o poco produttivo (i manager tendono spesso a limitare la fase di ricerca: "sappiamo già di cosa abbiamo bisogno"), la ricerca con gli utenti è fondamentale per realizzare prodotti che funzionano. Per fare un esempio, ultimamente le ricerche etnografiche si sono avvicinate molto al design dei prodotti, tanto che negli ultimi anni le più importanti multinazionali stanno investendo molto in questo campo. L'obiettivo di tutte le attività di ricerca con gli utenti è quello di conoscere quanto più possibile sugli utenti, in particolare i loro obiettivi e comportamenti. Nel caso di una intranet 7 Si veda a proposito: http://it.wikipedia.org/wiki/Metodologia_agile 8 Nel tempo ho collezionato numerosi riferimenti a proposito della progettazione agile della user experience che trovate nel mio blog: http://www.mucignat.com/blog/tag/agile-ux 5 per esempio possiamo cercare di capire come viene utilizzata, quali sono le cose che gli utenti fanno più frequentemente, quali non riescono a fare, quali trovano difficili, ecc. Soprattutto, la ricerca è molto importante per capire cosa non conosciamo a proposito degli utenti: per esempio perché una grossa fetta dei nostri colleghi non usa la intranet oppure perché non usano determinate funzionalità. Le attività di ricerca con gli utenti si suddividono in due categorie principali: qualitative e quantitative. Questa suddivisione è piuttosto importante: i migliori input di design sono garantiti dal feedback qualitativo, ma spesso viene comunque chiesto di motivare la ricerca attraverso dei dati quantitativi (specialmente da parte dei manager, che vorrebbero sempre avere dei numeri a supporto). Ricerche qualitative Ricerche quantitative • Interviste e focus group • Questionari e sondaggi • Card sorting • Analisi dei diari • Analisi statistiche web • Analisi ricerche interne • Test di usabilità Altre ricerche alla intranet Come ho già detto, lo scopo di tutte le attività di ricerca è cercare di capire obiettivi e comportamenti degli utenti, a cui si aggiungono le reali motivazioni, vero motore di ogni comportamento umano. Queste tre componenti sono la base fondamentale per produrre delle scelte di design efficaci e consistenti. A differenza degli obiettivi (scaricare un documento, cercare il telefono di un collega) e dei comportamenti (fare una ricerca per parole chiave, navigare la directory del personale), le motivazioni sono meno chiare, ma molto più interessanti, perché sono quasi dei "bisogni vitali" per il lavoro: "Mi servono dei dati e delle informazioni per un report", "ho bisogno di risparmiare tempo", "cerco qualcuno che mi aiuti". Conoscere approfonditamente quali sono le motivazioni ci consente di strutturare la intranet per supportare le azioni importanti per gli utenti in termini non solo di task, ma di supporto alla loro giornata in azienda. Anche se sono stati stabiliti dei principi strategici per la intranet, ogni persona ha degli obiettivi e dei comportamenti diversi: il tecnico ha bisogno di informazioni sulle procedure, mentre l'amministrativo deve poter aggiornare le informazioni su ferie e permessi. Per questo è indispensabile che la ricerca copra il più possibile tutti i comparti aziendali, anche e soprattutto quelli che oggi non usano la intranet. Riuscire a scoprire tutte queste informazioni consente di definire una "mappa tattica" della intranet in forma di bisogni, scenari e task: in questo modo la fase di design può concentrarsi sulla progettazione della migliore interazione possibile per arrivare all'obiettivo dell'utente. Di seguito cercherò di descrivere le attività di ricerca principali per una intranet, ben sapendo di non essere esaustivo 9. 9 Per approfondire consiglio Observing the user experience di Mike Kuniavsky: http://www.amazon.com/ Observing-User-Experience-Practitioners-Research/dp/1558609237/ 6 Ricerche qualitative Le ricerche qualitative sono indicate per raccogliere informazioni non strutturate sugli obiettivi e i comportamenti degli utenti. In pratica, si cerca di raccogliere informazioni "ad ampio spettro", puntando sulla disomogeneità degli input e sulla spontaneità degli utenti. Spesso queste ricerche vengono accomunate ad altre ricerche condotte autonomamente dalle aziende. Penso alle ricerche di marketing o ai questionari di clima interno per le aziende. La differenza sta nel fatto che le ricerche qualitative si concentrano sull'aspetto comportamentale anziché su quello attitudinale. Il loro risultato serve a guidare con precisione le scelte di design, per questo deve concentrarsi sui comportamenti anziché sui desiderata degli utenti. Rispetto alle altre ricerche, quelle qualitative sono le più importanti per far emergere cosa non fa l'utente e indagarne il perché. Questo aspetto è piuttosto fondamentale, infatti mi è successo molte volte di fornire risposte a problemi sconosciuti su cui i clienti si sono arrovellati per molto tempo, semplicemente con poche interviste o con un test di usabilità. Di seguito descrivo le ricerche con gli utenti che vengono utilizzate più spesso in ambito intranet, con la premessa che esistono dei noti riferimenti bibliografici, che ho riportato nelle note. Interviste e focus group Sono gli strumenti più utilizzati per fare ricerca con gli utenti perché consentono di raccogliere informazioni qualitative a proposito delle abitudini dell'utente. L'obiettivo è raccogliere più informazioni possibile sui comportamenti, i bisogni, le informazioni importanti per gli utenti. Le interviste e i focus group hanno molto in comune: entrambe cercano di ottenere informazioni qualitative, attraverso una diversa modalità di interazione con gli utenti. Se avete poco tempo e poche risorse per la parte di ricerca, il mio consiglio è di fare qualche intervista, magari anche telefonica: basta poco per conoscere molto della vita degli utenti, ma il valore di queste informazioni è altissimo. Di solito sconsiglio i focus group per i progetti web classici, ma per le intranet faccio un'eccezione: la vita aziendale si basa sulle relazioni tra le persone, le quali riescono a tirare fuori i problemi solo quando si trovano assieme a parlarne (spesso la presenza di un collega aiuta a "rompere il giaccio" e a segnalare i problemi nascosti). Sono due le cose importanti da considerare per le interviste e i focus group: gli utenti e le domande che vengono poste. Per i primi, il consiglio è di intervistare almeno un utente per ogni comparto. Di solito vengono intervistate 10-15 persone. Per i focus group si utilizzano di solito gruppi di 5-8 persone. 7 In generale, è importante riuscire a indagare il comportamento degli utenti ad ampio raggio. Per questo consiglio diverse strategie: • cercare di intervistare utenti di tutti i comparti aziendali • intervistare i champion, ma anche gli utenti che oggi non usano la intranet (sono forse i più interessanti, soprattutto dal momento che possono farci capire perché non la usano) • bilanciare le domande per andare a coprire tutte le aree della intranet e dei possibili utilizzi Il piano di lavoro è il seguente: • • • • • • • recruiting degli utenti definizione delle domande preparazione degli incontri conduzione delle interviste o focus group sbobinamento delle registrazioni e degli appunti analisi e rilevazione dei pattern report Nel caso delle interviste, la scrittura delle domande è una specie di arte che si perfeziona nel tempo. Ci sono diverse fasi dell'intervista: domande introduttive, domande specifiche e domande personali sull'utente (spesso queste consiglio di farle per ultime, perché scorrono facilmente anche se l'utente alla fine è stanco e poco lucido). In ognuna di queste fasi le domande vanno a farsi via via più specifiche per analizzare in profondità le informazioni ricevute dagli utenti. Un consiglio è quello di partire da domande molto generiche e farsi accompagnare dall'utente nell'utilizzo quotidiano che fa del sistema, attraverso una navigazione dell'attuale intranet. In questo caso, l'utente è molto più facilitato a spiegare come usa il software, quali problemi incontra, ecc. Inoltre, riusciamo ad avere molte più informazioni sull'ordine in cui vengono svolti i task. Un'altra parte impegnativa è la conduzione delle interviste. Un consiglio generale è quello di fare una domanda e poi stare zitti il più possibile e ascoltare. La pratica dell'ascolto è una delle cose più difficili, ma è fondamentale per riuscire a raccogliere molto materiale da analizzare. Ricordate che non fate le interviste per spiegare il vostro punto di vista, ma per conoscere quante più cose possibili sulla vita dell'utente. Ultimo consiglio, se le interviste vengono condotte da più di una persona, è meglio avere due ruoli: uno è il conduttore che fa le domande e interagisce, gli altri prendono appunti per la discussione e l'analisi. Le interviste e i focus group vanno registrati per essere riascoltati e analizzati. Questo passaggio è spesso sottovalutato, perché durante le interviste si possono prendere appunti. Purtroppo prendere appunti non basta: si rischia che molte informazioni vengano perse o trascritte male durante il colloquio, con conseguenti errori di valutazione strategica. Inoltre, il conduttore non può prendere appunti, quindi c'è il rischio che il collaboratore riporti un punto di vista parziale o personale (quello che è sembrato interessante a lui durante l'intervista). Infine, la trascrizione e l'analisi delle informazioni raccolte è la parte su cui serve forse più esperienza. L'idea è di riascoltare le interviste e trascrivere tutte le frasi degne di nota, evidenziando le persone, le azioni, le informazioni e gli oggetti citati. Successivamente si 8 può fare un'analisi dei pattern che emergono, costruire delle mappe di relazioni 10 tra gli elementi evidenziati, raggruppare le informazioni per temi11, ecc. Analisi dei diari Le interviste e i focus group sono attività di ricerca limitate nel tempo, che rischiano di lasciar fuori molti bisogni o comportamenti che gli utenti non ricordano o che si presentano solo in condizioni particolari. Per questo di solito si usano le cosiddette "ricerche sul campo" o "ricerche etnografiche", nate dalle discipline dell'antropologia e della ricerca sociale. Tali tecniche prevedono di passare del tempo assieme agli utenti e di osservarli nella loro vita quotidiana. È un lavoro piuttosto intrusivo e nelle aziende è ostacolato dai diritti sindacali dei dipendenti, che sicuramente possono rifiutarsi di essere sottoposti a osservazione. Anche se possiamo trovare dei volontari illuminati e disponibili, per ovviare a questi problemi l'analisi dei diari consente di raccogliere un input di ricerca in maniera poco intrusiva, fornendo dei risultati di valore. Si tratta di scegliere alcuni utenti e di fornire loro un diario ciascuno su cui appuntare la loro esperienza quotidiana di utilizzo della intranet. In questo modo gli utenti registrano liberamente i loro comportamenti, i problemi riscontrati, le loro frustrazioni e gli eventuali successi. Il principio è proprio quello del "diario segreto": ognuno racconta la propria giornata e le proprie esperienze come se le stesse confidando a un amico. In aziende particolarmente evolute, si stanno sperimentando i blog come strumento per tenere il diario: la raccolta delle informazioni online è però diversa dall'utilizzo di un diario fisico, il quale consente un'intimità sicuramente più adatta al racconto della propria esperienza. L'analisi dei diari è simile all'analisi delle interviste e dei focus group, ma può essere accoppiata ad una serie di interviste finali per approfondire determinati argomenti che sono stati raccontati dai diari e di cui siamo ignari. L'unico inconveniente sono i tempi: sicuramente è necessario un periodo di qualche giorno (talvolta di settimane) perché gli utenti raccolgano un numero sufficientemente alto di esperienze nei diari. D'altra parte i diari rappresentano uno strumento semplice e conosciuto dagli utenti: la barriera di utilizzo è molto bassa e funziona molto bene specialmente per le persone anziane o che non sono propriamente nativi digitali. 10 Sulle concept map, vedere il bellissimo libro Communicating design di Dan Brown: http:// communicatingdesign.com/ 11 Noto come "diagramma di affinità", questo esercizio consiste nel raggruppare degli elementi in maniera che abbiano una certa relazione tra di loro. Verrà descritto più dettagliatamente nella parte sul card sorting. 9 Test di usabilità A differenza delle interviste e dei diari, i test di usabilità necessitano di un sistema funzionante o di un prototipo su cui effettuare i test. Inoltre, sono orientati all'individuazione di problemi dell'interfaccia piuttosto che a indagare obiettivi e comportamenti degli utenti. Tuttavia ritengo importante citarli, anche perché forniscono degli input qualitativi di alto valore. Per questo sono considerati lo strumento principe dello user-centered design, anche se sono ancora utilizzati poco in ambito intranet. Per quanto riguarda la tecnica per effettuare un test di usabilità, sono disponibili innumerevoli risorse online e libri autorevoli12, per cui mi limiterò a descriverli brevemente. I test di usabilità sono degli strumenti di indagine per verificare il funzionamento di un software. In pratica, si chiede a un utente di effettuare delle operazioni (task) e lo si osserva per capire quali sono i problemi che incontra. Solitamente un test di usabilità non richiede una grande strumentazione, bastano un computer per i test e un software per la registrazione delle sessioni 13. La registrazione è fondamentale per poter rivedere i test e illustrare gli highlight agli altri membri del team o al cliente. Una pratica che consiglio è quella di inserire una piccola intervista alla fine del test (molti usano un questionario) per cercare di indagare altre informazioni qualitative sugli utenti. Questo passaggio consente di perfezionare continuamente la ricerca sugli utenti, anche perché di solito i test di usabilità vengono condotti con regolarità dopo la fase iniziale, per esempio a ogni ciclo di rilascio di un software. Nel caso delle intranet i test di usabilità sono particolarmente indicati perché non richiedono costi di recruiting. Gli utenti sono infatti facilmente identificabili all'interno dell'azienda. Per favorire la partecipazione i test si potrebbero anche organizzare in aule aziendali e coinvolgere i curiosi che passano o le persone che si trovano in pausa caffè. Tale forma di recruiting consente di disintermediare e di "agganciare emotivamente" le persone (spesso i manager "chiedono" ai dipendenti di fare il test, ma questo porta ad avere utenti poco motivati). Ricerche quantitative Le ricerche quantitative sono così chiamate perché si occupano di raccogliere informazioni che siano in qualche maniera "quantitativamente rappresentative". Questa richiesta avviene molto spesso nelle aziende, specialmente da parte dei manager, che vogliono il conforto dei numeri a supporto delle loro decisioni. 12 Esistono alcuni manuali che spiegano nei dettagli come condurre test di usabilità e che ho raccolto insieme sotto questo link: http://delicious.com/stain/book+usabilitytesting 13 Tra i software disponibili ve ne sono sia di gratuiti che a pagamento. Tra questi ultimi segnalo Camtasia su Windows (http://www.techsmith.com/camtasia.asp) e Silverback su Mac OSX (http://silverbackapp.com/). 10 Nella mia esperienza, la ricerca qualitativa è la più importante per iniziare a lavorare, mentre i dati quantitativi servono sostanzialmente a confortare i timorosi. Tuttavia utilizzo quasi sempre l'analisi delle statistiche come base per la ricerca qualitativa, anche perché possono fornire ottimi suggerimenti su come impostare le domande delle interviste o su quali task basare i test di usabilità. In ogni caso, se i tempi di progetto lo consentono, unire ricerche qualitative e quantitative porta i migliori benefici sul piano della qualità del lavoro e su quello della confidenza (in pratica è più difficile che venga messo in discussione il lavoro di ricerca). Questionari e sondaggi I questionari e i sondaggi sono una forma semplice ed efficace per raccogliere un feedback quantitativo sugli obiettivi e sulle abitudini di comportamento degli utenti. Si tratta di questionari che vengono somministrati agli utenti spesso in modalità remota 14 e che consentono di raccogliere in breve tempo molte risposte da parte degli utenti. I questionari solitamente contengono domande a campo libero, ma il più delle volte assomigliano a dei veri e propri sondaggi: si usano spesso scale di valutazione (da 1 a 5) oppure risposte a scelta singola o multipla. È consigliato utilizzare questionari e sondaggi solo dopo aver fatto una parte di ricerca qualitativa, per poter avere una serie di informazioni da "validare" o di cui vogliamo stabilire la priorità. Per esempio, se conosciamo 4-5 task che gli utenti compiono ogni giorno, con un questionario possiamo chiedere qual è quello più importante. Questa informazione può guidare non solo il lavoro di design (che partirà dai task più rilevanti), ma anche far emergere i task che non sono ritenuti importanti da una larga base di utenza. In generale per i prodotti digitali è necessario raccogliere un centinaio di risposte al questionario, ma per una intranet di medie dimensioni bastano qualche decina di risposte per garantire un'accettabile validità statistica. Un problema dei questionari è che spesso i dati sono difficili da interpretare. Anzitutto c'è un lavoro di pulizia e normalizzazione, che deve portare ad avere un foglio di calcolo di dati comprensibili a chi conduce la ricerca. Poi andrebbero analizzati bene prima di essere resi pubblici, evidenziando le scoperte e correlando le risposte tra di loro. Infine non vanno mai presentati da soli, ma assieme al resto della ricerca, per limitare il rischio di errate conclusioni. Analisi delle statistiche web L'analisi delle statistiche web è uno dei passaggi più sottovalutati quando si riprogetta un sito o una intranet. Gli strumenti di analisi delle statistiche web sono ormai alla portata di tutti 15 e consentono di monitorare diverse informazioni: pagine più visitate, percorsi degli utenti, ultime pagine visitate prima di uscire, elementi cliccati nelle pagine, percorsi degli utenti, ricerche interne al sito, ecc. 14 Uno dei software più utilizzati è SurveyMonkey: http://it.surveymonkey.com/ 15 Lo strumento gratuito più noto è Google Analytics: http://www.google.com/intl/it/analytics/ 11 Nel caso delle intranet, se siamo fortunati, sono disponibili le statistiche derivate dall'analisi dei log del webserver. Queste statistiche il più delle volte non consentono molte correlazioni e non permettono di ricostruire con esattezza i percorsi degli utenti all'interno del sito. Tuttavia, oltre alle pagine più visitate, la cosa più importante in una intranet sono le parole più ricercate. La search analysis è infatti un potente strumento per lo sviluppo della intranet, di cui parlerò a breve. Anche se raramente disponibili, i dati delle statistiche web sono un ottimo strumento per individuare in maniera inequivocabile quali sono le informazioni e i documenti più richiesti all'interno della intranet, ma questi dati non devono essere fuorvianti: spesso gli utenti non vanno in alcune pagine semplicemente perché non riescono a trovarle e/o perché i menu di navigazione sono poco funzionali. A volte capita di scoprire percorsi alternativi che a noi sembrano senza senso: per gli utenti questi percorsi sono invece una soluzione accettabile per arrivare al contenuto che cercano. In questo senso, le statistiche servono spesso anche di supporto per l'inventario dei contenuti, consentendo di determinare quali sono le aree più importanti e anche facendo emergere delle aree che i responsabili si erano dimenticati di segnalare. Altre ricerche Esistono altri tipi di ricerca che vengono effettuate con gli utenti durante la fase di progettazione di una intranet. Di seguito le illustro brevemente. Card sorting Un'attività di ricerca molto utile per riorganizzare le informazioni di una intranet è il card sorting16. Il card sorting è un esercizio piuttosto semplice. Si tratta anzitutto di avere un inventario dei contenuti della intranet (nel caso l'inventario non sia disponibile, si deve avere una lista di informazioni, contenuti e funzionalità da cui partire). La lista dei contenuti dev'essere stampata in piccoli fogli o scritta in alcuni post-it: gli utenti dovranno raggruppare i contenuti che ritengono simili e dare un nome a ciascun gruppo. Questa attività richiede la presenza dei dipendenti dell'azienda. Per le aziende con sedi distaccate o per le multinazionali si possono utilizzare dei tool remoti 17 che consentono agli utenti di effettuare il card sorting dal loro pc durante un certo periodo di tempo (per esempio una settimana). I risultati del card sorting sono piuttosto difficili da analizzare, perché richiedono una complessa lavorazione per individuare le correlazioni tra le varie card e i gruppi che sono 16 Il libro più completo sull'argomento è il recentissimo Card sorting di Donna Spencer: http:// www.rosenfeldmedia.com/books/cardsorting/ 17 I più noti tool online sono Optimalsort (http://www.optimalworkshop.com/optimalsort.htm) e WebSort (http://websort.net/). 12 emersi dagli utenti 18. Tuttavia, in molti casi si possono utilizzare dei semplici fogli excel, che consentono anche ai non esperti di raggiungere dei risultati soddisfacenti 19. Search analysis Durante l'analisi delle statistiche web è possibile analizzare anche le ricerche interne alla intranet. Molte aziende non tracciano le ricerche interne, sottovalutando l'importanza derivata dall'analisi delle informazioni che se ne possono trarre. Per esempio, analizzando le ricerche interne possiamo scoprire cosa gli utenti non riescono a trovare subito all'interno della intranet. Probabilmente i documenti e i task più ricercati sono quelli più importanti per loro. Questa informazione può essere utilizzata per rafforzare con dei numeri i dati della ricerca qualitativa. Un'altra idea può essere quella di analizzare le chiavi di ricerca, normalizzarle e riorganizzarle in gruppi con un diagramma di affinità e poi armonizzare l'architettura della intranet per contenere anche questi gruppi di contenuti. L'analisi della coda lunga delle ricerche può anche far emergere i contenuti che non sono presenti nella intranet. Questa informazione può essere utile per sviluppare una strategia dei contenuti o di riorganizzazione del sito. In ogni caso, l'analisi delle ricerche interne al sito è una delle attività che dovrebbe essere pianificata all'inizio e portata avanti nel tempo, per monitorare cosa è difficile trovare, cosa manca nella intranet e scoprire come gli utenti ricercano le informazioni. Deliverable tipici della ricerca: modelli mentali e personaggi Le attività di ricerca si concludono con una fase di sintesi piuttosto delicata. A seconda delle attività di ricerca condotte, nel caso più comune ci si trova di fronte a una marea di informazioni, il più delle volte raccolte in fogli excel. A questo punto è necessario un lavoro di riorganizzazione e scelta. L'attività più comune è la ricerca dei pattern: quali bisogni e quali comportamenti emergono dalle attività di ricerca? Questi pattern costituiscono la base di segmentazione su cui vengono solitamente prodotti i personaggi 20. Un'altra attività tipica è il diagramma di affinità, che consente di raggruppare le informazioni tra di loro e 18 Una panoramica delle tecniche di analisi è contenuta nella tesi Categorizzazione online: aspetti teorici, metodologici e applicativi di Stefano Bussolon: http://www.bussolon.it/dottorato/tesi.pdf 19 Esistono due metodi noti per l'analisi dei risultati del card sorting attraverso excel. Il primo è quello sviluppato da Joe Lamantia (http://www.boxesandarrows.com/view/ analyzing_card_sort_results_with_a_spreadsheet_template) e il secondo è quello sviluppato da Donna Spencer (http://www.rosenfeldmedia.com/books/cardsorting/blog/card_sort_analysis_spreadsheet/). 20 La costruzione dei personaggi viene descritta dettagliatamente nell'ottimo libro The user is always right di Steve Mulder: http://practicalpersonas.com/book.html 13 ottenere insiemi omogenei su cui operare delle considerazioni. Questi gruppi sono utilizzati per descrivere i modelli mentali 21 degli utenti. Insomma, alla fine delle attività di ricerca vengono prodotti una serie di deliverable che hanno l'obiettivo di rappresentare motivazioni e comportamenti degli utenti in una forma facilmente comprensibile. Questi deliverable costituiscono la base informativa per la fase di design e sono la vera differenza tra il design improvvisato e il design basato sulle reali esigenze dell'utente. Ci sono diversi deliverable che possono essere utilizzati per rappresentare i risultati della ricerca con gli utenti, ma quelli più comuni sono i modelli mentali e i personaggi. I modelli mentali sono uno strumento che serve per mappare un'ampia gamma di informazioni e azioni importanti per l'utente, alle quali vengono accoppiate le funzionalità del sito che le dovranno supportare. Per esempio possiamo mappare tutte le informazioni e le azioni che gli utenti hanno raccontato e descritto durante le attività di ricerca e cercare di dare un senso a queste informazioni. Di solito i modelli mentali rappresentano nella parte superiore i bisogni degli utenti, suddivisi per aree di interesse o scenari di utilizzo, e nella parte inferiore le funzionalità e le informazioni del sistema che supportano tali bisogni22. Questo tipo di deliverable ha una valenza strategica: può essere infatti utilizzato per sviluppare una strategia a medio-lungo termine di contenuti e funzionalità, che supportano determinate "aree di bisogni" evidenziati durante la fase di ricerca. I personaggi sono invece una rappresentazione di "utenti tipo" del sistema che riportano alcuni dati demografici e caratteristici, una descrizione del personaggio, i suoi bisogni, lo scenario tipo di utilizzo e i task più comuni. Queste informazioni possono variare a seconda del personaggi, nel caso delle intranet è essenziale mappare gli obiettivi e i task. Di seguito riporto un esempio di personaggio: Il champion È famoso in tutto il reparto Ricerca e sviluppo per la sua conoscenza del prodotto e la sua capacità di raccontarlo all’interno dell’azienda. Fa spesso corsi di formazione per i commerciali e per le aziende del gruppo, spiegando per filo e per segno il valore del prodotto. Nella intranet pubblica costantemente nel suo blog dei consigli su come utilizzare al meglio il prodotto. Spesso pubblica anche dei report tecnici per i dipendenti che vogliono approfondire la loro conoscenza del prodotto. Francesco 44 anni, Pavia “La intranet mi consente di comunicare efficacemente anche con chi lavora in dipartimenti diversi dal mio e che non vedo quasi mai.” Obiettivi:! • Pubblicare pensieri e documenti nel proprio blog interno • Monitorare le conversazioni • Partecipare alle discussioni sui prodotto Task:! • Verificare se ci sono nuovi commenti • Rispondere ai messaggi • Pubblicare un nuovo post • Cercare documenti inerenti al prodotto Figura A.1. Esempio di Personaggio per una intranet (di solito si inserisce una foto reale) 21 I modelli mentali in senso stretto sono uno degli strumenti strategici più importanti del design dei servizi. Su questo vedere l'ottimo libro Mental models di Indi Young: http://www.rosenfeldmedia.com/books/mentalmodels/ 22 Un esempio di modello mentale: http://www.flickr.com/photos/rosenfeldmedia/2125040269/ 14 I personaggi sono uno strumento più tattico rispetto ai modelli mentali: vengono infatti utilizzati proprio durante la progettazione dell'interfaccia e delle funzionalità della intranet, perché descrivono dettagliatamente gli obiettivi e i task degli utenti. Progettare l'interfaccia di una intranet con questi strumenti è molto più efficace, perché il focus è sempre chiaro e ben definito. Il consiglio è di utilizzare questi deliverable come supporto sia per l'impostazione delle pagine web, sia per rispondere alle domande che nascono durante la progettazione e che spesso vedono sorgere discussioni infinite tra i membri del team di progetto. Design e prototipazione: dagli utenti alle pagine web Molte persone ritengono che non sia necessario progettare le singole pagine di una intranet, poiché spesso le intranet vengono costruite partendo da software già disponibili23. 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. Detto questo, la fase di progettazione di una intranet è una conseguenza naturale della ricerca con gli utenti. Il passaggio fondamentale è quello di riuscire a definire i personaggi, gli scenari e i task principali, in maniera da guidare la progettazione delle singole pagine. Solitamente si parte da un task e si ipotizza un percorso utente all’interno delle pagine del sito. Si passa poi a un altro task, aggiungendo le pagine che mancano e così via fino a coprire scenari e task principali degli utenti. A queste pagine si aggiungono poi le altre definite in fase di architettura dei contenuti, per esempio attraverso l’esercizio del card sorting. Le pagine realizzate in questa fase, raccolte insieme in un unico documento o linkate assieme, rappresentano quello che chiamiamo “prototipo” e che costituisce il nostro deliverable finale. Il prototipo è una rappresentazione a bassa fedeltà visuale delle pagine e delle interazioni principali della intranet e assolve a un duplice ruolo: • servire come base di discussione e comunicazione all’interno del team e con il cliente • comunicare il funzionamento dell’interfaccia a chi la deve sviluppare. Vorrei rimarcare quello che ritengo il concetto di fondo più importante per la progettazione della User Experience di una intranet, che vale anche per tutti gli altri prodotti web, mobile, ecc. L’idea alla base della prototipazione è il cercare di rappresentare a bassa fedeltà visuale le pagine del sito e le singole interazioni. Questo è forse l’obiettivo che dobbiamo cercare di raggiungere ad ogni costo, perché porta i benefici più grandi per il team, il cliente, gli stakeholder, ecc. 23 Tra questi, il più utilizzato è SharePoint di Microsoft, che però nella mia esperienza riporta diversi problemi di utilizzo nella sua “versione base”. 15 La bassa fedeltà è proprio la chiave di tutto il processo 24: durante la progettazione dobbiamo comunicare e discutere le informazioni, non l’aspetto visuale. Dal punto di vista dell’efficacia comunicativa più il prototipo è “brutto” più comunica meglio le informazioni contenute. La bassa fedeltà consente inoltre di proporre al cliente anche prototipi incompleti: il feedback è favorito dal fatto che il cliente o gli stakeholder si fanno meno problemi a discutere un progetto se hanno la percezione che non è “perfetto”. Infine, lavorare con un prototipo consente di sacrificare facilmente il lavoro: fino a che non si inizia a sviluppare a livello IT, cambiare una frase o un menù è molto semplice e richiede poco sforzo. Mano a mano che la intranet viene implementata tecnicamente, i tempi e i costi dei cambiamenti aumentano esponenzialmente. Di seguito elenco i passaggi principali per riuscire ad arrivare alla realizzazione di un prototipo, ben sapendo che per ognuno degli step sarebbe necessario un libro a parte. Ho semplificato molto la complessità del sistema, per rendere più chiaro il processo, anche perché credo che una volta compreso bene si possa facilmente estendere a progetti ben più complessi. Mappa del sito e screen flow Un primo passaggio nella progettazione dell’interfaccia di una intranet consiste nel definire le pagine che dovranno essere rappresentate dal prototipo. Talvolta è sufficiente fare una mappa gerarchica che rappresenti le pagine. Altre volte, come nel caso di applicativi verticali all’interno della intranet, è sufficiente ipotizzare diversi step all’interno di un processo e descrivere ogni pagina o interazione al suo interno. Nel primo caso si usano delle sitemap o mappe del sito per definire la struttura gerarchica delle pagine di un sito. Nel secondo caso si possono impiegare degli schemi molto simili a dei diagrammi di flusso per rappresentare il percorso dell’utente attraverso diverse pagine. Anche se la navigazione dell’utente è circolare all’interno di un sito, la mappa consente di avere una visione dall’alto delle pagine che compongono la intranet e dovranno essere realizzate durante la fase di sviluppo vera e propria. Tuttavia le mappe non riescono sempre a definire tutte le relazioni che intercorrono all’interno delle pagine, per questo ultimamente si sono iniziate a usare le concept map 25. Lo screen flow è invece una rappresentazione molto utile per le interazioni, perché consente di raccogliere in un unico documento tutti gli step di cui si compone, per esempio, un processo per la richiesta ferie o permessi. Basandoci sugli scenari degli utenti possiamo partire dalla homepage e delineare quali sono gli step che devono essere compiuti per arrivare a compiere un certo task. Durante questo ragionamento ci appuntiamo quali sono le pagine o le visualizzazioni che ci servono. Successivamente riportiamo queste pagine in un foglio e per ognuna appuntiamoci: 24 Tempo fa ho scritto un post sul tema, che spiega bene lʼimportanza della bassa fedeltà e riporta alcune risorse: http://www.mucignat.com/blog/archives/654-bassa-fedelta.html 25 http://en.wikipedia.org/wiki/Concept_map 16 • quali informazioni devono essere visualizzate • qual è l’azione principale nella pagina • quali altre azioni sono possibili. Ora siamo pronti per la fase di sketching delle pagine e delle interazioni. Sketching Lo sketching è la classica attività di disegno su carta delle pagine o delle singole interazioni di un task flow. Spesso vengono utilizzate lavagne, perché consentono di lavorare assieme su una scala più grande e di cancellare, correggere, sovrascrivere rapidamente. Seguendo il nostro processo, una volta definiti tutti gli step e le pagine all’interno di un certo task, possiamo iniziare a disegnare su carta le singole pagine, facendo anche diverse versioni della stessa pagina, per favorire la scoperta delle idee e delle possibili soluzioni26. Questo momento è forse quello più creativo ed è una delle fasi più sottovalutate da molti designer, che spesso preferiscono prendere in mano Photoshop e andare subito in digitale. Purtroppo, dal momento in cui si inizia a realizzare un prodotto digitale, i costi dei cambiamenti aumentano notevolmente (comunque meno rispetto allo sviluppo software del prodotto finito). Come ho detto in precedenza, in questa fase possiamo anche pensare ad un coinvolgimento degli utenti o degli stakeholder, ben sapendo che il loro apporto deve essere considerato, ma non deve sostituirsi al lavoro del designer. L’obiettivo finale di questa fase è di esplorare possibili soluzioni e discuterle assieme: una volta realizzato lo sketch di un certo task, è utile ripercorrerlo simulando uno scenario reale dell’utente per verificarne la validità e scoprire i limiti dell’impostazione. È questo il momento in cui spesso si modificano i percorsi, perché iniziamo a vedere in opera i vari passaggi e scopriamo alcuni problemi che all’inizio non ci eravamo posti. Wireframe Quando lo sketch delle pagine principali è terminato, arriva il momento di realizzare delle bozze digitali delle pagine. Queste bozze si chiamano wireframe e sono forse il documento più utilizzato per rappresentare la user experience di progetti web. I wireframe sono degli schemi di pagina a bassa fedeltà visuale in cui vengono dettagliate le informazioni presenti: titolo, contenuto, immagini, menù di navigazione, link, ecc. Di solito i wireframe sono essenzialmente statici, per cui il focus del loro utilizzo è sulle informazioni e sulle aree visive che devono rappresentarle. 26 Sul tema segnalo questa mia breve presentazione: http://www.slideshare.net/stain/il-tool-definitivo-delloux-designer-alberto-mucignat 17 I wireframe possono avere diversi livelli di fedeltà delle informazioni, partendo dalla semplice schematizzazione a blocchi dei contenuti della pagina, fino a un dettaglio molto preciso delle informazioni e dei contenuti dei vari blocchi. Il wireframe a blocchi, in particolare, è molto utile in fase iniziale di un progetto per definire all’interno delle pagine gli spazi dedicati alle varie informazioni: lavorando assieme agli stakeholder è facile stabilire la priorità di ciascun blocco, per poi andare a dettagliare il suo contenuto. Voglio ricordare che i wireframe devono servire essenzialmente a comunicare e discutere il progetto. Non è quindi importante utilizzare colori o sforzarsi di realizzare i wireframe in maniera impeccabile: ricordate che la bassa qualità comunica meglio le informazioni che servono in questa fase. L’adozione dei wireframe è salutare per diversi motivi e ha un valore strategico per il cliente27: • vengono creati rapidamente • sono flessibili e modificabili • sono sacrificabili Brand A livello mondiale | Italiano Home page Video Registrati | QuickList (0) | Guida | Accedi Canali Community Cerca Carica video Titolo video img Nome utente 26 ottobre 2008 (ulteriori info) Iscriviti Titolo video URL <url> Codice da incorporare <codice> Include contenuti da: Propetario contenuti Altro da: nome utente Video correlati Video 3:26 HQ Preferiti Condividi 4:17 Visualizzazioni: 56226464 Numero voti Vota Video Playlist Video Segnala 2:55 MySpace Facebook Twitter Titolo video 2 2665454 visualizzazioni Nome utente B Titolo video 3 2665454 visualizzazioni Nome utente C altro Video Statistiche e dati Video di risposta (1) Titolo video 1 2665454 visualizzazioni Nome utente A 3:26 Titolo video 4 2665454 visualizzazioni Nome utente A Accedi per pubblicare un video di risposta Video in primo piano Video 3:26 Nome utente C Commenti testuali (5200) Opzioni Nome utente (5 minuti fa) Video Accedi per pubblicare un commento Rispondi Vota <testo commento> Video Video 3:26 3:26 3:26 Titolo video 5 2665454 visualizzazioni Nome utente A Titolo video 6 2665454 visualizzazioni Nome utente A Titolo video 7 2665454 visualizzazioni Nome utente A Figura A.2. Esempio di wireframe ad alta fedeltà di informazioni per un sito di video sharing 27 Si veda a tal proposito il mio post: http://www.mucignat.com/blog/archives/1489-wireframe-rulez.html 18 Una cosa interessante è che i wireframe sono modificabili da figure che spesso non sono i designer. Correggere una label o un testo è semplice, perché i programmi utilizzati per realizzare i wireframe non sono complessi come Photoshop28. Inoltre, spesso i wireframe rappresentano un vero e proprio “contratto” per la realizzazione del progetto, perché garantiscono una chiara comunicazione a tutti i membri del team. La comunicazione visuale in questi casi vale come mille specifiche funzionali 29. Solitamente i wireframe vengono comunicati al cliente e al team di sviluppo con una presentazione che include le immagini di tutte le pagine corredate da note e dettagli. Spesso vengono rappresentati diversi stati della pagina e descritte le interazioni che possono avvenire quando si clicca su un pulsante o su un link che espande un div. Assieme alla mappa del sito e agli screen flow (che adesso possono essere rappresentati in digitale con molto più dettaglio), i wireframe sono la documentazione minima con cui gli sviluppatori possono iniziare a lavorare. Prototipi interattivi Quello che i wireframe non rappresentano sono le interazioni. Per questo, dopo aver realizzato i wireframe, spesso si realizzano dei veloci prototipi in html semplicemente linkando le immagini dei wireframe attraverso delle mappe immagini. Un’altra soluzione è di utilizzare dei software che consentono di realizzare rapidamente dei prototipi interattivi a partire dai wireframe 30. Talvolta i designer preferiscono sviluppare un prototipo attraverso dei framework in html/css, ma questo richiede molto più tempo, anche per il designer più veloce. Comunque, il vantaggio del prototipo è notevole, perché consente di rappresentare il livello di interattività che manca nelle immagini statiche. Poter cliccare e navigare le varie pagine, scoprendo i menù a tendina e provando a compilare le form è un processo che rivela la user experience in tutti i suoi aspetti. Per i clienti è un momento in cui finalmente riescono a capire quello che verrà realizzato, con conseguente aumento del loro coinvolgimento nel progetto attraverso un meccanismo di feedback: discutere e modificare in questa fase consente di limitare fortemente i cambiamenti durante la fase di sviluppo, risparmiando un bel po’ di tempo e denaro. Un altro vantaggio è di poter testare con gli utenti il prototipo. Questo aspetto è fondamentale nel processo user-centered e consente di scoprire una serie di problemi prima ancora di implementare il software. Anche per questo motivo, il vantaggio e il risparmio di tempo e denaro è notevole. 28 Tra i software più utilizzati, su Windows cʼè Visio di Microsoft, mentre su Mac OSX un ottimo strumento è Omnigraffle. 29 Si veda il mio post provocatorio: http://www.mucignat.com/blog/archives/1193-i-wireframe-sonocontratti.html 30 Il miglior compromesso in tal senso è Axure (http://www.axure.com), che funziona sia su Windows sia su Max OSX e consente di fare wireframe/prototipi, esportarli come immagini oppure come pagine web interattive. È un prodotto a pagamento, ma rimane la soluzione dʼoro per la maggior parte dei progetti. 19 Dal design allo sviluppo Dopo tutto questo lavoro, arrivati al prototipo siamo proprio alla fine: la palla passa all’IT che deve sviluppare la soluzione proposta. Arrivati a questo punto e consegnato tutto il materiale, il più delle volte i tecnici si rinchiudono in produzione e ne riescono solo alla fine. Anche quando ho avuto la sensazione di dimenticare qualcosa, la forza della documentazione visuale ha aiutato gli sviluppatori, limitando i loro tentativi di indovinare come doveva funzionare una certa parte. In alcuni casi, però, vi accorgerete che manca qualcosa. Durante il periodo di sviluppo è comunque necessario un supporto da parte dei designer per chiarire alcuni aspetti legati al prototipo o ai wireframe che non sono chiarissimi o non sono stati dettagliati opportunamente. Una funzionalità che spesso viene dimenticata è la ricerca interna. Nelle intranet, ma anche nei siti web, la ricerca interna è importantissima, poiché è quella che utilizzano la maggior parte degli utenti quando cercano un documento nella intranet o un collega. Nella mia esperienza spesso la progettazione della ricerca interna è sottovalutata, ma è invece importante progettare la pagina dei risultati con le specifiche delle informazioni che vi appaiono, delle tipologie dei documenti, di come vengono riportati i titoli, ecc. Questo compito è di solito lasciato agli sviluppatori o ai sistemisti, ma, se guardate alle vostre statistiche e vedete quando gli utenti usano la ricerca, vi renderete conto di quanto può essere strategica. Per questo il mio ultimo pensiero va alla ricerca, spesso sottovalutata proprio nelle intranet, dove la trovabilità delle informazioni è resa difficile dalla presenza di migliaia di documenti. Conclusioni Lo scopo di questa appendice è di fornire una serie di linee guida su come si può progettare una intranet partendo dagli utenti e dalle loro esigenze, cercando di realizzare software che definirei più “umano”. Per questo ho semplificato il processo, limitandolo alle cose che ritengo più importanti. Negli ultimi anni abbiamo assistito allo svilupparsi delle intranet aziendali: molte di queste sono inutilizzate dalla maggioranza dei dipendenti perché poco usabili. Inoltre, si è ormai capito che il paradigma futuro delle intranet è riuscire a realizzare delle piattaforme che abilitino le relazioni e lo scambio di informazioni tra le persone. Aggiungo che l’affermarsi di piattaforme di social networking (Facebook in primis), facili da usare per tutti, ha “alzato la barra” dell’usabilità percepita da parte degli utenti. Sempre di più le persone si rendono conto di quanto è difficile utilizzare le intranet aziendali per cose che su Facebook richiedono pochi secondi (si pensi al postare un link o un pensiero veloce). Per questo, lavorare con le persone mettendole al centro del processo di design (o redesign) di una intranet è un passaggio culturale che spero di contribuire a portare anche all'interno di molte aziende italiane. E questo è un mio piccolo contributo in tal senso. 20 Ringraziamenti Vorrei ringraziare le persone che hanno reso possibile questo mio contributo. Giacomo Mason che mi ha dato la possibilità, troppe volte rimandata, di raccogliere assieme alcune mie idee. Senza il suo pressing non mi sarei mai seduto di fronte al foglio bianco di Pages. Carla Valenti che si è letta tutto e ha corretto alcune parti del testo. Cristiano Siri e Gianfilippo Ceraselli per l’aiuto e il confronto quotidiano. Matteo Balocco per il supporto alla versione digitale/ebook. Olivia, la mia stella polare, che mi ha aiutato, incoraggiato e sopportato mentre scrivevo (e per molto altro ancora). Grazie. Alberto Mucignat è il fondatore di Doralab, azienda che si occupa di design e usabilità attraverso un approccio centrato sugli utenti. Oltre ad aver preso parte a diversi progetti intranet ha realizzato numerosi siti editoriali, servizi web e mobile. È stato uno dei fondatori delle community Studenti.it e Giovani.it durante i primi anni della new economy italiana. Scrive regolarmente a proposito di user experience design nel suo blog: http://www.mucignat.com Per contatti: [email protected] 21