1983, Monterrey, California. All’Old Del Monte Golf Club un personaggio bizzarro si aggira parlando da solo e gesticolando sotto gli occhi stupiti degli avventori. Quel personaggio bizzarro si chiama Alan Cooper e quello che sta facendo è, di fatto, porre le basi di uno degli strumenti oggi più utilizzati per la progettazione di sistemi digitali: le user personas.
Cooper racconta come a quei tempi la compilazione dei sorgenti potesse metterci un’ora o più. Ne approfittava quindi per lanciare la compilazione durante la pausa pranzo e andare all’Old Del Monte golf club, che era vicino al suo ufficio. In queste pause era solito passeggiare facendo una sorta di gioco di ruolo in cui recitava dialoghi immaginari con il Project Manager riguardanti il programma che stava realizzando. Il Project Manager raccontava bisogni, problemi e faceva richiesta di nuove funzionalità.
Questi dialoghi non erano frutto della fervida immaginazione di Cooper ma si basavano su interviste che aveva fatto in precedenza a persone reali dell’azienda e sugli insight che ne erano scaturiti.
Dovranno passare degli anni e solo nel 1998 nel libro “The Inmates are running the Asylum” Cooper darà forma alle user personas così come le conosciamo oggi.
Ma in quei bizzarri monologhi lungo i campi da golf sono già visibili la potenza e i vantaggi dell’uso delle personas:
Le user personas sono delle rappresentazioni di cluster di utenti di un prodotto o servizio in cui vengono descritti comportamenti, bisogni e criticità che questi incontrano.
Queste informazioni vengono riassunte in schede di una pagina da utilizzare durante la progettazione.
Ci possono essere diversi tipi di schede con informazioni più o meno dettagliate.
Anche in Ariadne Digital ne abbiamo sperimentati diversi formati ma i dati che non possono mancare sono:
Queste informazioni non sono frutto di speculazioni ma derivano dai dati raccolti durante la fase di ricerca, da analisi statistiche, interviste, workshop etc.
Quante personas sono necessarie? Non c’è una regola precisa, dipende dai progetti ma 3 personas potrebbero essere il più delle volte sufficienti. Ricordiamo che non si tratta di uno strumento quantitativo, non deve rappresentare la popolazione in maniera statistica, si tratta di uno strumento che raggruppa utenti, anche molto diversi tra loro, ma che hanno stessi obiettivi, bisogni e frustrazioni. Più che rappresentare tutta la gamma demografica dei possibili utenti deve rappresentare tutti i bisogni principali.
Si fa presto a dire Personas ma se facciamo una veloce ricerca su Google troviamo differenti titoli.
User personas, buyer personas, proto personas... Che differenza c’è?
Le user personas sono quelle descritte nei paragrafi precedenti e vengono utilizzate principalmente da User Experience Designer nella progettazione di prodotti digitali. Come abbiamo visto, aiutano designer e sviluppatori a empatizzare con i potenziali utilizzatori e a sviluppare prodotti che siano più vicini ad esigenze reali.
Le buyer personas sono utilizzate invece nel marketing per rappresentare potenziali acquirenti del prodotto. In questo caso più che creare empatia lo scopo è di approfondire la comprensione dei comportamenti e delle motivazioni di acquisto. Inoltre, includono diverse informazioni soprattutto su aspetti demografici o geografici.
Spesso user personas e buyer personas non rappresentano gli stessi utenti, pensiamo all’acquisto di device per un ufficio: chi si occupa dell’acquisto potrebbe essere il responsabile IT o l’Amministrazione, mentre i prodotti verranno utilizzati dai dipendenti dell'azienda.
Le proto-personas sono infine una versione agile delle personas. Da quando Jeff Gothelf ha pubblicato "Lean UX" si è diffusa la pratica di creare le personas durante workshop in cui coinvolgere i principali stakeholder del progetto. In questo caso non ci basiamo su dati forniti dalla ricerca ma sulle conoscenze delle persone invitate, per questa ragione vengono chiamate proto-personas, perché sono un po’ dei simulacri dello strumento originario. E’ chiaro che in questo caso le personas siano meno robuste. Detto questo, meglio delle proto-personas traballanti, che non utilizzarle affatto e muoversi solo sulla base dei gusti e delle idee del committente.
Va detto inoltre che le proto-personas dovrebbero far parte di un processo lean che punta a creare un prodotto minimo di valore (MVP) da testare velocemente sul mercato per correggere eventualmente il tiro. Le Proto-personas diventano quindi delle ipotesi da testare e ad aggiustare per arrivare a centrare l’obiettivo in sprint successivi.
Una metodologia che stiamo usando sempre più spesso in Ariadne Digital per definire quali personas rappresentare e la teoria degli estremi di IDEO.
Nello sviluppare un progetto o un prodotto i comportamenti che possono restituirci gli insight più interessanti non sono quelli dell’utente medio, bensì quelli di chi sta agli estremi.
Secondo questa metodologia si decide la lente attraverso la quale osservare i nostri utenti, che a seconda della tipologia del progetto potrà essere differente.
Ad esempio potrebbe essere l’età, l’esperienza o la conoscenza che si ha del prodotto o servizio. Quindi si elencano le persone che potrebbero essere alle due estremità di questa lente.
Ad esempio, se la lente è la conoscenza chi sono gli utenti che hanno poca conoscenza all’interno del nostro progetto? E chi sono quelli che ne hanno molta?
A chi sa poco dobbiamo fornire un servizio che lo accolga, non lo faccia sentire smarrito e lo accompagni passo dopo passo ad accrescere conoscenze e sicurezza. Se sapremo creare un prodotto facile da usare per questo utente, ne beneficeranno tutti.
Da chi sa molto potremo imparare come sviluppare nuove funzionalità che solo un utente esperto sa vedere e chiedere e che poi possono essere messe a disposizione di tutti.
Bene, hai creato le tue 3 schede che rappresentano le principali user personas e adesso?
Prima di tutto condividile con il team e gli stakeholder. Tutti gli attori coinvolti dovrebbero comprendere il valore delle personas, fino a parlarne come di persone reali. Nel momento in cui sorgono dei dubbi di progettazione o sviluppo la domanda non dovrebbe essere più cosa potremmo fare? Ma: cosa vorrebbe Maria, Luca o Cristina (o comunque abbiate deciso di chiamare le vostre personas)?
Poi usa le personas come punto di partenza per creare experience map e user stories.
Ma questa è un’altra storia e l’affronteremo meglio in un prossimo post.