In questo secondo articolo della serie dedicata alla prototipazione della UX con Mean.io, affrontiamo diversi argomenti ‘teorici’ ma molto importanti per la realizzazione di una buona esperienza utente. Tra questi, lo strumento delle Personas e le cosidette Job Stories.

Progettazione e prototipazione

Il secondo appuntamento dedicato alla Prototipazione UX è un capitolo poco “smanettone” e un tantino “accademico”: ci occuperemo un poco di teoria, ma soprattutto getteremo le basi per tutto quello che servirà nel prossimo articolo per tuffarci a testa bassa nell’implementazione del nostro prototipo.

“La progettazione è una parte fondamentale del processo di prototipazione“.

Sembra un controsenso e ci si aspetterebbe che, lavorando con i prototipi, la fase di progettazione venga ridotta al minimo, soprattutto per ottimizzare tempo e risorse al fine di poterle investire nel processo di apprendimento e conoscenza del cliente.

Questo ragionamento è assolutamente corretto: il processo di customer development  descritto da Steve Blank in “The Four Steps of Epiphany” è quello che stiamo cercando di ripercorrere. ln termini differenti è la medesima metodologia descritta da Eric Reis in “Lean Startup” e ripreso da Jeff Gothelf in “Lean UX”.

Figura 1 – I quattro passi per lo “sviluppo del cliente”. Il cliente è, anzitutto, un utente del nostro servizio.

La progettazione che vogliamo effettuare non riguarda la progettazione implicita del servizio e, di conseguenza, del prototipo: noi vogliamo progettare l’infrastruttura che ci servirà per capire effettivamente il nostro cliente, che è, prima di tutto, un utente del nostro servizio e, cosa ancor più importante, una persona.

Miriamo quindi a definire i requisiti interni del prototipo non in termini funzionali, ma in termini di raison d’être, e gli obiettivi di apprendimento che vogliamo andare a tracciare per convalidare le nostre assunzioni e raccogliere risultati che ci aiutino a crearne di nuove.

Dove ci eravamo lasciati

Vi ricordate cosa ci accingevamo a progettare? Giusto per rinfrescarvi la memoria vi rammento il pitch dal quale partiremo:

EINKAUFSLISTE – La lista della spesa per chi comanda

Ovvero, una lista della spesa per famiglie o gruppi organizzati che, a differenza delle liste della spesa tradizionali, personali e poco condivisibili, possa essere inviata a un destinatario preciso con cui collaborare.

La mission

Costruire un prototipo veloce veloce, usando il framework MEAN.io e infarcirlo di tutto quello che ci serve per riuscire a rispondere a poche e semplici domande:

• esiste un mercato, esiste qualcuno che abbia un bisogno insoddisfatto e sarebbe disposto a pagare per una possibile soluzione?
• se questa persona esistesse, quale necessità avrebbe?
• data una possibile soluzione,  cosa funzionerebbe e cosa no?

Per trovare una risposta concreta a queste domande, dobbiamo prototipare e osservare come si comporteranno le persone e che tipo di interazione instaureranno… e dobbiamo farlo al costo minore e con la metodologia migliore.

Lo strumento Personas

Fra tutti gli strumenti utilizzati nel processo di progettazione dell’esperienza e nel design, i Personas (il plurale “Personas” è basato sull’inglese, in opposizione al latino “Personae”) sono un consistente comun denominatore, anche in contesti Agile o Lean UX dove la produzione di deliverable di documentazione è ridotta al minimo. Quando parliamo di Lean UX, ci riferiamo a un User Centered Design declinato per il contesto Lean Startup, vale a dire Customer Development accoppiato ad approcci Lean/Agile, caratterizzati da iterazioni veloci di cicli di creazione, feedback e validazione.

I Personas costituiscono un campionario di personaggi fittizi, costruiti dall’unione di categorie salienti di persone reali e definiti nei minimi dettagli, con tanto di foto, nome, cognome, età, descrizione fisica, lavoro, hobbies e soprattutto obiettivi ben specificati e durevoli nel tempo (diversamente dai task).

Jenkinson e il concetto di User Personas

Lo strumento degli User Personas ha origine nel settore del marketing, come modalità di categorizzazione dei clienti, inizialmente operata da Angus Jenkinson. Jenkinson desiderava uno strumento che potesse classificare i clienti (customers), che andasse oltre alla segmentazione tradizionale basata su indici demografici. Lo scopo di Jenkinson era di ottenere un livello di conoscenza molto più profondo dei propri clienti che riguardasse la loro vita quotidiana, i loro bisogni e desideri.

Nella sua pubblicazione “Beyon segmentation” (1993-1994), Jenkinson chiamò questo strumento Customer Prints e facilitò così la transizione a un nuovo modello di pensiero che vedeva il cliente evolversi da “individuo di classe o tipo”, inteso come “essere qualcosa”, a individuo complesso caratterizzato dall'”avere delle caratteristiche comuni e condivisibili”. Persone di astrazione differente potevano quindi agire e comportarsi in maniera simile se spinti dalle medesime pulsioni.

Si tratta di una categorizzazione proveniente dal basso, una delle basi su cui poggiano i principi delle personas moderne: essere sempre basate sulle persone vere, sui loro bisogni, sulle loro necessità.

Cooper e la metodologia basata su Personas

Parallelamente alla creazione di Jenkinson, Alan Cooper stava lavorando nello stesso periodo a un concetto similare che egli denominò, casualmente, proprio User Personas e che descrisse dettagliatamente nel suo libro “The inmates are running the asylum”.

Per Cooper, Personas sono ipotetici archetipi di utenti reali, definiti dai loro obiettivi e, a loro volta, gli obiettivi aiutano a definire le Personas. La metodologia di progettazione creata e formalizzata da Cooper aveva come primissima fase l’investigazione del dominio del problema e definiva, già allora, molte delle best practice che tutt’oggi vengono applicate.

Personas e design incentrato sugli utenti

Sebbene le modalità con le quali creiamo questi Personas siano cambiate nel tempo, essi sono e rimangono gli strumenti principali dello User Centered Design, il “design basato sugli utenti”, descritto in chiave moderna da Donald Norman, che viene ritenuto il processo dominante per lo sviluppo software.

Figura 2 – I Personas sono uno strumento importante per il design incentrato sull’utente.

Utilizzare i Personas sin dai primi momenti del progetto è il segreto per creare strategie in grado di influenzare tutto il processo creativo e produttivo, permettendo così di gettare le fondamenta per la definizione di una migliore esperienza utente e, nel nostro caso, delle assunzioni migliori.

La ragione principale per creare Personas è quella si stabilire un set di comune conoscenza dell’utente finale, affinchè si possa creare una strategia coerente e comune, mirata a soddisfare, con il prodotto/servizio, obiettivi che siano user-oriented.

Alla base del processo, vi è la necessità di restare sempre allineati con le aspettative e i bisogni dell’utente, nonostante il procedere disaggregato dei lavori e i ritmi concitati che potrebbero facilitare la perdita di vista dell’obiettivo principale.

L’utilità dei personas nel processo di design

Sostanzialmente un Persona è costituito dalla stereotipizzazione di alcuni profili specifici di utenti di potenziale interesse per il progetto, così vivi e reali da consentirci di avere davanti l’utente per cui vogliamo progettare e i suoi reali bisogni e obiettivi sia quotidiani, che di medio e lungo periodo

I Personas sono molto “utili” a superare la cosiddetta sindrome di Malkovich, cioè la tendenza a credere che tutti vogliano interagire con il nostro servizio come lo faremmo noi, e per aiutarci a capire che il progettista non è l’utente reale, anche perchè l’utente reale non è uno e nella definizione del servizio è cruciale decidere per chi progettare.

A partire dai personas sarà infatti possibile identificare alcuni scenari d’uso tipici del servizio in progettazione e descrivere in modo preciso come ciascun Persona potrebbe usare il servizio/prodotto per raggiungere i suoi obiettivi, soddisfare i suoi bisogni, e anche provare emozioni.

Caratteristiche e differenze con altri strumenti

La letteratura sui Personas è veramente estensiva: i Personas devono essere considerati guide di progetto e sono/devono essere tracciabili sin dalle primissime fasi di design. Essi possono essere delineati a partire da dati reali ed essere privi di qualsiasi livello di interpretazione; altre volte sono semplicemente “profili”, figure o stereotipi: hanno sì tratti distinguibili e concreti, ma sono stati creati in parte a tavolino, basandosi su intuizioni e assunzioni che dovranno essere comunque validate sul campo.

La differenza principale fra un Persona, un profilo, un archetipo, uno stereotipo e un target demografico risiede rapporto fra dati e informazioni reali e fittizie, e nella quantità di informazioni contestuali che si possono utilizzare nell’arricchire emotivamente ed empaticamente la figura. Maggiori saranno i dati contestuali capaci di modellare un profilo credibile/reale, maggiore sarà la credibilità del contesto e l’empatia che questi Personas saranno in grado di generare.

I Personas non sono documenti “finali”, ossia il frutto finale di una elaborazione: tutt’altro! Essi sono un distillato che deriva dall’analisi approfondita dell’utente; essi rappresentano il punto di ingresso per costruire le funzionalità del servizio.

In questo contesto non possiamo dedicarci ad una fase di analisi approfondita, perchè la tempestività con il quale vogliamo sondare direttamente il mercato è un fattore critico di successo.

Proto-Personas

A volte i Personas non sono generati interamente da dati esclusivamente reali ma, per ragioni di praticità e velocità, sono un mix di dati reali e informazioni artificiali: in tal caso, si parla più propriamente di proto-Personas (concetto intrododotto dal già citato Gothelf  in “Lean UX”). Sorge quindi un dubbio lecito: quanto è affidabile questo strumento, se alcuni aspetti sono stati disegnati a tavolino?

A. Cooper, la figura che ha introdotto l’uso dei Personas in ambito progettuale, ha definito i Personas come un paletto da campeggio: pochi paletti, molto ben definiti, verticali e precisi che vanno piantati sul dominio a una certa distanza. Su ognuno di questi paletti si estenderà la “tenda” delle figure potenzialmente assimilabili e direttamente simili, che andrà a coprire lo spazio circoscritto con una estensione tanto grande quanto è alto il nostro paletto.

Ma perchè lavoriamo con una base “artificiale”? Perchè durante la fase iniziale, un bilancio fra costi e rapidità è essenziale: è essenziale poter partire il prima possibile per poter avere una base iniziale di lavoro sufficientemente buona, non certamente perfetta, che ci porti a poter testare le nostre supposizioni il prima possibile. Solo allora avremo la possibilità di reiterare l’analisi, confermando eventualmente certe assunzioni e correggendo quello che è incongruente con la realtà.

“Interrogare” i Personas

I Personas sono strumenti di design che servono a impostare dubbi di progettazione nella forma:

“Cosa farebbe %NOME_PERSONA% in questo momento? Di cosa avrebbe bisogno adesso? Sarebbe in grado di comprendere questo passaggio?”

Con questo semplice esercizio di design, ci si sforza a guardare quello che si sta sviluppando con occhi differenti: gli occhi dell’utente, specialmente quando questo sembra talmente ovvio e scontato che, di fatto, lo dimentichiamo.

Nel nostro caso, i Personas generati per Einkaufsliste sono due, ossia un “produttore” e un “consumatore“.

Figura 3 – Ecco un esempio di Personas, che potremo usare per la nostra Einkaufsliste.

I tratti che contraddistinguono i Personas

Non esiste un formato standard per la descrizione di un Persona. Esistono profili estremamente ricchi e dettagliati, pieni di “narrazione”, oppure descrizioni minimaliste come questa adottata. Trattandosi di proto-Personas, quindi di assunzioni, avere una ricca descrizione totalmente fittizia, in realtà non aggiunge nulla se non il rischio di lasciarsi trasportare troppo dall’immaginazione e deragliare su binari fantasiosi.

Scegliamo di utilizzare qui il set di informazioni minime per essere comunicativi: nome, età, professione, un indicatore generico per competenze/comportamento, una lista di pain points (criticità) che affliggono quel Persona e una serie di gain points  che rappresentano credo, punti di vista o aspetti positivi del Persona.

Completano la descrizione delle Personas una frase caratteristica (quote) e una brand board, ossia un insieme di marchi che, sulla base della loro comunicazione e del loro posizionamento, possa a colpo d’occhio rendere l’idea del suo modo di agire e/o pensare.

Vediamo quindi i proto-Personas che abbiamo creato, con le loro caratteristiche.

Chi sono Jonathan e Marie?

Jonathan e Marie sono una coppia: lui è una persona molto attiva e tecnologicamente competente, mentre lei è meno avvezza alle tecnologie, molto sociale e attenta nello shopping.

Jonathan è spesso in giro per lavoro perchè è responsabile per alcuni cantieri distribuiti sul territorio e capita spesso che, tornando a casa la sera, sia lui a fermarsi al supermercato a fare la spesa settimanale.

Marie è quella più attenta agli acquisiti, avendo la cultura del magiare sano, mentre Jonathan è più incline alla “sopravvivenza”. Per questa ragione Marie lascia la lista della spesa sul tavolo alla mattina, ma Jonathan puntualmente la dimentica a casa. Se Marie non si ricorda di chiamare Jonathan e ricordargli cosa prendere, dovrà accontentarsi di mangiare junk food; e, se Jonathan non si ricorda di chiamare Marie, sa che facendo di testa sua a casa lo aspetterà un rimprovero.

Fortunatamente con Einkaufsliste, Marie può inviare e condividere con Jonathan la lista della spesa, mentre lui è al lavoro: Marie crea la lista durante la giornata, la invia nel pomeriggio a Jonathan e può farsela “approvare”. Anche quando lui non è raggiungibile, Marie può aggiornarla e inviarla, cosicchè entrambi siano sempre allineati.

Grazie ai nostri Personas, abbiamo appena creato uno scenario.

Scenari e user story

Scenari e user stories rappresentano un “reality check” per il progetto: ci permettono di “vedere” il servizio progettato all’interno di un ambiente credibile, e quindi, potenzialmente, aiutano a stimolare l’immaginazione a visualizzare le interazioni che saranno necessarie nel contesto immaginato.

Scenario

Lo scenario, seppur fittizio e/o immaginato, deve essere quantomeno verosimile e teoricamente possibile. Solo con questa premessa lo scenario permette di delineare, trovare o eliminare dei punti di contatto fra utente e applicazione/servizio che non siano banali.

Il proto-Scenario è uno scenario abbastanza specifico tale da essere calato agilmente nei proto-Personas che abbiamo generato, ma contemporaneamente deve essere sufficientemente generico e vago da non bloccare l’immaginazione di chi lo interpreta, creando quindi dialogo, punti di discussione e spunti di progettazione.

Via via che l’analisi diventa più profonda, gli scenari possono a loro volta diventare sempre più precisi e dettagliati, andando ad aggiungere particolarità sempre più definite raccolte con gli User Test. Dallo scenario principale che può essere paragonato ad una storia raccontata in maniera visuale, a monte dello sviluppo si possono distillare User Story,

User stories

Le User Stories sono delle piccole carte funzionali nella forma: “in qualità di X, vorrei fare Y per ottenere il risultato Z“.

Le User Story rappresentano microstorie, legate in maniera molto stretta alle funzionalità che si vogliono offrire, di fatto spesso utilizzate nei processi Agili come TO DO a livello di requisito aspirazionale.

Generalmente, una User Story è un requisito di business riformulato usando gli occhi dell’utente e reso “aperto” a diverse declinazioni.

Il processo di “distillazione” delle informazioni

Personas e User Stories / Scenarios sono normalmente utilizzati quando i team di prodotto e gli utenti finali hanno un basso grado di interazione. Creiamo quindi dei modelli surrogati che ci permettano di proseguire nello sviluppo senza perdere di vista i requisiti esperienziali iniziali e sostituirli esclusivamente con quelli di business.

Tradizionalmente, questo processo porta raccogliere le informazioni e distillarle in qualcosa di più pratico e portabile, privo di tutte quelle conoscenze tacite che il team ha sviluppato durante il progetto e che rappresentano una sorta di conoscenza interna e un ricordo empatico comune che non è necessario ricomunicare ogni volta.

Essendo un processo di distillazione, andiamo a perdere tre importanti aspetti che sono difficilmente riportati: causalità, ansia e motivazioni.

La filosofia di concentrarsi su questi tre aspetti è denominata metodologia “Jobs to be done” o “agenda scenari narrativi” e rappresenta un modo granulare di riportare questi elementi e reinserirli nel processo UX.

Le Job Stories

Per quanto utilissimi, una User Story e uno User Scenario non sono sufficienti a descrivere la complessità di una situazione, in quanto:

• utilizzando Personas hanno intrinsecamente un certo grado di supposizione e, mai, la certezza;
• creano un legame diretto fra motivazione e risultato;
• ignorano il contesto, la situazione e lo stato emozionale dell’utente.

Figura 4 – La Job Story completa le informazioni fornite da User Story e User Scenario.

Una Job Story, copre queste mancanze e completa la visione progettuale con una dimensione in più: è un documento che riformula la storia, incentrandosi sull’attività pura (il job), e tende quindi a slegare la parte “emozionale” facendola diventare “contestuale”.

Invertendo il punto di vista, stiamo slegando il risultato atteso (ossia la mera soluzione progettuale) dalla motivazione caratteriale e la leghiamo alla coppia “motivazione – situazione”, tracciando così un “recinto di validità”.

Figura 5 – Un’ulteriore rappresentazione della Job Story.

Questo ci permette di avere la libertà progettare (pensare) tutte le N soluzioni che soddisfano questa tripla e filtrare fino a trovare la migliore, utilizzando, successivamente, la lente interpretativa dei nostri Personas / Scenario. Aggiungendo questo tassello, abbiamo reso il processo UX molto più modulare e flessibile e meno prono a sbilanciamenti valutativi personali derivanti da assunzioni non veritiere.

Alla nuda motivazione, ad ogni storia sono state aggiunte anche delle cosiddette forze, ossia tratti caratterizzanti che “spingono” o “tirano” le motivazioni verso specifici aspetti. Le forze possono essere considerate come modificatori di ambiente. La tabella delle storie generate per Einkaufsliste contiene semplicemente tre storie, a ognuna delle quali sono associate tre “forze”.

Figura 6 – Ecco la tabella delle tre Job Stories generate.

Come si legge la Job Story?

La Job Story deve essere letta con gli occhi di Jonathan e Marie in maniera semplice e lineare per ottenere una storia, ad esempio:

“Quando il suo compagno esce per fare la spesa e a Marie sovviene qualcosa da aggiungere alla lista, Marie vuole poter comunicare al marito le cose da aggiungere senza doverlo chiamare cosicchè possa fare mente locale via via, senza l’ansia di ricordarsi tutto in un unico istante.”

Come potete vedere, la storia prende la forma molto simile a quella che sarebbe una storia nel contesto agile, con la stessa variabilità di risoluzione, ma con una particolare caratteristica che rende lo strumento quantomeno interessante: la resilienza.

La storia è formulata in maniera tale che si possa leggere anche con gli occhi di un altro Persona, mantenendo la struttura di base intatta, ma conferendo una declinazione totalmente differente.

La stessa storia, per un Persona tecnologicamente evoluto potrebbe essere risolta con una differente gamma di soluzioni di design. Ad ogni singola storia può essere applicata una “forza” e la nuova combinazione genera un nuovo scenario con un diverso set di variabili.

Ad esempio, una “forza” che reciti “sono di fretta”, applicata a una storia fa sorgere dubbi che si possono tramutare in nuovi requisiti interni di progetto:

• sono di fretta?
• forse sono in metropolitana?
• in un luogo pubblico?
• non ho la precisione di fare scelte precise in movimento?
• è un dispositivo mobile con uno schermo di piccole dimensioni?

In definitiva, la storia non è più un obiettivo singolo, ma un perno sul quale si può costruire una matrice di N obiettivi associati a triple di Personas + Job + forza.

La mappa di navigazione

Tutti questi elementi possoo essere messi insieme cominciando con una mappa di navigazione dell’applicazione, ragionata, ma senza particolari accorgimenti. La potete disegnare su carta oppure usare uno strumento digitale agile che vi permetta di essere veloci ed espressivi, come Balsamiq Mockup, Microsoft Powerpoint, Apple Keynote, Omnicorp Omnigraffle o, il mio preferito da qualce mese a questa parte, Bohemian Coding Sketch.

Figura 7 – Si può disegnare la mappa di navigazione anche con carta e penna.

Essendo la lista della spesa non più che una gestione di CRUD, siamo partiti dalle viste di creazione, visualizzazione e modifica. Ora che c’è una prima bozza di navigazione, la si percorre seguendo, via via, le Job Stories, prima in maniera neutrale, poi con gli occhi dei Personas associati e, infine, applicando una a una le “forze”.

Iteriamo il processo, aggiungendo soluzioni di design che soddisfino, volta per volta, la singola storia. “Marie deve operare in mobilità”? Forse sarebbe meglio ridurre il data entry, inserendo dei quick tag. “Jonathan è di fretta”? Forse eliminare il menu in favore di icone grandi potrebbe aiutare. E così via: iteriamo fino a che siamo soddisfatti e finalizziamo la mappa di navigazione.

Figura 8 – Il passaggio successivo sarà passare dalla mappa di navigazione alle viste, ma per questo c’è tempo e ne parleremo nel prossimo articolo.

Non attendiamo che sia perfetta: non lo sarà mai… raggiungiamo invece uno stato stabile e fermiamoci: ci penserà il test del prototipo a evidenziare le problematiche e anche la loro possibile soluzione.

Conclusioni

In questo articolo abbiamo analizzato dei principi e degli strumenti relativi alla progettazione Lean UX: in particolare abbiamo visto Personas, User Stories, Scenari, Job Stories e mappe di navigazione. Si tratta di strumenti potenti che, usati nel modo opportuno, ben si adattano a una prototipazione rapida ma accurata ed efficace, consentendo di verificare la validità del nostro prodotto/servizio in maniera orientata all’utente.

Non male eh? È tempo di creare un wireframe veloce delle viste per avere una chiara idea di come implementarle… Ma tutto questo nel prossimo articolo!