Ho avuto il piacere di collaborare con il team di Cripto books con un rapporto che ha iniziato nel duemilaventidue e che poi ha proseguito per anni insieme al team di base box.

Il rapporto con il team di Cripto Books ci ha visti coinvolti su più aspetti legati alla UX, ma comunque con un approccio di confronto, di consulenza strategica su aspetti anche di prodotto e dopo una serie di iterazioni e dopo un paio d'anni, si è iniziato a parlare di rifare il sito web quello che vedi qua davanti a te e chiaramente questo è il nuovo sito web e il lavoro e ha visto in qualche modo noi come consulenti, ma tutto il team di Cripto books e quindi le loro figure chiave coinvolte in un diciamo un lavoro di mappatura e definizione dei requisiti sicuramente non convenzionale.

E il lavoro che abbiamo fatto, um dal punto di vista teorico è molto simile anche a quello che ho ho descritto all'interno di questo corso, ovvero abbiamo mappato quello che era il contesto contesto di partenza e quindi andando a cercare di capire um, quali fossero i principali entry point per cui un utente sia cliente che potenziale tale e in qualche modo entrasse in contatto con il sito web, ad esempio le email, i webinar, la ricerca organica, le app e i social.

E quindi, dopo aver definito um diciamo questa mappa anche del del come le persone in qualche modo trovano il sito e quindi anche cercare di capire da dove provengono e quindi anche cosa si aspettano e abbiamo mappato effettivamente l'attuale sito web, ovvero quello che era l'attuale sito web, ovvero da dove stavamo partendo, cercando di mettere sul piatto non soltanto le cose che sicuramente erano i migliori dal punto di vista di design di U i e anche de legato al brand, visto che c'è stato il branding, ma tutte quelle che erano le esigenze di ogni speci- persona specifica dal punto di vista tecnico, di marketing di business, in modo tale che tutto il team fosse coinvolto.

Ma soprattutto che il lavoro non fosse soltanto un rifare il sito web in funzione del acquisire nuovi clienti.

E quindi eh, diciamo in funzione di quelle che potenzialmente sono le esigenze del cliente finale, ma anche per andare a diciamo, a rispondere a quelle che erano le esigenze del team, ad esempio del team di marketing di poter realizzare delle landing page um di acquisizione in modo più rapido e in modo più efficace.

Una volta mappato il sito web di partenza e quindi da dove che effettivamente stavamo partendo, abbiamo mappato quelli che erano, diciamo, rappresentavano i maggiori competitor.

Quindi, andando a cercare di capire, in effetti cosa fanno i competitor, cosa facevano i competitor nel momento in cui abbiamo fatto il redesign del sito e per cercare di capire, in effetti, anche se questo potesse avere un impatto su quelli che erano i requisiti funzionali e non funzionali del sito nuovo, che saremmo dovuti andare a progettare.

E quindi dopo aver analizzato i competitor e quindi ci ha ha anche compreso in effetti cosa c'era sul mercato al di là insomma de del nostro naso e è stata realizzata una nuova architettura di progetto.

Um, come vedi in realtà non c'è diciamo l'applicazione di una di un protocollo, diciamo, di un metodo di user mapping in modo specifico perché e questo in qualche modo rappresenta la realtà, ovvero il fatto che nel momento in cui uno conosce un metodo di lavoro e sicuramente è bene che poi capisca qual è il momento giusto per applicarlo quando in modo diciamo da manuale e quando invece magari bypassarlo per cercare di raggiungere in modo migliore o diversamente, quelli che sono poi gli obiettivi di progetto.

In questo caso noi abbiamo fatto una prima mappatura, una prima scrematura, se vogliamo delle attività che ci aspettavamo, che un utente potesse fare all'interno del nuovo sito web cercando di mappare le pagine, ma anche elementi di progetto come il menù e il footer, per poi andare a fare un approfondimento pagina per pagina, quantomeno per le pagine principali di quelle che sono le tassonomie, ovvero l'ordine dei contenuti e in qualche modo l'ordine della narrazione, costituendo questi diciamo wireframe questi scheletri di pagina e coinvolgendo tutto il team al fine di arrivare ad avere una versione um se se anche se grezza, comunque abbastanza definita del nuovo sito web che convincesse tutti sia dal punto di vista tecnico che dal punto di vista di obiettivi di business che dal punto di vista di eh diciamo in qualche modo di poi di obiettivi, anche di acquisizione.

Perché il sito web, insomma, aveva questo scopo e ha tuttora questo scopo e questo ci ha permesso di raggiungere le fasi progettuali, le fasi di sviluppo e arrivare ad avere un sito web sicuramente molto più performante rispetto a quello che che c'era prima e sicuramente molto più anche adeguato a quelle che sono le attività e gli utilizzi che in effetti il team ne fa una cosa importante.

Se ti posso lasciare un un altro suggerimento è quello di cercare di validare i requisiti non soltanto tra diciamo in house tra le persone ci sono quindi che siano consulenti o persone del team, ma anche cercando di coinvolgere persone esterne.

Il vantaggio che noi avevamo avuto, mi ricordo all'epoca fu quello che nel mentre stavamo facendo la riprogettazione del sito.

Nel frattempo c'era un'attività di ricerca di customer research sulla piattaforma, quindi sulla parte interna della piattaforma.

E una cosa importante è stata quella di coinvolgere alcuni clienti o potenzialità, e non solo sulla parte di piattaforma, ma anche su alcune scelte del sito, quindi su pezzi di prototipo, su parti di contenuto, su nuovi copi.

E questa cosa ci ha permesso di validare non soltanto i requisiti, ma anche tutte quelle piccole sfumature di dettaglio che poi in realtà fanno la differenza rispetto poi alla buona riuscita di un progetto.

Ecco, se ti posso lasciare questo consiglio è nel momento in cui riesci a farlo perché ne hai la possibilità.

Sicuramente potrebbe essere una buona scelta.

È sicuramente una buona pratica quella di validare i requisiti in fase appunto di mappatura, analisi dei requisiti, ma successivamente cercare di coinvolgere utenti o potenziali dati reali e al fine di essere sicuri che veramente non ci siamo persi nulla.

Nel senso che, anche se a noi ci risulta che dopo tutte le fasi che sono state fatte non è stato perso nulla, un utente finale potrebbe magari farci quella domanda o farci quell'appunto che non ci aspettiamo e che sicuramente può essere di grandissimo valore.