Alberto Mucignat

Alberto Mucignat


Random thoughts around web stuffs (è tutto un equilibrio sopra la follia)

agosto: 2019
L M M G V S D
« Ott    
 1234
567891011
12131415161718
19202122232425
262728293031  

Categorie


Lean UX a Better Software (con note aggiuntive)

AlbertoAlberto

Lunedì sono stato a Better Software, dove ho parlato di lean ux, che è un po’ l’evoluzione dell’agile ux in chiave startup (ma non solo). Le slide sono disponibili da qualche giorno su slideshare, ed eccole qua:

Aggiungo a margine alcune considerazioni, anche per consentire a chi non c’era di analizzare le slide.

UX e Lean (slide 4-6)

Da quando ho iniziato a interessarmi al tema Lean UX mi è subito apparso chiaro come la user experience lavorasse su un concetto di valore simile a quello del pensiero Lean. Intendo che entrambe elaborano un concetto di valore con un ragionamento molto simile.

L’idea di focalizzarsi sul testimone e non sui corridori della staffetta è un esempio che vorrei aver inventato io. In realtà fa capire molto bene l’assurdità di alcuni metodi di gestione dei processi (direi “fordisti”) che tendono a ottimizzare riducendo le persone a oggetti che devono produrre velocemente e sempre con più efficacia. E questo vale moltissimo anche per chi lavora al design di prodotti digitali.

Dobbiamo quindi iniziare a concentrarci sul valore che viene deliverato anziché sull’ottimizzazione maniacale dei tempi e delle risorse. E nel caso della UX il valore è proprio quell’incrocio di interessi tra business (che realizza un prodotto sostanzialmente per guadagnarci) e utenti/clienti del prodotto (che valutano il valore del prodotto in base all’esperienza d’uso che ne ricavano).

Evitare gli sprechi? (slide 8-10)

Spesso al metodo Lean viene erroneamente associato il concetto della riduzione degli sprechi. Non è proprio esatto: il lean si concentra sul miglioramento continuo, che presume anche una ricerca degli sprechi, allo scopo di poterli ridurre. Viene cioè insegnato al personale come individuare gli sprechi nel loro lavoro.

Questo non presuppone una ricerca top-down degli sprechi, ma un continuo focus sull’ottenere il massimo valore con il minimo sforzo, che ogni persona svolge durante il proprio lavoro.

In realtà, io sono convinto che la UX abbia contribuito ad eliminare molti sprechi: le pratiche di design della UX hanno consentito di focalizzarci sul prodotto finale fin dalle prime fasi di idezione. Sketch delle pagine, wireframe e prototipi hanno progressivamente portato le aziende a ridurre le pile di documenti a favore di deliverable più “agili”.

Ma la “rivoluzione” è stata ancora più raffinata. Comunicare visivamente ci ha infatti permesso di evitare molti piccoli sprechi negli interstizi dei progetti: incomprensioni tra sviluppatori e designer, decine di mail di spiegazioni, interpretazioni errate di una frase, correzioni in post-produzione, ecc.

Infine, esiste un limbo, che è quello della generazione delle idee di design, dove lo spreco deve essere proprio coltivato: solo dalla molteplicità delle idee che riusciamo a generare possiamo scegliere la più adatta. E subito dopo dobbiamo iniziare a togliere: andare all’osso dell’idea, semplificare, togliere il superfluo.

In Aviator c’è una scena in cui Hughes/Di Caprio osserva il profilo della fusoliera di un aereo e dice qualcosa tipo: “tutti questi ribattini: via!”. A me questa immagine piace pensarla ispirata da Saint-Exupery, che pure era un amante del volo:

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

La morale è che si può arrivare a questo punto solo se si lavora cercando il miglioramento continuo del prodotto.

Cicli di lavorazione (slide 11-13)

L’idea che sta alla base della Lean UX è che il lavoro procede a cicli, con 3 fasi per ogni ciclo: build (costruisci), validate (verifica) e learn (impara).

Per noi che facciamo UX è un processo abbastanza noto: prototipazione, testing, debrief. In effetti, molte pratiche della UX sono completamente allineate al processo ciclico.

La cosa interessante è l’utilizzo di questo ciclo da parte delle aziende.

Un primo consiglio (slide 12) è quello di iniziare con una fase di discovery (quella che in passato, nel mio talk su Agile UX, avevo definito “Iteration 0”) che aiuti a creare un embrione del prodotto. Questa fase, nella mia esperienza, può anche essere più lunga di quanto si pensi, poiché è sicuramente necessario uno studio del mercato e uno studio del comportamento degli utenti.

Un secondo aspetto (che non ho trattato nella mia presentazione) è quello della gestione del team di lavoro. Spesso ci sono team di design e sviluppo separati. Altre volte ci sono agenzie esterne che si integrano nel processo. In queste situazioni la gestione del team diventa fondamentale per la buona riuscita del progetto.

La visione della UX (slide 14-16)

In tutto questo lavoro ciclico c’è la necessità di mantenere una visione coerente, che solo la pratica dello user-centered design può fornire.

Anzitutto, dobbiamo considerare alcuni livelli (layer) della user experience (a cui ne aggiungo uno post-presentazione):

Una chiave di volta del processo è la relazione tra scenari e user stories che ho già descritto in un post su Augmented design.

La visione d’insieme dovrebbe far capo al designer della UX: scenari, collocazione delle user story, ecc, derivano direttamente dalla strategia e dalla UX vision.

Solitamente l’iteration planning è un momento cruciale in cui si decide la pianificazione dello sviluppo. Si decide cioè quante e quali user story verranno realizzate in ogni iterazione di sviluppo.

In un contesto puramente agile, in cui anche il design è inserito nei cicli di lavoro, è necessario che all’iteration planning siano presenti anche dei designer. In realtà, l’iteration planning è proprio un’attività di design del prodotto (si decide come si evolverà il prototipo del prodotto), quindi secondo me chi decide l’iteration plan è anche UX designer.

Voglio dire: è importante che iniziamo a pensare all’iteration planning non solo come un momento di pianificazione risorse/tempo, ma anche come un momento chiave in cui si decide l’evoluzione del prodotto e la sua UX. Per questo è necessario che questo step sia facilitato da un responsabile della UX, che deve validare la roadmap e gestirne le eventuali modifiche successive (che ci saranno, se siamo veramente agili).

Lean UX: convergenza tra business, design e sviluppo (slide 17-19)

Il punto è che siamo in un momento storico in cui il business, il design e lo sviluppo stanno convergendo tutti verso pratiche comune:

Questo aspetto di convergenza è dato anche dalle pubblicazioni (vedi slide 7) che in questo periodo si stanno susseguendo su questi temi.

Per me, in questo momento storico, la figura chiave che può garantire il massimo del valore è un “designer della UX contaminato con il business“.

Alcuni (tipo Cooper) hanno proposto il concetto di “Product Stewardship”, in cui ci sono 2 figure responsabili di prodotto: Product manager (business side) e Product Steward (design/development side).

In realtà, il mio auspicio è che anche in Italia si inizi a pensare a figure come “Head of UX”, al posto dei vari marketing o product manager. In effetti oggi l’esperienza È il prodotto, ma se i manager non lo capisco il rischio è che facciano fallire il design dei prodotti.

Propongo quindi alcune condizioni di partenza per uno “UX Product Manager” o “Head of UX”:

Comunicare i cambiamenti (slide 20-26)

Per andare un po’ sul pratico e abbassare un po’ i toni della mia presentazione, ho inserito una serie di esempi sul tema della comunicazione e dell’introduzione dei cambiamenti nelle interfacce. È un tema su cui conviene investire sempre di più per far percepire la coerenza di visione all’utente/cliente finale e “formarlo” a un utilizzo consapevole e pieno dell’interfaccia.

Una considerazione a margine è che mentre questo aspetto si è molto evoluto su web, nel caso delle app mobile è ancora difficile capire dove e come sono cambiate le cose a seguito di un upgrade.

Riflessioni finali

Sempre di più mi trovo a fare delle presentazioni e percepire di aver dato una visione d’insieme che ha delle radici profonde: sono temi su cui ragiono e lavoro da anni, che mi appassionano e che mi piace condividere.

Spero di aver comunque puntualizzato gli aspetti che non ero riuscito (per mancanza di tempo o di opportuna dialettica) a spiegare nel mio speech.

Tuttavia mi rimangono alcuni punti aperti su cui ragionare e lavorare ancora:

Infine, vi lascio con una riflessione di Tim McCoy (di Cooper.com):

Lean UX is not interaction design shoehorned into agile frameworks. Product vision, user research and modeling, and truly evolutionary iteration are central to this approach. It stresses lightweight, collaborative, right-fidelity UX techniques to generate, test, and evolve the design of your product.

E noi (parlo anche di me e della mia azienda) siamo pronti a questo passaggio?

Comments 0
There are currently no comments.