Per poter accogliere mappa, definire i requisiti di un prodotto digitale.

Ci sono tantissimi metodi e processi che in realtà si possono mettere in pratica.

Quello che vedremo noi da applicare poi in una versione un po' più semplificata e anche più accessibile a chi non ha competenze troppo tecniche è chiamato user story mapping.

Um diciamo prima di di parlare di questo metodo, vediamo un po' la storia di questa metodologia che è stata identificata o, se vogliamo, inventata circa nel duemilaotto da Jeff Patton, un informatico americano molto attivo nel contesto, JL, che descrive questo processo come una sorta di conversazione tra più persone coinvolte da tecnici fino anche ai clienti per capire cosa vogliono ottenere, cosa bisogna fare e con quale priorità, andando a mappare una sorta di panoramica di tutti quei passaggi necessari per raggiungere un obiettivo.

Durante questa conversazione che vede coinvolte le persone del progetto um diciamo è è è necessario far partecipare più personalità diverse con competenze diverse al fine di avere il punto di vista di ci di ciascun dipartimento.

E in questa in questa conversazione approfondisce appunto il punto di vista del potenziale utente fruitore del prodotto o del servizio in tutti quelli che sono i passaggi che lo portano da un punto zero fino a quello che è l'obiettivo che può essere uno o più di uno, cercando di raccontare e mappare e quindi in qualche modo individuare questi passaggi in un ordine di attività quanto più logico e consequenziale possibile.

Questo processo avviene di norma con un'attività di co- design o copartecipazione tramite un laboratorio, una riunione, un workshop e che viene chiamato normalmente il momento di raccolta di requisiti e utilizzando appunto la tecnica dello user serie mapping e e tutta una serie di pratiche che vedremo in questo corso e ad esempio, un workshop di questo tipo prevede alcuni passaggi chiaramente um l'abbiamo già detto, ma ripeto, quello che va fatto è che si coinvolgono e devono essere coinvolte e invitate appunto a partecipare tutte quelle persone e quelle professionalità che possono dare un contributo importante per il progetto stesso.

Di norma sono presenti sia il cliente che i suoi collaboratori, ma anche di norma, persona tecnica come il CTO, chi si occupa di marketing e di comunicazione, chi si occupa di design di UX, chi fa più prodotto e in alcuni casi potrebbero partecipare anche ad esempio i responsabili char customer care o altre figure chiave che, a seconda del tipo di progetto, di prodotto o di servizio che si sta mappando, possono essere interessate a portare il loro contributo.

La seconda cosa è che si raccolgono poi tutti i materiali relativi al contesto, le persone se gli obiettivi, tutto quello che insomma c'è come base di partenza, che serve in qualche modo ad avere un quadro chiaro di progetto, oltre che a chiarire anche qual è l'obiettivo che si vuole raggiungere.

E diciamo, è buona norma condividere tutto questo con il gruppo che parteciperà alla conversazione all'attività prima del momento.

Insomma, di questa attività per permettere alle persone di arrivare aggiornate e sul pezzo rispetto a quello che va fatto.

E poi si prende una stanza che sia fisica o virtuale, anche se devo dire che um dal vivo la resa in generale la partecipazione è spesso maggiore se c'è una persona che sa facilitare e tenere.

Insomma, le persone anche attive e coinvolte si co-, forniscono dei post-it.

E chiaramente nel caso della versione virtuale e ci sono i post-it digitali.

E si comincia questa attività insieme che anche dal vivo, ma soprattutto anche da da, diciamo da digitale e da remoto, è bene farla anche in più sessioni in più momenti, per permettere anche di digerire e di metabolizzare alcuni processi e dei dei concetti che spesso poi richiedono un po' di tempo per posarsi prima di poterli rivedere, approfondire e concludere al meglio um attività e che che consiste in che cosa e quindi questo workshop, come come funziona? Che cosa si fa all'interno di questa attività di design tramite il dialogo e il confronto e sulla base di quelle che sono tutte le informazioni di progetto, gli obiettivi e tutto quello che abbiamo raccolto? Il team inizia a posizionare letteralmente dei post-it nello spazio condiviso con informazioni, categorie e dettagli rispetto a quelle che sono le funzionalità di un prodotto o di un progetto digitale.

Um l'attività dello user story mapping non è molto complicata da realizzare e ha tre livelli di profondità e a seconda poi del motivo per cui ti troverai a dover definire i requisiti, potrai decidere di soffermarti ai primi due livelli che sono un po' più di alto livello e quindi di meno dettaglio, oppure di scendere un po' più in profondità fino al terzo livello e quindi con maggior dettaglio e maggior definizione a tutti gli effetti.

Il primo livello vede dei post-it che vengono chiamati epic se consideriamo il nome da letteratura, ma per semplificare potremmo chiamarli attività.

Questo primo strato, diciamo di informazioni, rappresenta delle macrocategorie macro categorie funzionali di quelle che sono le attività principali che ci aspettiamo che l'utente del prodotto eh o insomma del prodotto digitale possa effettuare.

E ad esempio, ti potrei dire che um rispetto a un esempio di un e-commerce c'è la sezione del catalogo c'è, la gestione dei prodotti, la gestione dei pagamenti, gli ordini e l'account quindi un livello molto, molto eh molto generico se vogliamo delle macro categorie che permettono di mappare la la sorta di colonna vertebrale del prodotto digitale.

Il secondo livello, che è subito sotto il primo appunto, vede i post-it che possiamo chiamare step o passaggi, ma anche task.

In realtà il nome relativo e al di sotto di queste macro attività vengono descritti e dettagliati dei passaggi chiave che secondo un flusso logico e quanto più consequenziale, consequenziale possibile e diciamo questi questi step e passaggi possono rappresentare quelle che sono le varie funzioni del progetto su un piano sempre molto alto, ma sicuramente di più di maggior dettaglio rispetto a le macro categorie.

Ad esempio, se ci prendendo in esame il solo catalogo, potremmo spacchettarlo, ad esempio dicendo che c'è una lista dei prodotti c'è una ricerca, ci sono dei filtri, ci sono dei preferiti e poi da lì si ci si sposta verso altre macro attività che avranno i loro sotto step di riferimento.

Il terzo livello, che è quello più profondo, vede dei post-it che chiameremo dettagli o user story, appunto.

Da qui il nome user story mapping e raccoglie quelle che sono le sfumature utili per descrivere in modo approfondito le funzioni e i requisiti sia funzionali che non funzionali di un progetto digitale.

E in questo livello di norma, almeno secondo la letteratura, la formula per scrivere una corretta user story, quindi per riempire un post-it è più o meno la seguente come utente, quindi come utente, come admin, come insegnante, come acquirente, quindi come utente e posso voglio e e qui c'è un verbo che permette di determinare qual è l'azione che voglio fare.

Quindi posso voglio fare un'azione con lo scopo, con l'obiettivo in modo da avere un vantaggio ottenere qualcosa, raggiungere un un certo un obiettivo, un certo step.

Quindi, come utente posso voglio fare un'azione in modo da ottenere qualcosa.

E questa formula è per esempio, se te la riporto nell'esempio di prima, ti potrei dire come acquirente posso, ad esempio, filtrare i prodotti del catalogo e per ridurre le opzioni.

Quindi lo scopo è quello di ridurre le opzioni e trovare più velocemente quello che sto cercando.

E l'obiettivo finale è quello di arrivare ad avere una serie di attività macro, ognuna delle quali al di sotto avrà le proprie tasche o i propri passaggi, sotto i quali ci saranno un numero variabile di user story, il tutto ordinato quanto più possibile secondo un senso logico e consequenziale, con lo scopo proprio di raccontare una storia vera e propria da quando l'utente interagisce la prima volta con il prodotto digitale fino a tutte quelle che sono poi le diramazioni che potrebbero esserci e chiaramente questo non sarà un processo lineare, perché per definizione si tratta di un dialogo e quindi anche di una conversazione, a volte anche divergente iterativo e tra tutti quelli che sono i partecipanti che insomma sono chiamati a fare questa attività e per questo motivo potrà succedere di tra virgolette, salire e scendere tra i i vari livelli, di muoversi in avanti e indietro rispetto a questa mappa che stiamo facendo di dover spostare interi blocchi in avanti e indietro per ridare in effetti un ordine coerente con lo scopo poi di arrivare in fondo ad un risultato condiviso tra le parti che soddisfi gli obiettivi di tutti e del progetto.

Soprattutto, ricapitolando, il user stopping è un metodo di definizione e raccolta dei requisiti che si sviluppa tramite una conversazione tra tutte le parti interessate coinvolte ad un progetto o in generale nella mappatura e raccolta dei requisiti con lo scopo di mappare le funzionalità secondo un modello che ha tre livelli di profondità e posizionando dei post-it in un ordine logico e temporale rispetto ad un percorso ottimale di un possibile utente, vengono poste sullo spazio di lavoro delle macro attività, ognuna delle quali avrà una serie di step e passaggi sottostanti più dettagliati, per finire poi al terzo livello che è l'ultimo, dove ogni step verrà poi approfondito e descritto con delle user story o semplicemente più dei requisiti che di norma hanno una forma come la seguente come utente posso voglio fare un'azione in modo da con lo scopo di raggiungere un obiettivo o un vantaggio