Partire dall’arrivo
Dopo avere definito gli obiettivi (Nel caso ve lo steste chiedendo, sto parlando dell’articolo di Mariachiara!) è importante capire come raggiungerli.
Prendiamo un cliente che ha definito, come obiettivo principale, che il proprio servizio diventi un canale unico di comunicazione tra vari utenti con ruoli diversi e che la documentazione relativa sia digitalizzata, controllata, approvata e sempre disponibile.
In questo caso si tratta di un servizio già in uso: abbiamo proposto quindi un workshop nel quale – come prima fase – abbiamo mappato, analizzato e verificato il flusso attuale.
Qual è il percorso giusto?
Pensate a un capo spedizione che ha già un itinerario definito per il proprio percorso avventuroso ma che vorrebbe migliorarlo, come può farlo?
Sono presenti vari strumenti a seconda dell’obiettivo e del dettaglio che vogliamo raggiungere, la forbice è ampia: possiamo concentrarci su un singolo utente e su un singolo scenario (es.: l’aggiunta di un articolo al carrello di un ecommerce) oppure intersecare i percorsi completi di tutti gli utenti che dovrebbero usare il nostro servizio (es: la registrazione a un evento fino alla partecipazione).
Service Blueprint
La spedizione è formata da più tappe e ogni tappa ha più passaggi, non gestiti solo dagli avventurieri, quindi il capo spedizione ha bisogno di avere una visione d’insieme di tutto il percorso.
Lo strumento che abbiamo usato è la Service Blueprint, la planimetria completa del servizio al di sopra e al di sotto della linea di visibilità.
Per semplificare:
- sopra la linea di visibilità = cosa vede l’utente
- sotto la linea di visibilità = cosa fa il sistema senza che l’utente se ne accorga
Perché la Service Blueprint?
Perché stiamo mappando un servizio esistente che può aiutare gli stakeholder a prendere coscienza del proprio flusso, mettendo a terra tutti i passaggi presenti senza dare per scontato nulla.
Cos’è una Service Blueprint quindi?
Si tratta di un diagramma che mostra l’intero processo del servizio, elencando tutte le attività che si verificano in ogni fase, eseguite dai diversi utenti coinvolti.
Chi partecipa al viaggio?
Qualcuno partirà dalla sede principale, qualcun altro salirà sull’aereo o su una nave in una tappa intermedia, qualcuno invece attenderà al capolinea…
Dove prendiamo gli utenti?
Bisogna prima di tutto elencare gli utenti coinvolti nel processo: l’attività che abbiamo svolto insieme ai partecipanti del workshop (se non riusciamo a intervistare direttamente l’utente che utilizza il servizio) è la creazione di proto-personas.
Il capo spedizione non ha a disposizione una guida, quindi prova a immedesimarsi e cercare da solo la strada…
Queste proto-personas sono basate sugli utenti attuali del servizio ma sono personaggi grezzi e fittizi, elaborati insieme agli stakeholder, che prenderanno parte al nostro flusso. Si tratta di personaggi provvisori, non completi, che ci permettono però di definire alcune caratteristiche come l’età, la fruizione della tecnologia (a che livello e con che tipo di device, ad esempio), la necessità di avere dei promemoria, quali sono le preoccupazioni durante l’utilizzo del servizio.
Si parte!
La nostra mappa dovrà contenere ogni itinerario di ogni avventuriero, guida, autista o spedizioniere.
Possiamo quindi cominciare a costruire la Service Blueprint elencando gli utenti coinvolti su un asse verticale e tutti i passaggi necessari per fornire il servizio sull’asse orizzontale in ordine temporale.
La matrice risultante permette di rappresentare il flusso di azioni che ogni ruolo deve compiere lungo il processo, evidenziando quelle che l’utente può vedere (sopra la linea di visibilità) e quelle che avvengono a sistema (sotto la linea di visibilità).
Troveremo quindi dei punti di contatto tra vari ruoli e sicuramente ci saranno dei momenti in cui nessuno farà domande ma… Ehi! Qualcuno avrà pur portato quella cassa nella foresta, come ci è arrivata?
In questo modo possiamo capire i rapporti cross-funzionali tra utenti e sistema ed evidenziare gain e pain point in relazione al nostro obiettivo.
Come abbiamo svolto questa attività?
Io, Mariachiara e Emanuele abbiamo fatto da moderatori durante il workshop: sono state create le proto-personas nella prima parte della mattinata e, nel resto della giornata è stato esposto il flusso attuale, discusso in ogni singolo passaggio, e successivamente arricchito dagli spunti emersi durante la presentazione.
Fondamentale per noi svolgere queste attività in presenza: anche da remoto è possibile ma dal vivo i partecipanti sono meno distratti e maggiormente coinvolti nella discussione.
Abbiamo diviso i partecipanti in gruppi e ogni gruppo ha rappresentato un utente del sistema: a questo punto si sono verificati dibattiti a ogni passaggio.
A questo punto è chiaro che non c’è quindi un singolo capo ma un consiglio riunito che non dovrà solo osservare la mappa ma viverla, come se fossero gli avventurieri stessi, le guide, gli autisti o gli spedizionieri.
Sono emerse considerazioni che hanno stupito gli interlocutori: convinti che alcuni punti si svolgessero in una certa sequenza o in modo differente rispetto dell’attuale funzionamento.
Uno dei consiglieri è certo che ci sia un ponte in legno che attraversa un fiume, mentre gli esploratori hanno sempre usato una liana per passare da una riva all’altra.
L’attività di mappatura che è stata svolta ha portato alla luce varie criticità che sono state confermate dagli stakeholder e che abbiamo potuto trasformare insieme in opportunità di miglioramento direttamente durante l’attività di co-design.
Un altro dei consiglieri, a questo punto suggerisce di costruire questo ponte ma gli viene detto da un altro ancora che se gli esploratori hanno sempre usato una liana forse è meglio lasciare la liana.
Ma non è detto che tutti siano favorevoli al cambiamento…
Qual è stato l’output?
Il consiglio sa che ci vorrà tempo prima di ottimizzare tutto ma ora ha una visione d’insieme sulla quale riflettere per poi intervenire
Consapevolezza dello stato attuale del servizio, un elenco di funzionalità che possono essere trasformate in priorità e che possono essere sviluppate con diversi livelli di effort a seconda delle strategie di business.
Conclusioni
Alla fine della giornata di workshop è stato chiaro per il cliente che il design non è solo una serie di schermate ma è progettazione e analisi.
L’analisi è fondamentale per trovare un terreno comune sul quale cominciare a costruire (o ricostruire) qualcosa: spesso il cliente pensa a come funziona il proprio servizio ma non sa esattamente come e quando vengono svolte determinate azioni.
Mettendoci nei panni di chi userà il servizio e non vestendo solo i panni di designer, sviluppatori, manager o responsabili possiamo fare un passo ulteriore verso l’utente, che è al centro dell’esperienza.
Nel frattempo, l’avventuriero continua a cercare…
