Di seguito gli interventi pubblicati in questa sezione, in ordine cronologico.
 
 

Cosa sono i diagrammi di affinità
I diagrammi di affinità - affinity diagram in inglese - sono una tecnica di analisi che aiuta nella categorizzazione dei dati e nell’individuare relazioni fra essi. Nel nostro caso, i dati da analizzare sono quelli acquisiti durante le ricerche qualitative o reperiti nell’analisi delle ricerche demoscopiche finalizzati allo sviluppo dei personaggi (vedi IV lezione del Corso UCD).

Introduzione
Prima di svolgere l’analisi dei dati con i diagrammi di affinità, occorre che siano state definite le modalità di segmentazione e che siano state individuate le categorie sotto le quali raccogliere i microdati. Tipicamente la segmentazione può essere effettuata per obiettivi o per modalità d’uso o per comportamenti (vedi V lezione del Corso UCD). Per esempio, se la segmentazione avviene per modalità d’uso, le categorie che ne derivano possono essere “registrati” e “non registrati”.

Attività preliminari
Coinvolgere il team
Anche se a volte è possibile fare questa attività da soli, la cosa più opportuna è coinvolgere sempre le persone direttamente collegate al progetto. In questo modo, tutti potranno sentirsi “padri” o “madri” dei personaggi e quindi più propensi al loro utilizzo nelle fasi successive. A queste persone il facilitatore dovrà spiegare chiaramente le finalità dei diagrammi di affinità e, se necessario, dovrà effettuare una dimostrazione pratica prima di svolgere la sessione di analisi.

Preparare i materiali
Devono essere disponibili:
- un cartello con le regole di base (vedi box);
- post-it di colore diverso, abbastanza grandi da poter contenere
- annotazioni esaustive (da 76x76 mm o più grandi);
- pennarelli neri a punta fine/media (il tratto della penna è meno leggibile);
- evidenziatori, per marcare i microdati estratti;
- uno o più fogli di carta bianca 70x100 cm da appendere alle pareti
- o alla lavagna (sarà più facile portarli con sé in caso sia necessario
- cambiare stanza) e altri fogli della stessa misura per bloccare i post-it
- in caso di trasporto o coprirli alla fine della giornata;
- scotch riposizionabile per fissare i post-it “ribelli”;
- fogli bianchi o blocchi per appunti.

Inoltre, il facilitatore deve avere una macchina fotografica per documentare ogni fase dell’attività e il risultato finale.

Le regole di base: - Nessuno è leader e tutti sono uguali - Tutte le idee sono importanti e non sono criticabili - Le categorie proposte sono modificabili - Le categorie con molti dati possono essere divise - I microdati possono essere duplicati e, se necessario, inseriti in gruppi - multipli - I microdati e i gruppi di microdati non sono fissi e, se necessario, - possono essere spostati Regole di base in PDF (25,6Kb)

Scegliere il luogo
Una sala riunioni o una normale stanza di lavoro con un tavolo grande. L’importante è che sia in grado di ospitare e far muovere agevolmente i partecipanti.

I diagrammi di affinità passo passo
Passo 1 - Prima di iniziare
Ricapitolare brevemente le attività di ricerca e analisi già svolte e ribadire le finalità della sessione di lavoro. Appendere alla parete o alla lavagna il cartello con le regole di base e descriverle brevemente. Attaccare sui fogli 70x100 - precedentemente appesi - i post-it con i nomi delle categorie di segmentazione. Distribuire le copie dei report con i risultati delle ricerche opportunamente codificate (per esempio: R01, R02, ecc). Fornire un congruo numero di post-it di diversi colori e indicare le convenzioni per il loro uso (per esempio: i gialli per dati, i rosa per le citazioni, ecc.). Fissare un tempo massimo per tutte le fasi della sessione.

Passo 2 - Estrazione dei microdati e categorizzazione
Ogni partecipante dovrà evidenziare sul report il microdato che ritiene significativo, scriverlo sul post-it di colore adeguato insieme al codice della ricerca di provenienza e al numero di pagina (Figura 1). Il partecipante dovrà quindi collocare il post-it vicino a una delle categorie. Questo tipo di lavoro deve essere svolto senza commenti.

Figura 1 - Esempio di microdati estratti da una ricerca ISTAT



Passo 3 - Verifica delle categorizzazioni
Al termine dell’estrazione e della categorizzazione si procederà con una verifica delle scelte fatte, dando completa libertà di modifica. In particolare si possono creare categorie non definite in precedenza oppure spostare i microdati da una categoria all’altra o, ancora, duplicare un microdato per associarlo a un’altra categoria. In questa fase si dovranno anche etichettare le informazioni della stessa natura per ogni categoria (per esempio: tipo e luogo di connessione, esperienza su internet, ecc.). Tutto questo deve essere fatto commentando e discutendo le scelte ad alta voce, con lo scopo di coinvolgere tutti i partecipanti nel processo di verifica.

Passo 4 - Nominare i gruppi
Una volta che i microdati sotto ogni categoria sono stabili, condivisi ed etichettati, si procede dando un nome e un ruolo alla categoria. Per esempio, la categoria “Registrati” potrà diventare “Giuseppe, il cliente assiduo” (Figura 2). Questo passaggio è importante poiché permette di cominciare a tratteggiare i personaggi in base ai dati reali e, quindi, a renderli più credibili. Inoltre, la scelta del nome rende tutti partecipi della “nascita” dei personaggi e crea l’empatia necessaria per il loro utilizzo in campo progettuale.

Figura 2 - Esempio di categoria con gruppi e microdati



Passo 5 - Narrare le storie
A questo punto ogni partecipante (o gruppo di partecipanti) sceglie un nominativo e prova a costruire una storia che descriva una o più esperienze d’uso. La fonte delle storie sono le informazioni contenute nelle ricerche analizzate. Il risultato da ottenere sono storie di nuove esperienze d’uso, che vadano incontro alle esigenze e agli obiettivi dei personaggi e, di conseguenza, a quelli delle persone che i personaggi rappresentano. Le storie devono essere registrate e trascritte per la fase succesiva, quella dello sviluppo vero e proprio dei personaggi e degli scenari.

Bibliografia
Understanding your User
Catherine Courage e Kathy Baxter - 2005, Morgan Kaufmann

The Persona Lifecycle
Tamara Adlin e John Pruitt - 2005, Morgan Kaufmann

Storytelling for user experience
Whitney Quesenbery e Kevin Brooks - 2010, Rosenfeld

Che i personaggi siano uno strumento molto efficace per comunicare le esigenze delle persone reali ai membri di un team di sviluppo e che agevolino la progettazione di prodotti usabili è ormai un dato di fatto, come dimostra la ricerca “Research Paper - Real or Imaginary: The effectiveness of using personas in product design“, segnalata anche da Alberto Mucignat sul suo blog.

Ma i personaggi, abbinati alla tecnica dello storytelling, sono anche un potente strumento di persuasione, utile, spesso indispensabile, quando si devono presentare nuove idee progettuali ai vertici aziendali (presidenti, amministatori delegati, ecc.), che non hanno tempo per le presentazioni lunghe e dattagliate. Inoltre, con una storia ben congegnata si può dare un senso a fatti, anche distanti fra loro, che, presi uno per uno, non ne hanno affatto e quindi aiutarci a mettere ordine nell’eterogenea mole dei dati raccolti durante le attività di ricerca.

Lo storytelling è una ben nota e studiata tecnica comunicativa, che viene utilizzata nella propaganda politica e nel marketing (a chi interessa l’argomento, consiglio Storytelling, La fabbrica delle storie di Salomon Christian, Fazi, 2008).

Senza scendere nei dettagli, riassumiamo sinteticamente i passaggi principali da seguire per preparare una storia efficace, che ben rappresenti le qualità dell’esperienza che avranno le persone con il prodotto che si sta progettando.

Passo 1
Selezionare l’idea o il concetto che si vuole comunicare e far accogliere.

Passo 2
Dai dati raccolti durante le attività di ricerca, che hanno portato allo sviluppo dei personaggi, prendere le situazioni reali più pertinenti. Con queste imbastire la trama della storia, che avrà il personaggio primario e il prodotto come protagonisti. Rifinirla e renderla “digeribile”, semplificandola.

Passo 3
Raccontare la storia in modo coinvolgente ed essere pronti a fornire dettagli.

Occorre precisare che queste storie non vanno confuse con gli scenari, che sono più dettagliati e descrivono in profondità l’interazione personaggio/prodotto.

Per chi fosse interessato ad approfondire, segnalo un blog, Storytelling for User Experience Design, collegato a un libro di prossima pubblicazione da parte della Rosenfeld Media, autori Kevin Brooks & Whitney Quesenbery.

L’argomento del titolo, ovvero come sposare lo sviluppo Agile e lo User-Centered Design, è stato ultimamente al centro dei miei interessi. Dopo aver letto innumerevoli articoli su blog e riviste, ho frequentato, per approfondire, il corso di specializzazione Agile Development and Usability del Nielsen Norman Group ad Amsterdam, letto il loro report sull’argomento e ascoltato l’intervento di Alberto Mucignat al RomeCamp. Quelle che seguono sono le conclusioni a cui sono arrivato, alla luce anche delle mie esperienze, che in genere sono con progetti della durata massima di due o tre mesi e solo in ambito web.

Per chi non sappia nulla dello sviluppo Agile, mi limiterò a una descrizione sintetica degli elementi più importanti. Agile è un processo di sviluppo che sostituisce il classico waterfall lifecycle nella produzione del software. In estrema sintesi Agile spezzetta in più cicli quello che di solito viene fatto in un unico ciclo. Quindi le fasi di Analisi, Progettazione, Programmazione e QA Testing e Rilascio vengono svolte solo per un piccolo gruppo di funzionalità e ripetute per i cicli che seguono, su altri piccoli gruppi di funzionalità. Ognuna di queste fasi, quasi sempre di carattere incrementale, è, nella terminologia Agile (metodo SCRUM), chiamato sprint.

Lo sviluppo Agile è nato nell’ambito della produzione del software e questo, a mio parere, lo rende suscettibile di adattamenti per essere proficuamente utilizzato in ambito web. Inoltre, dei principi alla base dell’Agile Manifesto pubblicato nel 2001, metto in evidenza quello che ritengo il più importante, sostituendo software con user experience: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable experience“. Questo, aggiungo io, con lo scopo di permettere al committente di raggiungere i suoi obiettivi, informativi o commerciali che siano.

Veniamo alla mia visione su come sposare lo sviluppo Agile e lo UCD. Lo farò dividendo il processo in fasi, analizzando quelle essenziali.

Fase A - Ricerca e analisi
La fase di Ricerca e analisi è fondamentale per la buona riuscita di un progetto web. Oltre a definire gli obiettivi aziendali e gli scopi del sito web, si pianificano le attività di ricerca per acquisire informazioni sui suoi fruitori, potenziali o reali che siano. A tal fine si effettuano interviste all’interno dell’azienda, si analizza la concorrenza, si esamina il sito web già on line (analisi dei log) e si effettuano attività di ricerca etnografica (di qualunque tipo, dalle interviste informali nelle fiere ai test di usabilità sul campo). Al termine di queste attività il committente deve tassativamente approvare un documento dove sono riportati gli obiettivi del progetto.

Fase B - Sprint 0: sviluppo dei personaggi, degli scenari e delle stories
Servendoci dei risultati delle ricerche possiamo, nello sprint 0, definire i personaggi e gli scenari che ci porteranno a individuare le principali stories (altro termine dello sviluppo Agile). Una delle criticità dello sviluppo Agile è la gestione della priorità delle stories. Con l’uso dei personaggi e degli scenari questo aspetto è affrontato a monte con la segmentazione e quindi le stories più significative riguardano i personaggi primari. Durante lo sprint 0 il team di programmazione, o almeno un suo rappresentante, deve essere coinvolto nello sviluppo dei personaggi e degli scenari. Il committente, se coinvolto, parteciperà al loro sviluppo e, se non coinvolto, dovrà condividere la loro scelta. Sempre in questo sprint si avvieranno le procedure per il reperimento dei partecipanti al card sorting e/o alla prototipazione partecipata e/o ai test di usabilità, in modo da poterli convocare con un breve preavviso. Anche in questo caso i personaggi torneranno utili per la preparazione dello screener.

Fase C - Sprint 1: architettura informativa, task, wireframe e interfaccia grafica
A mio parere, le stories più importanti dello sprint 1 sono quelle che portano allo sviluppo dell’architettura informativa generale, a individuare i task principali, alla progettazione dei wireframe generali e al progetto grafico dell’interfaccia. Gli strumenti UCD a supporto di queste attività sono il card sorting, la prototipazione partecipata e il cognitive walkthrough con i personaggi. L’eventuale coinvolgimento di persone nella progettazione tornerà utile alla raccolta di informazioni per rifinire e perfezionare i personaggi e gli scenari. In questo sprint il team di programmazione procederà alla raccolta di informazioni sullo stato dell’arte delle tecnologie in uso nel dominio specifico (analisi dei siti concorrenti) e alla definizione di specifiche tecniche compatibili con le caratteristiche dei personaggi. Chiaramente il committente sarà partecipe delle decisioni prese e dovrà condividerle.

Fase D - Dallo sprint 2 allo sprint (N): produzione
Nella fase di produzione vengono individuate stories che, di volta in volta, portano allo sviluppo di determinate sezioni del sito web oppure a determinati task dell’applicativo web (una procedura di registrazione, per esempio). Per essere subito produttivi, conviene arrivare allo sprint 2 con almeno 1 o 2 stories già progettate, in modo da procedere subito alla fase di programmazione. Parallelamente altre stories saranno progettate per essere pronte nello sprint successivo. Una certa asincronicità, quindi, è essenziale per procedere spediti. Le attività UCD per la verifica delle scelte fatte, sono i test di usabilità (tradizionali o RITE, Rapid Iterative Testing and Evaluation) con prototipi più o meno evoluti e il cognitive walkthrough con i personaggi. Al rilascio di una sezione del sito web o di una o più funzionalità dell’applicativo web, il committente valuterà e fornirà il proprio feedback. Per questa ragione si dovranno prevedere alcuni sprint per gli eventuali aggiustamenti.

Fase E - Sprint (N)+1: pubblicazione
Le attività di questo sprint sono essenzialmente di revisione e controllo. Un’attenta correzione dei testi, il controllo dei messaggi di errore e un debug finale, garantiscono al prodotto una maggiore qualità. Il sito web potrà essere pubblicato completo oppure, se il committente lo richiede, si procederà con la pubblicazione di una parte significativa, rimandando a sprint successivi il suo completamento.

Fase F - Sprint di ottimizzazione e modifica
Se il progetto lo prevede si potranno identificare degli sprint in cui inserire le attività di ricerca più idonee per valutare l’efficacia, l’efficenza e la soddisfazione d’uso. Quelle più comuni in questa fase sono l’analisi dei log, i questionari e le interviste. Chiaramente, a ogni sprint di ricerca sarà abbinato uno sprint per l’implementazione delle modifiche.

Conclusioni
Appare chiaro, da quanto ho scritto, che per me lo sviluppo Agile modellato intorno allo User-Centered Design è un processo ben strutturato, che deve essere guidato con mano ferma per rispettare tempi e costi. Solo in questo modo il matrimonio risulterà duraturo e felice.

Nota finale
Al temine del suo intervento al RomeCamp, Alberto Mucignat mi diceva che lo sviluppo Agile ti permette di rispondere velocemente a cambiamenti di rotta, anche significativi, da parte del committente. Su questo sono d’accordo, ma voglio sottolineare, che in questo caso, la stessa agilità è richiesta a lui nell’adeguare il budget e far si che il progetto mantenga i giusti margini di profitto.

Cos’è il Cognitive Walkthrough e come si effettua
Il cognitive walkthrough è un metodo ispettivo per la valutazione dell’usabilità, che consiste nell’analizzare i passaggi richiesti per lo svolgimento di un compito (per esempio, una procedura di acquisto), con lo scopo di individuare nell’interfaccia gli eventuali ostacoli che impediscano o rallentino il completamento del compito stesso.

Concretamente, lo si fa guidando il personaggio in una “camminata” attraverso il compito che deve svolgere, utilizzando un prototipo a bassa fedeltà o la reale pagina web.

Il cognitive walkthrough è relativamente semplice da applicare e lo si fa con queste modalità:

Fase 0 - Viene individuato il compito da analizzare e si descrivono tutte le azioni che sono in esso comprese per il suo completamento. Quindi per ogni azione nel compito:

Fase 1 - Il personaggio esplora la pagina web (o un suo prototipo) alla ricerca delle azioni che gli possano permettere di effettuare il compito selezionato.

Fase 2 - Il personaggio seleziona l’azione che gli sembra appropriata al fine di eseguire il compito.

Fase 3 - Il personaggio interpreta la risposta del sistema e valuta se sono stati fatti dei progressi per il completamento del compito.

Sempre per ogni azione del compito alla Fase 0, il valutatore dovrà a rispondere alle domande che seguono, esplorando la pagina web attraverso gli occhi del personaggio.

Domanda 1 - In relazione alla Fase 1
L’azione corretta è sufficientemente evidente al personaggio?

Domanda 2 - In relazione alla Fase 2
Il personaggio è in grado di riconoscere l’azione in base alla sua descrizione?

Domanda 3 - In relazione alla Fase 3
Il personaggio può capire se ha fatto la scelta giusta in base alla risposta del sistema?

Ogni risposta NO a queste domande indica, quasi sempre, un problema con l’interfaccia ed in questo caso è necessario indicare la severità del problema. Quella che segue è la scala da utilizzare a questo scopo:
4 = Alto - Problema di usabilità grave: causa una grande frustrazione e impedisce il completamento del compito.
3 = Medio - Problema di usabilità maggiore: può rallentare il compito, ma non ne impedisce il completamento.
2 = Basso - Problema di usabilità minore: può causare dubbi, ma non crea problemi nel completamento del compito.
1 = Miglioramento - Suggerimento per un possibile miglioramento.
0 = Altro - Con questo indicatore saranno segnalati i problemi che non dipendono dall’interfaccia, ma che possono creare dubbi nel corso del completamento del compito.

Perché farlo con i personaggi
Perché è più efficace, in quanto lo specialista che lo effettua si cala nei panni del personaggio. In questo modo, le capacità e le limitazioni nell’affrontare il compito oggetto dell’analisi saranno quelle del personaggio e saranno meno influenzate dall’esperienza dello specialista. Un interessante articolo per approfondire questo tema è Bring your personas to life!, scritto da Zef Fugaz e pubblicato su Boxes&Arrows e sul suo blog personale.

Il cognitive walkthrough con i personaggi passo passo
La sequenza dei passaggi indicata è quella necessaria per effettuare il cognitive walkthrough come analisi di usabilità a sé stante. Nel caso che lo si svolga all’interno di un processo di sviluppo user-centered, i punti 1, 2 e 3 dovrebbero essere stati già sviluppati durante le fasi di ricerca e analisi e di sviluppo del progetto. Per maggiori dettagli vedere il nostro Corso introduttivo allo user-centered design. Gli esempi mostrati si riferiscono ad un cognitive walkthrough effettuato per una procedura di acquisto (per ragioni contrattuali sono stati eliminati tutti i riferimenti al sito web oggetto dell’analisi).

Passo 1 - Sviluppare il personaggio
Nel caso di un’analisi di usabilità non inserita in un processo di sviluppo user-centered, lo sviluppo del personaggio deve essere iniziato con le attività di ricerca più appropriate. In questo caso, comunque, il personaggio sarà meno ricco di informazioni, in quanto sarà sviluppato su misura per la sola attività di analisi.
Il percorso da seguire per il reperimento delle informazioni di norma è questo:
- interviste all’interno dell’azienda (vedi II lezione del Corso UCD)
- consultazioni delle ricerche di pubblico dominio (vedi IV lezione del Corso UCD)
- veloci ricerche qualitative (per esempio, interviste telefoniche su un argomento specifico, ecc.)
Esempio di personaggio sviluppato appositamente per il cognitive walkthrough:



Passo 2 - Definire lo scenario
Lo scenario descriverà la situazione specifica che porta il personaggio a visitare il sito web e a utilizzarlo per il compito oggetto dell’analisi.
Esempio di scenario:

Riccardo legge su “Il Sole 24Ore” un articolo sulla (...), che illustra i vantaggi che questa può portare alle aziende in termini di risparmio di tempo e di denaro. In particolare, è interessato alla possibilità di (...). Riccardo va su Google, cerca (...) e arriva sul sito del servizio (...). Dopo un breve approfondimento, il servizio sembra interessante e conveniente, così decide di attivarlo.

Passo 3 - Definire il caso d’uso
Il caso d’uso descrive il percorso ideale nel sito web, che permette al personaggio di completare il suo compito.
Esempio di caso d’uso:

Cosa fa Riccardo Apre Internet Explorer, che ha Google come pagina predefinita. Digita (...) nella search box di Google. Cosa fa il sistema Mostra i risultati della ricerca. (...) è al terzo posto. Cosa fa Riccardo Clicca sul link (...). Cosa fa il sistema Carica la Home page del sito web (...). Cosa fa Riccardo Clicca sul bottone (...). Cosa fa il sistema Carica la pagina Che cos’è (...) che illustra le caratteristiche del servizio. Cosa fa Riccardo Legge le caratteristiche del servizio. Decide di attivare (...). Clicca sul link Home. Cosa fa il sistema Carica la Home page.

Passo 4 - Effettuare il cognitive walkthrough
Applicare il metodo con le modalità spiegate in precedenza ad ogni azione descritta nel caso d’uso.
Esempio di analisi:

Azione da svolgere Cosa fa Riccardo Procede con l’acquisto Cosa fa il sistema Carica la procedura di pagamento Analisi dell’azione Riccardo esplora la pagina web alla ricerca dell’azione che gli possa permettere di procedere. Domanda 1 L’azione è sufficientemente evidente a Riccardo? E:4 - No, non è presente nessun bottone che invita a concludere il pagamento. L’azione più evidente è Vai allo Step 4: Invio. Riccardo deve selezionare l’azione appropriata. Domanda 2 Riccardo è in grado di riconoscere l’azione in base alla sua descrizione? No, l’azione richiesta non è evidente in alcun modo. Il link Vai allo Step 4: Invio sembra preludere al completamento del compito, ma in realtà non è così. Domanda 3 Riccardo può capire se ha fatto la scelta giusta in base alla risposta del sistema? No. Procedendo con l’azione più evidente Riccardo non ottiene nessun avviso sul mancato pagamento, e viene portato nella pagina successiva Invio del contratto a (...).

Passo 5 - Preparare il report
Nel report devono essere indicati:
- gli obiettivi dell’analisi di usabilità
- la scala per la classificazioni dei problemi
- il personaggio e le motivazioni per la sua scelta
- le ricerche e le fonti utilizzate per lo sviluppo del personaggio
- lo scenario
- il caso d’uso
- l’analisi dell’interfaccia svolta con il cognitive walkthrough
Esempio di pagina di analisi:



Bibliografia
Per approfondire le tematiche sulla valutazione delle interfacce
consigliamo il volume
User Interface Design and Evaluation
D. Stone - C. Jarrett - M. Woodroffe - S. Minocha
2005, Morgan Kaufmann In vendita su Amazon.co.uk a 39,99 sterline

Per quel che riguarda i personaggi e il loro sviluppo consultare la bibliografia ragionata.

Ho iniziato a lavorare con i personaggi prima ancora che il metodo venisse conosciuto con questo nome e ho individuato, attraverso le ricerche e l’esperienza, tre importanti aree che devono essere tenute in considerazione: i dati, il coinvolgimento nella descrizione dei personaggi e il consenso da parte dell’organizzazione coinvolta nel processo di sviluppo, sia che si tratti di un redesign che di un nuovo progetto. Per questo motivo ho sviluppato dieci fasi che portano alla creazione dei personaggi, cercando di coprire l’intero processo, dall’acquisizione dei dati fino al completo sviluppo.  

Nell’articolo descriverò brevemente le dieci fasi. Nei progetti che prevedono l’uso dei personaggi non è necessario seguirle tutte: l’importante è sapere cosa comporta evitarne una. 

Fase 1: Cercare gli utilizzatori
La fase iniziale è quella di acquisire il maggior numero di informazioni sugli utilizzatori. Questi dati possono provenire da diverse fonti: interviste, ricerche sul campo, informazioni di seconda mano, questionari, relazioni, indagini culturali, ecc. Per esperienza, so che le grandi aziende hanno frequentemente un gran numero di informazioni sugli utilizzatori, relazioni dal marketing, dai call center, ecc. Queste fonti possono, in una certa misura, sostituire gli incontri con le persone reali ma creano anche problemi poiché non sono focalizzati sulle necessità del progetto. Questo apparirà chiaro nella prossima fase.  

Fase 2: Formulare un’ipotesi
Lavorare con i personaggi vuol dire focalizzare l’attenzione sugli utilizzatori nel contesto determinato dal progetto. Spesso le aziende parlano dei loro clienti in un modo che non prende in considerazione il differente contesto in cui si trovano quando usano un sito web o un software. In un recente progetto per un’autorità nazionale danese, consistente nel redesign di un portale web contenente relazioni sulle attività economiche destinate a diverse autorità governative, veniva usata una modalità di divisione del mondo degli affari danese in categorie di grandezza e di tipo di commercio. Dalle interviste con lo staff del call center e dalla lettura di molte relazioni prese vita un’altra ipotesi. La precedente divisione del mondo degli affari non aveva significato in questo progetto, perché non aveva importanza in che tipo di commercio agiva chi doveva redigere la relazione. Quello che importava era quanto grande fosse l’azienda e se la persona che redigeva la relazione fosse interna all’azienda o un consulente. Le indagini condotte precedentemente non erano state analizzate con queste premesse, quindi l’analisi doveva essere rifatta basandosi su questa nuova prospettiva.  

Fase 3: Verificare
Nella mia esperienza, la parte più difficile del lavoro inerente allo sviluppo dei personaggi è “come dividere la torta”, partendo dai dati per arrivare a decidere quali descrizioni includere nei personaggi. Questo comprende alcune delle dieci fasi e coinvolge più di un gruppo di consulenti o membri del team di progetto solo per elaborare le descrizioni. Nella fase di verifica, l’attenzione è posta sul reperimento dei dati che sostengano lo schema iniziale e, nello stesso tempo, la descrizione dei personaggi e la scrittura degli scenari. Il metodo dei personaggi richiede un certo tipo di informazioni che possano favorire la preparazione delle descrizioni e facilitare la scrittura degli scenari. Per esempio, cosa piace o non piace agli utilizzatori, quali sono i loro valori, qual’è il loro approccio con il software o sito web, in quali condizioni useranno il software o il sito web e, per finire, se i dati raccolti sono a favore o contro i dati iniziali.  

Fase 4: Trovare schemi
L’ispirazione, in questa e nelle precedenti fasi, ha origine dal cercare il significato nei dati raccolti con le ricerche qualitative. Si comprende di essere sulla strada giusta quando gli altri possono seguire le vostre argomentazioni e arrivare agli stessi risultati. Per poterlo fare, è importante mostrare gli schemi finali agli altri membri del team, ai partner nel progetto, ecc.

Fase 5: Sviluppare i personaggi
La fase cruciale arriva quando si deve scegliere cosa includere nella descrizione dei personaggi, evitando la creazione di stereotipi. Ho visto abbastanza spesso descrizioni in cui i personaggi erano presentati come superuomini o stereotipi, il che li rendeva difficilmente accettabili. In questa fase è necessario ricordare che lo scopo principale dei personaggi non è quello di descrivere come sono gli utilizzatori, ma creare soluzioni che usino le necessità del personaggio come punto di partenza. Al fine della comprensione dei personaggi, devono essere presenti nella descrizione cinque componenti principali che, se anche non menzionate direttamente, comunque facilmente deducibili dalla sua lettura.

- Corpo (una foto o una descrizione della persona creerà un senso di umanità. La postura e il vestiario raccontano molto della personalità)

- Psiche (tutti noi abbiamo un atteggiamento nei confronti della vita e su cosa ci circonda, che influenza anche il modo in cui ci avviciniamo alla tecnologia. Per esempio: il personaggio è introverso o estroverso)

- Background (tutti noi abbiamo un retroterra sociale, scolastico ed educativo che influenza le nostre capacità, gli atteggiamenti e la comprensione del mondo)

- Emozioni e atteggiamenti riguardo alla tecnologia e al campo in cui stiamo progettando

- Tratti personali. Questo è un aspetto complesso. Nella scrittura romanzata, c’è una distinzione tra tipi e caratteri a tutto tondo. Un tipo è caratterizzato dall’avere solo un tratto distintivo che si ripercuote in tutte le azioni che compie e crea un carattere assai prevedibile vicino agli stereotipi. Un tipo è difficilmente coinvolgente. Un carattere a tutto tondo ha più di un tratto caratteristico, non è prevedibile ed è più coinvolgente.

Quando si descrivono i personaggi diventa essenziale evitare gli stereotipi e creare, invece, delle descrizioni che i membri del team possano accettare e apprezzare. Un modo per evitare gli stereotipi è quello di cercare informazioni che reiterano le stesse caratteristiche. In un caso che ho trattato, il personaggio da descrivere, una donna, era incline ad esercitare autorità, e da questo i membri del team scrissero nella descrizione che essa lavorava per l’ufficio delle imposte. Questo influenzava il suo atteggiamento nei confronti della vita e, di conseguenza, nella descrizione veniva dipinta come persona in sovrappeso e con pochi amici. Per il team l’informazione “esercitare l’autorità” aveva creato un sentimento negativo sul personaggio, riscontrabile, poi, in tutte le altre informazioni che seguirono.  

La quinta fase è anche quella in cui si può incrementare l’accettazione. Nella mia esperienza, sono poche le organizzazioni che permettono ai membri del team di far parte del processo di scrittura. Al loro posto esse utilizzano consulenti o il personale del reparto usabilità per scrivere le descrizioni. Il metodo dei personaggi dovrebbe essere, invece, percepito come un processo dove tutti devono capire da dove le descrizioni sono estrapolate e come possano essere utilizzate. Se si permette ai membri del team di essere parte del processo di scrittura, si sentiranno anche loro padroni dei personaggi. In seguito, le descrizioni potranno essere riscritte da una singola persona per assicurarne l’omogeneità nella scrittura e nella presentazione. In ogni modo, si trarranno benefici dall’inclusione di più persone nel processo di scrittura o, come in un nostro precedente progetto, nel lasciare ai membri del team la scelta delle fotografie per i personaggi.

Fase 6: Definire le situazioni
Come detto in precedenza, il vero scopo dei personaggi è quello di creare scenari dalle descrizioni. Questa fase è una preparazione agli scenari nella quale viene descritto il personaggio, in quali situazioni userà il software / sito web o quali necessità ha il personaggio che preludono a una situazione d’uso. Ogni necessità o situazione è il passaggio iniziale che porterà agli scenari.  

Fase 7: Validazione e accettazione
Per essere sicuri che tutti i partecipanti al progetto siano d’accordo sulle descrizioni e le situazioni, possono essere seguite due strategie: chiedere la loro opinione e/o coinvolgerli nello sviluppo dei personaggi. Spesso il metodo dei personaggi è visto come uno strumento di comunicazione delle necessità degli utilizzatori verso gli sviluppatori o altri soggetti, mentre in realtà è un processo che permette lo sviluppo user-centred. Un chiaro processo di sviluppo aiuta a creare opportunità che permettano alle molte persone coinvolte nel progetto di partecipare allo sviluppo dei personaggi e ad usarli nel progetto.  

Fase 8: Disseminare la conoscenza
Sono completamente cosciente che non tutti possano essere parte del processo. Nuovi arrivati o altre aziende potrebbero essere coinvolte. Ma se i personaggi non sono resi disponibili a tutti, non hanno nessun valore. Non solo i personaggi, ma anche i dati su cui è basato il loro sviluppo devono essere fatti conoscere (quello che Grudin, Pruit e Adlin chiamano documento fondante). Inoltre, è essenziale spiegare come e per che cosa si useranno i personaggi. In molti progetti si tralascia di informare e di insegnare agli sviluppatori e ai progettisti come usare i personaggi, come pensare con gli scenari o come utilizzarli nei casi d’uso.

Fase 9: Creare gli scenari
I personaggi non hanno valore se non sono inseriti in uno scenario. Uno scenario è come una storia: ha un protagonista principale (il personaggio), un set (qualunque posto dove l’azione si svolga), un obiettivo (quello che il personaggio persegue), un’azione che porterà all’obiettivo (interazione con il software / sito web / strumento) e, non meno importante, degli ostacoli che bloccano la strada verso l’obiettivo. Ho visto spesso quelli che chiamo “scenari felici”, dove uno strumento risolve tutti i problemi. Provate a leggere la descrizione di Mrs Tahira Khan, e di come riesce a sconfiggere il diabete: capirete di cosa parlo. Non è realistico, né convincente, lo scenario che permette a una donna di 65 anni, in viaggio in Gran Bretagna, sofferente di un diabete non diagnosticato, che non comprende bene l’inglese e che non è ben istruita neppure nella sua lingua, di sconfiggere il diabete con uno strumento elettronico.

Fase 10: Sviluppo continuo
Per ultimo, raccomando di aggiornare le informazioni sui personaggi. Questo deve essere fatto se i test con gli utilizzatori mostrano all’improvviso nuovi risultati o se qualcosa cambia nell’ambiente dei personaggi. È importante che non tutti siano in condizione di cambiare le informazioni, ma che tutti sappiano chi possa farlo se necessario. Inoltre, raccomando spesso di avere un ambasciatore per i personaggi, che tenga sempre sotto controllo le descrizioni e che possa essere interpellato dagli altri partecipanti al progetto per segnalare errori nelle descrizioni. E infine, come Adlin e Pruit raccomandano nel loro libro “The Personas Lifecycle”, lasciare che i personaggi escano di scena dopo aver raggiunto il loro scopo.

L’articolo originale, “Ten Steps to Personas”,
è stato pubblicato sul sito web HC Vista
(http://www.hceye.org/HCInsight-Nielsen.htm).

La Dr.ssa Lene Nielsen è una specialista danese di user-experience, interaction design e usabilità. Nel 2004 ha pubblicato la sua tesi di dottorato (Ph.D.) "Engaging Personas and Narrative Scenarios". È autrice di numerose pubblicazioni e articoli dedicati ai personaggi e agli scenari. È assistente part-time al Center of Applied ICT della Copenhagen Business School e consulente part-time della Snitker & Co per l’usabilità. La Dr.ssa Nielsen pubblica un blog dedicato ai personaggi, www.personas.dk, in lingua danese.