Nella progettazione centrata sull’utente (UCD, User-Centered Design) un passaggio chiave è quello di definire i personaggi (o personas), ovvero degli “utenti tipo” sui quali verrà centrata tutta la progettazione del servizio web. Alla fine del processo, di solito vengono prodotti un paio di personaggi per ogni progetto.
Ora la domanda è: come fanno questi 2 personaggi a rappresentare tutti gli utenti che avrà il mio servizio web? Come posso pensare di progettare un servizio per loro 2, quando in realtà può essere usato da milioni di utenti?
Flow Interactive ha postato a proposito una serie di risposte sensate che mi permetto di evolvere liberamente:
1. i personaggi sono tuttora il modo migliore che abbiamo per rappresentare gli utenti
2. i personaggi aiutano a definire gli utenti limite del sistema
3. non tentare di progettare per tutti gli utenti
In particolare, gli ultimi due punti si legano ad un piccolo sfogo di Stefano sugli utenti medi del web. Il punto è che spesso, nel definire i personaggi del nostro sistema, pensiamo proprio di dover definire l’utente medio, sul quale andiamo a costruire il nostro sistema web. In realtà, si dovrebbe definire un utente particolare, con esigenze particolari.
Faccio un piccolo esempio.
Di recente mi è capitato di vedere dei personaggi inventati di sana pianta. L’errore non è solo nel metodo, perchè di solito i personaggi vengono definiti dopo una fase di ricerca e analisi sul target degli utenti, supportata da attività concrete (interviste, focus group, ecc) (*). L’errore risiede soprattutto nel fatto che se ci inventiamo dei personaggi, inevitabilmente tendiamo a idealizzarli e a immaginarceli perfetti, perlomeno per il ruolo che devono ricoprire nel nostro scenario, nel nostro sito web.
Ma l’utente perfetto non esiste, come non esiste l’utente medio.
Per progettare un servizio web dobbiamo capire soprattutto per chi non stiamo progettando. È un pilastro della strategia: capire prima di tutto cosa non fare, a chi non rivolgersi. Ne consegue che non possiamo progettare per l’utente perfetto, ovvero per l’utente medio, ma dobbiamo invece definire gli utenti particolari del nostro sistema.
Questi utenti particolari hanno delle esigenze che sono evidentemente particolari. Soprattutto, queste esigenze devono combaciare quanto più possibile con i requisiti business. Questi ultimi, devono essere abbastanza circoscritti, altrimenti si ricade nel problema noto come WTGO (“Wannabe the Google of …”).
In conclusione, credo che il processo di definizione dei personaggi parta a monte, mentre si pensa al servizio da realizzare. Definiti i requisiti business, si definiscono di conseguenza i personaggi (gli utenti particolari!) a cui è rivolto il servizio. Questi ultimi non sono una semplice rappresentazione del target utenti, ma sono il prodotto di un’intensa attività di ricerca e analisi.
Mettiamola così: se non lavoriamo con criterio sui nostri personaggi, non stiamo nemmeno lavorando per i nostri 5 milioni di utenti.
(*) Penso che comunque sia una buona pratica immaginarsi i propri utenti, sicuramente meglio del non immaginarseli affatto
Segui i post del blog (feed rss)
10 commenti ↓
Alberto, condivido la tua analisi tranne che per il punto 2, i personaggi aiutano a definire gli utenti limite del sistema, sintesi della Answer 2 pubblicata nel post su Flow Interactive e ti spiego perché. I personaggi sono sviluppati sulla base di oppurtune attività di ricerca (interviste, studi sul campo, ecc.). I risultati di queste attività vengono analizzati per individuare schemi ricorrenti e quindi raggrupparli in modo significativo attraverso una segmentazione. Generalmente la segmentazione viene effettuata per obiettivi, per comportamenti o per modalità d’uso. Alla fine del processo solo da alcuni di questi segmenti verrano sviluppati i personaggi e, come correttamente spieghi, la scelta verrà fatta in base agli obiettivi aziendali. Quindi, i personaggi non possono essere gli utenti limite di un sistema, perché non è detto che siano quelli maggiormente compatibili con gli obiettivi aziendali.
quando parlo di “utenti particolari” definisco proprio i personaggi che escono dall’analisi dei pattern dopo le interviste. per cui siamo daccordo, anche se trovo interessante che si pensi anche al “limite invalicabile” oltre il quale “non far uscire” i personaggi. certo, come dici tu proprio il processo evita che si esca, ma mi piace la metafora utilizzata.
tra l’altro l’autore del post utilizza il termine “edges” che ho liberamente tradotto, ma bisognerebbe capire esattamente cosa intende…
domanda: perché, invece di usare degli utenti immaginari, non usiamo degli utenti veri?
Perché limitarsi alla User Centered Design e non integrarla con un sano design partecipativo?
Risposta 1: il design partecipativo presuppone che un certo numero di persone sia sempre disponibile durante tutto lo sviluppo del progetto e questo può essere un problema. Generalmente lo si si può prevedere nella progettazione di una intranet, dove è facile che lo stesso gruppo di persone possa essere coinvolto.
Risposta 2: si possono coinvolgere persone nel progetto quando si è nella fase di sviluppo, non certo nella fase di ricerca. Questo perché contano di più i comportamenti che le opinioni, che sono la parte più facile da ottenere. Chiunque abbia assistito a un test di usabilità sa che le opinioni espresse non sempre collimano con i comportamenti. Per concludere i personaggi sono estremamente utili nel sintetizzare le ricerche e definire le necessità e gli obiettivi, per poi comunicarli al team di sviluppo e alla committenza. E, comunque, possono essere molto utili nel reperire le persone adatte da coinvolgere nella fase di sviluppo del progetto. In definitiva, l’uso dei personaggi non esclude che da un certo punto in poi si passi al design partecipativo.
Sapreste indicare dei pattern, delle best pratice per identificare i personaggi?
Può essere proficuo sottoporre un’intervista sulle abitudini di navigazione, corredata da domande aperte in cui far sfogare l’utente per cercare di carpirne lo stato d’animo o comunque la sua percezione dei nostri intenti?
tassoman: certo, l’importante è che fai domande più aperte possibile. ricorda anche che nel caso di ricerca sugli utenti bisogna cercare di capire l’utente, non “come viene percepito il vostro sito” (in questo caso è una ricerca marketing). dovete scoprire abitudini d’uso e comportamenti, invece che capire se usano o no una certa funzionalità. più o meno questa è la guideline principale.
Quindi mi sembra di capire che bisogna evitare select, pallini e spunte. Per fare un esempio, una domanda aperta potente potrebbe essere:
“Quando effettui l’accesso alle pagine di XXX, la prima cosa che fai è: … “
Le risposte potrebbero variare da: “controllo se ci sono aggiornamenti” a “clicco ultime news”.
non è semplice darti così 2 consigli su cosa chiedere, dipende molto dal progetto e dall’esperienza. ti direi di approfondire con qualche lettura sui personaggi, altrimenti è un po’ difficile mettere in piedi così su 2 piedi.
in generale, bisogna fare delle domande più aperte, vedi questo thread:
http://www.ixda.org/discuss.php?post=43311
in realtà ho trovato anche questo:
http://www.clickz.com/3628726
dove utilizzano delle domande poco aperte, però ho i miei dubbi che servano veramente allo scopo.
Immagina le motivazioni degli utenti di un e-commerce famoso, che vogliono comprare oggetti status symbol, e crea i relativi personaggi … Ora immagina una intranet della pubblica amministrazione, ed suoi dipendenti che devono completare task piovuti loro dall’alto … Molto probabilmente si tratta degli stessi utenti che incarnano due personaggi diversi…
Bene, ora credo che andrò a rileggere il Manuale del Master di Doungeons & Dragons… XD
[...] presenti, in modo da fornire elementi precisi al team di sviluppo. 23. Costruite una serie di personas sulle quali testare la bontà dei wireframe. 24. Per le applicazioni più importanti, [...]