Oggi Chris e Teresa (senza Nikki, impegnata su altri fronti) ci aspettavano al varco su questi due temi: persona e scenario, i due cavalli di battagli di Cooper.
Abbiamo dedicato 4 ore (dalle 9 alle 12 e dalle 13 alle 14) alle personas e altre 3 agli scenari (dalle 14 alle 17).
Ieri abbiamo chiuso la giornata con la nostra prima intervista a un possibile utente della mobile app per Photo Star. Come compito a casa ci hanno detto di leggerci le altre 4 interviste che avevano preparato preventivamente, così abbiamo potuto confrontarle con le domande fatte da noi.
Oggi abbiamo cominciato a lavorare subito revisionando le interviste.

Il compito di revisione consiste in questo: da soli, 30 minuti, individuare le azioni principali compiute degli intervistati e per ogni azione abbinare le n attività relative. Questa procedura permette di creare i primi cluster di attività fatte dagli utenti, facendo emergere i pattern più frequenti o comuni. Dopodiché, in pair, abbiamo unificato i cluster, cosa che ci ha evitato di perderci qualcosa per strada. L’ultima cosa che abbiamo dovuto fare è stata descrivere la situazione che vedevamo in frasi compiute.

Tutti questi esercizi derivati dalla revisione delle interviste sono serviti a fare un zoom out dalla situazione specifica raccontata dall’intervistato alla situazione generale. Così, avvicinando i pattern simili e descrivendo esplicitamente la situazione, abbiamo fissato le basi e il territorio entro cui creare le nostre personas.
A questo punto, Chris ci ha spiegato che cosa sono le personas (in due parole: archetipi che rappresentano i pattern individuati), come e quante crearne, persone primarie e secondarie, come presentarle al team e come usarle.
Nella mezz’ora di tempo che ci hanno assegnato, abbiamo creato questa prima bozza di profilo per Ellen, con la sua storia, i suoi obiettivi e le sue caratteristiche.

E poi abbiamo dovuto presentarla agli altri, come se fosse una persona vera. Tutte le presentazioni hanno un senso all’interno del progetto: per le personas, presentarle al team significa ricordare che stiamo lavorando per loro e abituare il team a vederle come loro utenti di riferimento.
Creare un personaggio ti fa sentire un po’ come uno scrittore. È stato piuttosto divertente, perché devi farlo all’interno dei paletti che ti sei dato grazie alla revisione delle interviste, ma puoi anche sbizzarrirti con dettagli di vario tipo sulla sua personalità, il tipo di vita che fa, le sue passioni, le frasi che direbbe ecc. Ho solo avuto la sensazione di essere troppo arbitraria o libera in alcune scelte, ma forse è un limite del mio modo analitico di progettare.

Siamo poi passati agli scenari, che servono a individuare i comportamenti delle personas nel conseguimento dei loro obiettivi, a prioritizzare e a condurre la ux senza perdersi in dettagli di funzionamento. Non sono ancora accompagnati da schizzi e wireframe (mi aspetto di affrontarli domani).
Per individuare uno scenario, abbiamo scelto uno degli obiettivi associati alla nostra Ellen (organizzare / categorizzare). Abbiamo poi analizzato i vari aspetti da tenere in conto per il conseguimento dell’obiettivo: attività che fa oggi l’utente (senza il nostro prodotto), problemi che incontra, vincoli imposti dal sistema e bisogni emergenti. Questi ultimi sono le opportunità che l’app potrebbe cogliere.

Abbiamo scelto uno dei bisogni emergenti (Ellen vuole aggiungere informazioni ai suoi scatti e vuole farlo in qualunque momento sulle foto originali, senza creare duplicati) e lo abbiamo descritto con uno schematicissimo storyboard suddiviso in momenti chiave. Come per le personas, la scelta di produrre una rappresentazione visiva di questi momenti chiave (senza perdersi in dettagli funzionali o disegni artistici) serve a facilitare la spiegazione dell’opportunità al team e a ragionare dal punto di vista dell’utente e dei suoi bisogni.

Devo dire che lavorando sugli scenari abbiamo perso troppo tempo in esercizi propedeutici al disegno, ma visto che siamo una classe mista e che tutti dovevano disegnare, posso capire. Abbiamo anche perso tempo a rimescolare le squadre, in Cooper hanno decisamente la fissa di lavorare in pair e cambiare spesso collega di lavoro, per evitare che il gruppo si fossilizzi su un’idea. Io avrei preferito di più avere un feedback sullo “splendido” storyboard prodotto, ma il tempo per oggi era finito.

Tutti gli esercizi fatti oggi possono sembrare dei giochini anche un po’ naïf. Invece, grazie a questi deliverables, procrastiniamo le decisioni di design finché non abbiamo individuato e discusso gli obiettivi degli utenti, senza lanciarci in proposte di ux o ui infondate oppure basate su cose che abbiamo già visto. La mia impressione è che in questo modo riusciamo a portare innovazione e a creare un qualcosa che davvero possa risolvere alcuni problemi degli utenti, e che quindi il prodotto possa essere desiderabile e utile.
Sono a metà corso, e già inizio a chiedermi quante di queste cose riuscirò a introdurre e proporre quando rientrerò. Forse potrò sceglierne qualcuna, in base al progetto e al budget?
E comunque ho pronta la domandona da fare domani a fine giornata oppure a fine corso: come posso introdurre questi deliverables in un flusso agile? Per esempio: c’è una relazione tra gli scenari e le epic stories? O tra le personas e gli utenti associati a una user story? Qualcosa posso immaginare, ma voglio sentire cosa mi diranno qui.

Dimenticavo: in due giorni ho raccolto 5 consigli di lettura. Mi segno solo i due che potrebbero interessarmi:

• Inmates are running the Asylum – Alan Cooper
• The user is always right – Steve Mulder