Di seguito tutti gli interventi pubblicati sul sito, in ordine cronologico.
 
 

Vi segnalo un eccellente post di Leisa Reichelt sui personaggi, "Personas are for hippies… and transformation and focus". Leisa, in poche righe, evidenzia l'importanza dell'utilizzo dei personaggi all'interno di grandi organizzazioni che, molto spesso, fanno fatica a mettere a fuoco le esigenze e le necessità dei loro clienti. Inoltre, e questa è senza dubbio una delle ragioni che più condivido, i personaggi permettono anche di "reduce usage of the term ‘user’ (so abstract, inhuman and elastic) and replace it with our personas names".

Certo, continua Leisa, i personaggi devono essere ben sviluppati e ben utilizzati, altrimenti è meglio non sprecare energie con loro. Ma come si può capire se i personaggi rispondono a queste caratteristiche? Con un test, ovviamente.

Eccolo qui:
- do you have personas for your project/product?
- are they made of data from real (potential) customers?
- do they have real names not segment names?
- do you have fewer than five personas?
- can you remember all the names of your personas and describe them?
- do you use them to guide, evaluate and/or explain design decisions?
- can your boss name your personas?
- can the developers on your team name your personas?

La maggioranza delle risposte deve essere si. Provate e fatemi sapere.

P.S.
Ho partecipato ieri a Torino alla conferenza user experience 2.0 e, tra le tante presentazioni, tre hanno suscitato il mio interesse e confermano quanto scritto dalla Reichelt. Sono due casi di studio e un intervento sullo sviluppo dei personaggi, presentati da grandi organizzazioni che ne hanno recepito l'importanza e le potenzialità.

I casi di studio sono stati presentati da Whirlpool e Tetrapack. Nei loro progetti i personaggi sono stati sviluppati al termine di una vasta fase di ricerche sul campo e utilizzati nella fasi di progettazione.

Lo sviluppo dei personaggi è stato trattato nella presentazione di Elena Guercio (strategy/innovation - progetti di ricerca di telecom italia). La peculiarità risiede nel fatto cha hanno creato dei layer di base dai quali partire per sviluppare poi personaggi specifici. Un approccio decisamente interessante per accorciare i tempi di sviluppo e risparmiare risorse.

Vi segnaliamo un'interessante articolo, Avoiding Half-baked Personas, nel quale Todd Wilkens (Adaptive Path) spiega cosa sono e le differenze tra Ad-Hoc Personas e Proto-personas.

Le Ad-hoc Personas sono i personaggi sviluppati velocemente, per mancanza di tempo e risorse, attingendo ai soli dati disponibili all'interno di un'organizzazione, senza effettuare attività di ricerca. Jared Spool le definisce user descriptions, perché per lui non possono essere definiti personaggi.

Le Proto-personas sono, invece, il primo passo concreto nello sviluppo dei personaggi e sono basate sulle prime intuizioni che si hanno durante la fase di ricerca.

In entrambi i casi si tratta di personaggi allo stato iniziale, che si devono usare con cautela e solo per alcune situazioni specifiche, come la preparazione al recruiting - nel caso delle Ad-hoc Personas - e per iniziare a far emergere pattern condivisi - nel caso delle Proto-personas.

Da leggere anche i commenti, trai quali è molto condivisibile quello di Indi Young.

Vi segnaliamo alcuni strumenti che possono tornare utili durante la prototipazione di interfacce. Non sono solo software ma anche "analogici". Questi ultimi saranno molto apprezzati da chi, come me, utilizza la matita come primo strumento di prototipazione. 

UXPin
Questo è il mio preferito. Si tratta di un blocco che riproduce su carta la schermata di un browser e fornisce elementi adesivi per form, bottoni e altro ancora.
Il set è acquistabile online sul sito http://www.uxpin.com/

UI Stencils
Stencil in metallo per prototipare interfacce di siti web e di applicazioni iPhone, iPad e Android. Inoltre, ci sono anche i blocchi che riproducono le schermate dei browser e dei device mobili. 
Il prodotti sono acquistabili online sul sito http://www.uistencils.com/

MockupScreens
Un software che permette di creare le schermate in modo molto veloce e intuitivo e di organizzarle in presentazioni che simulano flussi e interazione.
Il prodotto è acquistabile online sul sito http://mockupscreens.com/

Interface
Una app per iPhone e iPad che permette di creare prototipi di apps direttamente sul device di riferimento. Permette, poi, di visualizzare in anteprima il risultato e di esportarlo in Xcode.
Il prodotto si acquista su App Store.
Per maggiori informazioni http://lesscode.co.nz/interface

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

L’argomento del workshop è stato l’innovazione che, a nostro parere, diventa significativa quando rende più facile la vita delle persone. Nello specifico abbiamo parlato di ricerche etnografiche, interviste e diari e degli strumenti di analisi e progettazione che supportano lo sviluppo di prodotti e servizi digitali che vanno incontro alle reali necessità delle persone.

Questo approccio, che tiene conto prima delle persone e poi di altri fattori, è essenziale per lo sviluppo dei servizi digitali in Italia. I numeri non lasciano dubbi. Abbiamo uno dei più bassi tassi di utilizzo della rete, al 22° posto secondo un’indagine Nokia. E non è un problema di infrastrutture. A nostro parere, sono inadeguati gli approcci ai progetti a impedire innovazione e sviluppo. Approcci tutti centrati o sulla creatività fine a se stessa o sulla tecnologia, che non rimuovono la barriera più grande: il senso di inadeguatezza che le persone sentono quando utilizzano dei dispositivi e dei servizi digitali non progettati per loro. Spesso, dopo un primo approccio, la frustrazione prende il sopravvento e smettono di utilizzarli.

Per questo è necessario un approccio che faccia emergere le reali necessità delle persone, soprattutto di quelle al momento escluse. Le prospettive, per chiunque abbracci questo modello di progettazione, possono essere enormi, perché darebbero un vantaggio competitivo senza eguali.

Le slide e lo script (PDF 25Kb) del workshop a SMAU2010 / smau10Mi

Vi segnaliamo un podcast con un'intervista a Kim Goodwin, autrice di Designing for the Digital Age. Nell'intervista, condotta da Jared Spool, la Goodwin sottolinea come gli scenari, abbinati ai personaggi, siano uno dei più potenti e versatili strumenti di progettazione. Inoltre, spiega anche la differenza tra scenari, user cases e user stories. Il podcast è disponibile a questo link:
http://www.uie.com/brainsparks/2010/10/15/spoolcast-designing-with-scenarios-featuring-kim-goodwin/

A tre anni dalla pubblicazione abbiamo aggiornato il corso introduttivo allo user-centred design. Principalmente si tratta di piccole modifiche e dell'inserimento delle descrizioni di nuovi strumenti di ricerca. 

Questi gli argomenti trattati, lezione per lezione:

- Cos'è lo user-centred design (I lezione)
- Le attività di ricerca nell'universo aziendale (II lezione)
- Le attività di ricerca nell'universo internet (III lezione)
- Le attività di ricerca nell'universo dei navigatori (IV lezione)
- Segmentazione dei visitatori (V lezione)
- I personaggi, gli obiettivi e gli scenari (VI lezione)
- Le attività nello sviluppo del progetto (VII lezione)
- Le attività nella produzione e dopo la pubblicazione (VIII lezione)

Vi segnaliamo un articolo, Persona driven user stories for Agile UX, nel quale Leisa Reichelt descrive la sua esperienza con personaggi e user stories.

La Reichelt afferma che scrivendo user stories con protagonisti i personaggi si ottengono due importanti benefici. Il primo, è che i personaggi diventano parte attiva del progetto e che non vengono messi da parte e dimenticati. Il secondo, è che con i personaggi è più semplice scrivere user stories mirate e soprattutto veramente utili al progetto. Anche i commenti sono da leggere, perché contengono alcuni spunti interessanti.

Alla fine di questa segnalazione, mi piace ricordare che quasi due anni fa, nel nostro post Sviluppo Agile e User-Centered Design felicemente sposi?, avevamo scritto più o meno le stesse cose e queste considerazioni della Reichelt  confermano la bontà del nostro approccio allo Agile UX.

Vi segnaliamo un articolo, Personas as User Assistance and Navigation Aids, nel quale Mike Hughes illustra un atipico utilizzo dei personaggi.

Hughes, dopo aver contribuito a svilupparli e averli passati al team di sviluppo, ha scoperto alla fine del progetto che erano stati anche utilizzati all'interno del sito web come supporto e guida alla navigazione. In pratica il visitatore può scegliere il personaggio con cui si identifica di più e attraverso gli scenari d'uso abbinati raggiungere i contenuti che possono essere di suo interesse. Davvero un utilizzo molto intelligente. L'articolo è stato pubblicato su UX Matters.

Come sempre in queste occasioni, quando si torna si prova un senso di euforia, come quello dovuto all’aria di alta montagna. Tutto sembra facile e possibile. A poco a poco l’effetto svanisce, ma rimane sempre la sensazione di essere più ricchi e di avere maggiore consapevolezza del proprio lavoro. E questo, grazie alle persone incontrate e alle idee condivise. Quelle che seguono sono alcune considerazioni, fatte a mente fredda, su quello che ho visto e ascoltato.

- La maggior parte delle presentazioni trattavano dell’usabilità come processo e non come strumento di valutazione. Si è parlato, quindi, di human-centered design, user experience, etc. senza mai perdere di vista l’obiettivo ultimo di questi approcci: rendere facile la vita alle persone che utilizzeranno i prodotti.

- Ricerche etnografiche e personaggi sono sempre parte integrante di questi approcci. In alcuni casi, Oracle per esempio, come strumenti per guidare l’innovazione. In altri casi, strumenti di progettazione, come nella presentazione di Mad*Pow.

- Tutti i produttori di sistemi per l’eyetracking erano presenti con i loro stand e almeno due presentazioni erano dedicate a promuoverne l'utilizzo. L’unico intervento che ho seguito non ha smosso di un millimetro la mia convinzione che si tratta di uno strumento poco utile. In uno degli esempi mostrati, non era certamente necessario l’eyetracking per capire che le immagini in un catalogo di e-commerce erano troppo piccole e che era necessario ingrandirle per aumentare le vendite. Gli altri esempi, credetemi, non erano certamente più incisivi. A quanto pare, il punto di forza dell’eyetracking non è la sua capacita di fornire indicazioni utili, ma quello di farle vendere, per quanto banali siano. Certo, se si hanno circa 90.000 euro da buttare, tra sistema e formazione, è indubbiamente un buon investimento.