Una guida per la creazione delle personas

Abbiamo già parlato di personas in passato. Come sapete è un mio cavallo di battaglia…

UXPressia - template personas
UXPressia è un tool online di creazione delle personas


Vi ho raccontato cosa sono le personas, quali strumenti potete utilizzare per costruirle, che tipo di domande potete fare nelle interviste e quali modelli prendere ad esempio.
Oggi torno su questo tema perché mentre stavo facendo una ricerca sui tool di creazione online delle personas – di cui parlerò prossimamente – mi sono imbattuta in un documento che penso possa fornire degli spunti interessanti.

Si tratta della guida di UXPressia, una start-up di San Mateo Califonia nata nel 2014 da un gruppo di progettisti appassionato di design thinking.
UXPressia è un tool online di creazione di personas, customer journey e impact maps che favorisce un approccio collaborativo.

La guida in questione è ovviamente uno strumento di marketing per far conoscere il loro applicativo ma contiene diversi spunti interessanti che penso valga la pena condividere.
Qui potete scaricarla.

Creare le personas

La guida ripercorre le basi della teoria e i vari elementi di cui abbiamo già parlato: le domande volte a chiarire gli aspetti demografici (chi sono i nostri clienti? che età hanno? dove vivono? ecc.) e quelli comportamentali (cosa vogliono ottenere? perché fanno quello che fanno? cosa li motiva? ecc.).
Ricordate? L’obiettivo è arrivare a comprendere gli obiettivi, le attività, i bisogni e le difficoltà di clienti e utenti perché queste informazioni sono risorse preziosissime per migliorare la customer experience e, in generale, i nostri prodotti e servizi.

L’utilizzo di scale di comportamento

Uno dei punti della guida che porto alla vostra attenzione è questo: le interviste ai clienti e ai clienti potenziali ci devono permettere di identificare attributi comportamentali comuni.
Ma cosa intendiamo per attributi comportamentali?
L’attributo descrive cosa influenza una persona nelle situazioni in cui cerca di completare un task, sta perseguendo un obiettivo, cerca di risolvere un problema o interagisce con il nostro prodotto. Ad esempio ogni quanto compie una determinata attività, per quali ragioni è portata a fare una determinata cosa, che strumenti usa, da dove ricava le informazioni, che cosa la frena dal farla?

La guida suggerisce di definire tutti i possibili valori di ogni attributo e mapparli su delle scale.
Nel caso di prima potremmo dire che una persona evita di fare una certa attività – ad esempio gestire direttamente le proprie finanze – perché:

  • pensa di non essere in grado di tener traccia di tutti i dettagli
  • è un’attività che porta via molto tempo
  • ha paura di perdere informazioni rilevanti
  • teme che altre persone possano avere accesso alle informazioni
  • pensa che sia una perdita di tempo.

Questi sono tutti modi di pensare emersi dalle interviste che avete fatto; semplicemente li state posizionando in una scala di comportamenti.
Al termine delle interviste vi troverete con un numero di scale che va da 5 a 20 e, per ogni scala, almeno 3 valori presenti.
Le scale possono riguardare elementi di tutti i tipi, sta a voi scegliere cosa è più rilevante nel vostro caso:

  • fattori umani (età, area geografica, educazione, fisiologia, ecc.)
  • bisogni, obiettivi, aspettative
  • problemi, barriere, frustrazioni
  • conoscenza dell’ambito
  • attività da portare a termine
  • elementi che scatenano l’azione
  • tempo d’esecuzione
  • esperienza del prodotto / servizio
  • ambiente
  • relazione con altri attori durante l’attività.

Collocare gli intervistati sulle scale di comportamento

Una volta definite le scale e i diversi valori al loro interno è giunto il momento di posizionare gli intervistati rispetto ai vari attributi.
Qui stiamo proprio collocando i nomi delle persone con cui abbiamo parlato sui loro attributi quindi ogni nome appare in ciascuna scala.

Vi accorgerete che alcune persone appaiono più volte nella stessa posizione o in posizioni molto vicine. La guida suggerisce che quando le stesse persone appaiono così in diverse scale (da 5 in su) abbiamo individuato un pattern.

Gli intervistati sono mappati rispetto a scale di attributi
Gli intervistati vengono collocati su varie scale di attributi. La presenza di posizioni simili su più scale indica un pattern.


Queste similarità sono il fondamento per la costruzione di una persona.
Possiamo fare una prova del nove: se il pattern identificato è logico e spiegabile allora siamo sicuri di avere individuato un aspetto rilevante della personas.

Personalmente non ho mai utilizzato le scale nel processo di creazione delle personas e ho sempre portato avanti questa fase di individuazione delle somiglianze in maniera più artigianale ma questa tecnica mi sembra molto efficace e decisamente adatta ad una creazione collaborativa. Non mancherò di provarla quanto prima!

Scaricate la guida per costruire le personas! In appendice trovate una lista di domande da cui potete prendere spunto per tracciare le vostre interviste.

Continuous Discovery: metti una sera un webinar con Teresa Torres

Conoscete Teresa Torres? Per me Teresa è un mito!
Si definisce una Product Discovery Coach, è autrice di “Continuous Discovery Habits” e del blog producttalk.org.
Il suo lavoro è aiutare i team in aziende di tutte le dimensioni a prendere buone decisioni su cosa sviluppare rendendo le best practices sempre più semplici.

Martedì 1 febbraio Teresa ha tenuto un webinar dal titolo “The What & Why Of Continuous Discovery”. Potevo mancare a quest’occasione? No! Insieme a me c’erano più di 1000 persone registrate all’evento e collegate da tutto il mondo per capire come fare a calare questa pratica nella quotidianità della propria organizzazione.

Che cos’è la Product Discovery

Discovery = deciding what to build; Delivery = building it

La Product Discovery è un insieme di attività per capire che cosa ha senso sviluppare, mentre con delivery intendiamo lo sviluppo vero e proprio.
Alcune delle pratiche utilizzate nella fase di discovery sono ad esempio le interviste ai clienti, la definizione delle personas e dei jobs to be done, le customer journeys, le sessioni di brainstorming e co-design.

Discovery e delivery non sono attività separate o fasi distinte nel processo di creazione del prodotto perché la linea di demarcazione tra le due tende a sparire.
Secondo la Torres sono entrambe importanti nonostante molte aziende tendono a sottovalutare la prima.
Il suo invito è di approcciare la discovery mettendo l’accento sulla continuità di questa attività. Non si tratta di un progetto con una deadline temporale, bensì di una pratica sempre in corso nel team.

Quando fare Product Discovery

La best practice definita dalla Torres consiste in touchpoint settimanali del team che sviluppa il prodotto digitale con i clienti o potenziali clienti allo scopo di apprendere il “desired product outcome”, ovvero il valore dal loro punto di vista.

Attenzione quindi perché la discovery non è un’attività relegata esclusivamente alla fase iniziale del ciclo di vita del prodotto o al momento in cui si è alla ricerca del product – market fit.
La cadenza continua di questa attività anche in una fase matura del prodotto stesso consente di raggiungere un miglioramento continuo.
Del resto i prodotti digitali non sono mai finiti; è sempre possibile ottimizzarli finché sono in vita e per fare ciò è fondamentale includere i clienti nel processo, co-creare con loro.

Ma da dove si comincia se la Product Discovery è una pratica di cui nessuno ha mai sentito parlare in azienda? Come si fa a raggiungere quei livelli?
Come sempre partiamo da dove siamo.
Se non avete mai parlato direttamente con un cliente alzate il telefono e fissate questo primo incontro. Se le chiacchiere che fate sono solo sporadiche potreste cominciare a mettere in agenda un appuntamento fisso mensile, e così via.
La cosa importante è puntare al miglioramento continuo e progredire passo a passo con l’obiettivo di arrivare a una cadenza settimanale di incontri.

Ricordate: state allenando i muscoli della cooperazione e un nuovo approccio al design!

Chi partecipa alla Product Discovery

Pensate che la Discovery sia di dominio esclusivo del Product Owner? Non è così.
Il minimo sindacale per portare avanti questa attività richiede la coesistenza di 3 figure: il product owner, il designer e il team leader, il cosiddetto “Product Trio”.
Questo è il minimo delle persone da coinvolgere ma se più persone del team volessero partecipare ben venga!
L’importante è lavorare assieme, portare avanti le interviste in coppia o in trio in modo tale da condividere più punti di vista.

Non esiste un hand-off tra le 3 figure.
Vogliamo davvero tornare ai tempi in cui il prodotto passava le specifiche al reparto creativo e questo passava i template allo sviluppo senza un minimo di interazione? Il risultato è sempre stata una perdita di fedeltà con l’idea iniziale del cliente e – più spesso del previsto – la creazione di una soluzione sbagliata.
Ecco perché oggi includiamo tutti – ingegneri compresi – nelle decisioni su cosa andare a sviluppare.

Scopo della Discovery

La Discovery portata avanti dal product trio ci consente di definire l’impatto che vogliamo ottenere con il nostro prodotto digitale, non la lista di funzionalità che andremo a sviluppare (ricordate la la differenza tra output e outcome?).
I cambiamenti sono costanti nel mercato, emergono continuamente nuove tecnologie e nuovi competitor; le nostre stesse release di prodotto hanno un effetto che porta a nuove richieste.

L’obiettivo della Product Discovery è identificare nuove opportunità, prioritizzarle e ideare soluzioni che indirizzino le più promettenti.
Teresa ci ricorda che è fondamentale non buttarsi sulla prima soluzione che ci è venuta in mente perché potremmo essere influenzati da tanti bias.
Le opportunità vanno messe a confronto tra loro.
Se volete capire meglio come effettuare questa selezione vi consiglio di prendere in considerazione quello che lei ha da dire sul tema opportunity tree (su cui tornerò anch’io a breve…):

Chi scrive le user stories nel tuo Scrum team?

Se pensate che sia una domanda retorica ebbene non lo è!
E’ anzi un interrogativo su cui può essere utile mettere a confronto esperienze di vita diverse.
Questa riflessione nasce in seguito alla partecipazione ad un meetup di Pierluigi Pugliese intitolato “Stupidaggini che avete sentito su Scrum, Ep. 3: Le User Stories non si scrivono!”, organizzato all’interno del gruppo Milano Scrum/Agile User’s Group.

Il titolo – inutile dirlo – mi ha attirato ed ero sicura che potesse aggiungere spunti interessanti alle riflessioni su uno degli strumenti più utilizzati dai Product Owner.
Ma non parleremo soltanto di chi scrive le user stories, smonteremo anche alcune “leggende metropolitane” che derivano da cattive pratiche ed insegnamenti discutibili discussi durante l’incontro con l’Agile coach.

Inutile dire che molti di questi comportamenti errati li ho vissuti in prima persona e in alcuni casi so di esserne stata anche corresponsabile, quindi voglio fare la mia parte nel smantellarli insieme a voi.
Nella mia esperienza con diversi development team Scrum ho visto un po’ tutte le situazioni: dai team che non fanno partire lo sviluppo se non ci sono user stories super-dettagliate, al PO che si sobbarca l’intero onere della chiarificazione dei bisogni, ai team che che contribuiscono solo al livello degli acceptance criteria fino a quelli più navigati che sono in grado di scrivere storie end-2-end e spacchettarle a dovere.
Tutte queste situazioni – giuste e sbagliate – sono dei pattern ed è utile sapere come affrontarle.

Ma partiamo dalla prima di queste male pratiche…

Il minimalismo delle user stories

Le storie sono:

  • il valore di business che vogliamo generare per l’utente
  • una promessa di conversazioni
  • riassumono l’aspettativa di business
  • descrivono l’attività da fare
  • sono un elemento di pianificazione
  • non si scrivono

Vi ritrovate in queste affermazioni?
C’è forse qualcosa che vi stona?
Davvero le user stories non si scrivono? Cosa intende dire Pugliese?

Pierluigi con questa affermazione provocatoria vuole ribadire che le user stories non sono semplicemente un modo un po’ diverso di esprimere i requisiti, un altro tipo di formato, bensì piuttosto un modo minimalista per descrivere le funzionalità e di semplificare la parte burocratica.

Questo approccio minimalista funziona a patto che la conversazione tra stakeholder, sviluppatori e Product Owner avvenga davvero.
La scrittura è secondaria; la card riassume la conversazione e non ne contiene tutti i dettagli, solo ciò che serve al team per ricordarsi cosa deve fare.

Capite bene che questo approccio definito lightweight dagli agilisti (= leggero) sta in piedi se e solo se una reale interazione avviene.
Se non c’è un momento di confronto e di approfondimento qualsiasi user story sarà monca, una promessa (di conversazione) non avvenuta.
E a quel punto nascerà inevitabilmente la richiesta di una maggiore documentazione.
Infatti una cosa che mi è spesso capitato di notare è che quando i team sono meno maturi tendono a utilizzare le storie come copertine di Linus e chiedono al Product Owner di specificare e dettagliare molto di più.

Quando ravviso questo comportamento so che è il momento di alzare le orecchie.
Può essere un indicatore rilevante del fatto che:

  • il chiarimento non è ancora avvenuto (la card non serve a eludere la conversazione)
  • Il vero valore dello strumento user stories non è stato compreso (siamo di fronte a una trasposizione dei vecchi documenti di requisiti)
  • il team demanda in toto la chiarificazione al PO (di questo aspetto ne parliamo più in là…)
  • c’è scarsa fiducia tra gli interlocutori (questo – se vero – è l’aspetto più problematico che richiede attenzione immediata).

Le parole di Pugliese per me sono sempre illuminanti…

Senza la conversazione le user stories non hanno senso. Non sono una religione alternativa per scrivere i requisiti! Se usate in maniera stupida, meccanica, inutile e dannosa fanno spegnere il cervello agli sviluppatori

Chi fa la business analysis?

Chi è l’owner della business analysis? La domanda sembrerebbe retorica… in fondo esiste una figura professionale proprio per questo, tuttavia negli Scrum team come sapete non ci sono singoli “detentori” di attività.
E’ un punto importante spesso poco capito. Nel team ideale tutti fanno tutto, o meglio sono in grado di fare tutto. Nella realtà spesso non è così perché le competenze e le seniority sono diverse, ma pratiche come il peer programming e le pair review ci vengono in aiuto facendo sì che la conoscenza di tutto il team aumenti progressivamente con il tempo.

La stessa cosa vale per l’analisi dei requisiti.
Magari date per scontato che il momento della chiarificazione dei bisogni sia appannaggio del Product Owner e del business analyst (se avete la fortuna di averlo) ma non è così!

“Voglio che il team faccia business analysis” – ha insistito il coach durante il meetup – “Più persone possibili devono saper fare le domande giuste e ovviamente devono avere competenze di dominio sufficienti per fare le domande giuste”.

Ma a cosa punta questo approccio? La finalità è avere una responsabilità condivisa dell’intero Scrum team sul risultato finale. L’analisi è una premessa fondamentale per fare la modellazione di un sistema attraverso le user stories.
Per questo motivo secondo Pugliese è un’attività che può essere portata avanti direttamente dal team con gli stakeholder senza necessariamente la presenza del Product Owner (ricordate quando si diceva di “smettere di fare il piccione viaggiatore”?)

Il vero ruolo del Product Owner

Ma se il product owner non scrive le storie e non fa chiarificazione – ha chiesto un partecipante – qual è esattamente il suo ruolo?
Esattamente quello che prescrive la Scrum Guide: essere il responsabile di massimizzare il valore prodotto.

Il PO non fa chiarificazione, può partecipare a questa attività ma non è il suo focus primario. Il product owner regola il sistema dal punto di vista delle priorità; decide cosa fare del backlog (se una storia entra, non entra e con quale priorità). In questo modo fa strategia di prodotto.
Impiegarlo solo per spiegare o scrivere le user stories è di fatto svilire questa figura a un lavoro di segretariato, quando invece il suo vero scopo è capire cosa c’è di valore e come massimizzarlo.

Non possiamo pensare che gli stakeholder si mettano d’accordo sulle priorità perché hanno solitamente interessi troppo diversi. Il team può chiarire autonomamente cosa vuole ottenere lo stakeholder, ma poi è con il PO che ci si confronta sulle priorità.
Non è compito degli sviluppatori, dei designer o degli analisti decidere cosa è più importante e cosa no.

Detto questo vi chiedo: nella vostra esperienza quanta parte del lavoro del PO è focalizzato sulla massimizzazione del valore e quanto sulla scrittura e la chiarificazione? Adesso che sapete qual è l’approccio più produttivo ed efficace avete voglia di condividerlo con i vostri team?