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://cre​ativecommo​ns.org/lic​enses/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