La Lean Ux è una tecnica cross-funzionale e collaborativa. Il termine che la identifica, ovvero Lean UX, è stato coniato da Jeff Gothelf e Josh Seiden nel loro libro, Lean UX appunto: il testo individua nella metodologia Lean i principi da applicare per migliorare la User Experience.

Nella Lean Ux la collaborazione diventa fondamentale, imprescindibile tra tutti gli esponenti del team. È un impegno continuo che permette di creare un nuovo prodotto molto più velocemente. Scendendo nel dettaglio potremmo individuare tre aspetti principali nella Lean UX: il design thinking, il metodo Lean Startup, il mindset Agile. Ma andiamo per ordine.

Il Design Thinking è un processo iterativo attraverso cui cerchiamo di comprendere l’utente e comprendere i vari bisogni da soddisfare/problemi da risolvere in modo nuovo, identificando, testando strategie e soluzioni alternative non immediatamente individuate. In un determinato e conciso lasso di tempo, il Design Thinking vuole quindi ottenere un risultato verificabile. 

Entrando in sintonia con gli utenti, si comprendono i loro bisogni da cui nascono a loro volta nuove soluzioni per soddisfare le loro suddette necessità:  attraverso la creazione di prototipi le soluzioni vengono testate e quindi verificate. 

Il Lean Startup è un metodo basato sull’ideazione, la verifica e la modifica continua: con costi e tempi ridotti si può testare se un determinato prodotto funziona o meno sul mercato. Il fallimento, inteso come sbaglio da cui imparare velocemente, è parte integrante dell’approccio Lean Srartup. Arrivati alla creazione di un MVP, ovvero di un prodotto con i prerequisiti minimi affinché possa essere approvato, si integrano poi via via funzioni, caratteristiche... Con feedback continui da parte dell’user e degli stakeholder, il prodotto viene testato e modificato in base alle necessità, riducendo così il margine di errore, i costi e i tempi di realizzazione del prodotto stesso. 

Il Mindset Agile e il Lean UX sono strettamente correlati a partire dai loro valori, dal loro approccio, dall’importanza dell’usabilità del prodotto. 

Nel loro libro Jeff Gothelf e Josh Seiden pongono l’attenzione sull’apprendimento, sulla priorità di questo rispetto al rilascio delle funzionalità. Quindi in caso di un nuovo prodotto il primo step include creare dei piccoli e diversi prototipi, testarli e quindi individuare quali caratteristiche, funzionalità, aspetti siano potenziali e quali no per il nostro futuro prodotto. 

Lean UX, il canvas.

Il Lean UX Canvas è una tecnica che permette insieme a tutto il team di ragionare sul business problem e sui business outcomes che vorremmo raggiungere. 

Quindi sulla nostra canvas andremo ad individuare dei blocchi distinti:

• Il problema da risolvere (business problem)

• Gli outcomes da raggiungere 

• Chi è il nostro user

• Quali outcomes l’user vuole raggiungere attraverso il nostro prodotto 

• Soluzioni 

• Ipotesi

• Il MVP, ovvero Minimum Viable Product

• Cosa dobbiamo fare per arrivare al MVP

Stato del Problema

Dopo aver individuato i business outcomes, gli users, gli outcomes degli users e le features, devi fermarti sul problema più grande ovvero... il problema! Con la Lean UX Canvas, rispetto al problema, ci andremo quindi a chiedere: 

Su cosa e su chi si sono focalizzati i prodotti attuali, su quali aspetti e users;

I prodotti attuali falliscono per quale gap;

Per risolvere tale gap il nostro prodotto adotterà quale strategia;

I nostri users sarà un determinato target;

Se il nostro prodotto funziona gli users faranno tali azioni.

Proto-Persona

Dopo aver individuato il problema passiamo all’User, alla persona che andrà a utilizzare il mio prodotto. Cercando di comprendere cosa fa, come vive, che comportamenti assume e perché negli altri miei competitors ha individuato un gap e qual è. 

Eccoci arrivati al momento clou, ovvero quando l’Agile entra in gioco nella Lean UX. Come anticipato all’inizio del nostro post, è importante che il team sia collaborativo e cross funzionale. Tutti i membri devono quindi partecipare e contribuire all’attività di discovery, favorendo il progetto e aumentando la produttività. Si parla infatti nel team di una shared understanding, ovvero di una comprensione condivisa. 

L’intero team partecipa infatti a sessioni di Design Thinking per arrivare al MVP (Minimum Viable Product). L’importante in tal senso è riuscire a creare un prototipo attraverso cui comprendere le ipotesi più rischiose, testarle e sottoporle al target.

Sempre alla condivisione, alla shared understanding, possiamo legare la necessità di inserire nella stessa Product Backlog: user stories, discovery, bugs, tech tasks. Ogni item nella Product Backlog ha la sua priorità assegnata attraverso gli story points (puoi trovare tutti gli approfondimenti relativi ad Agile Scrum qui).

Facendo un ripasso veloce quindi:

• Nella prima cerimonia Agile avviene il Backlog Refiniment: si definiscono quali user stories si andranno a sviluppare nello Sprint Planning, dando una priorità attraverso gli acceptance criteria. La prioritizzazione viene fatta dal team insieme al PO. 

• Nella seconda parte della cerimonia Agile le user stories vengono “pesate”, sono assegnati gli story points. Questa azione si chiama stima dell’effort e getta le basi per lo Sprint Planning. Nello Sprint Planning si decide quante e quali user stories portare in Sprint e quanto effort occorrerà per ognuna di esse. Ma come si fa a decidere quante e quali user stories portare in Sprint? Con una vera e propria media! Si analizza la capacità del team e la sua velocità nella risoluzione delle user stories, analizzando gli Sprint precedenti. 

• Realizzato lo Sprint Planning e stabilito l’obiettivo da raggiungere (Sprint Goal), si inizia con lo Sprint. Ogni giorno, durante il Daily Scrum, il team si riunirà e condividerà gli stati di avanzamento del progetto: cosa è stato fatto ieri? Ci sono stai impedimenti nel mio lavoro? Cosa farò oggi?

• Il team quindi anche attraverso il Daily Scrum comprenderà quanti e quali passi avanti sta facendo, se ci sono degli impedimenti per raggiungere lo Sprint Goal. Al termine dello Sprint avviene la Demo o Sprint Review dove gli stakeholders testeranno il prodotto fino ad ora sviluppato e la sua usabilità. Le richieste che gli stakeholders faranno in fase di Sprint Review saranno annotate dal PO, condivise poi col team, riportate nel Product Backlog ed inserito nel prossimo Sprint. 

• L’ultimissimo step alla fine di ogni Sprint è la Sprint Retrospective dove il prodotto viene dallo Scrum Team ispezionato: cosa ha funzionato? Cosa non ha funzionato? Quali impedimenti il team ha incontrato nello sviluppo del prodotto? In cosa potremmo migliorare? Cosa andrò ad implementare nella prossima Sprint? Con chiarezza e trasparenza date delle risposte a queste domande e non caricate la prossima Sprint con implementazioni non realizzabili. Usare sempre la concretezza.