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):
si parte dalla UX strategy: qual’è la vision, la strategia di design del nostro prodotto? (e questa deve essere centrata sul valore massimo tra business e utenti)
personaggi e scenari: ci aiutano a trasformare la vision in scenari reali e ad applicarla a pattern di comportamento reali(sono forse il primo reality check)
user stories: sarebbero i task dello user-centered design (cioè i task che possono essere svolti dagli utenti/clienti) e sono delle unità minime di rappresentazione della user experience
iteration planning: è il momento in cui si decide cosa deve fare l’applicazione nelle sue varie versioni di rilascio.
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:
piccoli team cross-funzionali che collaborano a stretto contatto
metodi di gestione informali e leggeri (wiki-like)
cicli rapidi di lavorazione
focus sull’utente/cliente finale.
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”:
responsabile ultimo della UX di prodotto: nessuno oltre a lui ha più potere in merito)
investire continuatamente nelle persone (scelta, formazione continua, mentoring)
ricerca maniacale del miglioramento continuo (iterazioni e retrospettive con il team)
equivalente a un C-level: se vogliamo che abbia peso nelle decisioni, non può essere un semplice quadro
budget: iniziamo a prevedere un budget specifico per la UX? cosa ne dite di partire dal 10% del budget adv?
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:
il design dev’essere embeeded all’interno dei team di sviluppo?
come possiamo fare in modo che le agenzie esterne o i consulenti riescano ad integrarsi meglio con i team di sviluppo senza perdere la testa o senza diventare un collo di bottiglia?
com’è possibile rinunciare al design up-front e fare invece vero design incrementale?
e infine: com’è possibile mantenere una visione d’insieme (pensate al puro visual design) durante cicli di lavorazione rapidi?
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?
Poor online user experience, coupled with a lack of insight about why customers are abandoning websites, is costing businesses billions of dollars / pounds.
Nello specifico, chi riesce a quantificare i clienti che abbandonano, stimano che la perdita media sia del 24%, dovuta principalmente a cattive esperienze online:
Companies able to quantify site abandonment estimate they are losing the equivalent of 24% of their annual online revenue due to a bad online experience. This equates to more than $50 billion lost in the US and around £14 billion lost in the UK in the last year.
In Italia i numeri sono sicuramente diversi, ma i termini percentuali sono sicuramente peggiori (è una mia percezione), dovuto al fatto che il nostro mercato dell’usabilità e della customer experience (quella vera, non millantata) è ancora immaturo e poco sviluppato.
Altre cose interessanti del report:
While companies have a relatively good understanding of what customers are most likely to do on their first visit and the reasons for making the first purchase and returning to their site, they have “limited” or “no understanding” about why customers abandon the shopping cart (78%) or leave the site without converting (81%).
Come dico da tempo, le statistiche non bastano e questi sono chiari problemi ai quali solo la ricerca qualitativa può dare risposta, specialmente a quello che “sappiamo di non sapere”.
Ma non basta, le aziende sono anche lente e reagiscono tardi, invece di anticipare i problemi:
Rather than avoiding problems in the first place, companies are reacting to issues after the horse has bolted. Companies are most likely to learn about problems as a result of calls to the customer service team (76%) and customer emails (also 76%). In other words, most companies are reactive, discovering problems when it’s too late.
Purtroppo è un’aspetto che spesso notiamo: essere proattivi è difficile, è più semplice far finta che i problemi non esistono. Ed è difficile per noi che facciamo UX e usabilità far capire ai nostri clienti che stanno buttando soldi dalla finestra.
In ogni caso, perlomeno nel mercato UK-US, i test di usabilità si stanno piazzando bene, come dimostra l’immagine:
Dopo tutto ciò, mi stupisce un po’ un altro dato: gli investimenti in miglioramento della UX sono considerati da molte aziende ancora insufficenti, a dimostrazione che il mercato non è ancora maturo per poter imporre alle aziende investimenti continui.
In effetti questa è anche la mia esperienza: mentre per l’adv e altre attività di manutenzione sono previsti budget ad hoc, il budget per usabilità/UX non viene quasi mai considerato, o solo in emergenza.
Comunque c’è una buona notizia: la maggioranza degli intervistati ritiene che i test di usabilità siano fondamentali per capire la customer experience:
While only 44% of respondents carry out user testing, the vast majority consider it to be “very effective” (56%) or “quite effective” (43%) in helping them understand the customer experience.
Ma soprattutto i test di usabilità sono ritenuti lo strumento più efficace per capire la customer experience:
E infine, l’architettura dell’informazione è il problema più critico dei siti:
As revealed by both quantitative and qualitative data, bad navigation / poor findability is by far the most common issue customers encounter on websites, with more than half of companies mentioning this. It is also perceived to be the most serious problem.
To get to a great product or service, you need to work from great insights about your customers.
[...]
The user-centered design process we teach at the d.school focuses on developing empathy for your customers. This is much more than just understanding statistics, data, and click-through rates. You need to know them well enough to understand what’s important to them, what they care about, and how your product fits into their world.
Cioè, insomma, perfino ad Harvard insegnano ai manager (o meglio: agli imprenditori e innovatori) ad andare oltre i numeri.
Peraltro ieri parlavo con un amico che lavora per un’agenzia pubblicitaria e mi diceva che ormai il mercato si sta orientando verso il modello a performance, anche perché il puro display è chiaro che porta poco.
È una cosa che immaginavo, in ogni caso google rulez: la grande G ci ha abituati a lavorare sui numeri e sull’ottimizzazione frenetica. E in fondo il mercato adv in pochi anni è cambiato molte volte.
Però, insomma, secondo me il ragionamento è sbagliato: si chiede alla pubblicità di garantire i numeri, quando invece è l’utente a scegliere se acquistare o meno (mi pare veramente assurdo, ma se non è così spiegatemelo, please).
Insomma, l’utente continua ad essere l’elefante nella stanza del reparto marketing: non ne parla nessuno, spesso viene idealizzato, quasi sempre viene ignorato nelle scelte. Eppure Harvard insegna e anch’io vi ho spesso esortato ad andare oltre le ricerchine di mercato.
Per concludere, ho anche un un paio di corollari a questo ragionamento.
1. Continuerò a ripeterlo fino alla nausea: dobbiamo mettere assieme dati e ricerca sugli utenti per ottenere il massimo dalle performance. Poiché è vero che i numeri da soli non bastano, però dobbiamo imparare a portali dentro il lavoro sulla user experience.
2. La ricerca con gli utenti, il perfezionamento del prodotto e il controllo delle performance sono pratiche che avvengono a monte della pianificazione di una campagna. Che senso ha spendere soldi per portare i prospect sul sito, quando poi il servizio/prodotto funziona male?
(Pensa te come passa il tempo: lo dicevo 5 anni fa e lo sottoscrivo anche oggi.)
Ci tengo a ribadirlo: lavorare sull’architetura delle informazioni del sito/servizio/prodotto è un investimento a lungo termine che, a differenza della pura usabilità o delle ottimizzazioni che si possono fare, dà i suoi frutti nel tempo, in maniera costante.
Segnalo anche una frase che ripeto da diversi anni e che, vedendola scritta dai ragazzi di Google, mi fa sorridere placidamente di soddisfazione:
You may find that Google Analytics can show you what happened, but perhaps not why it happened. To learn more about your visitors sometimes you have to observe them. The best way is user testing and it’s easier than you think, you can start with just 3 or 4 participants.
In conclusione, ti consiglio di leggere attentamente l’articolo, anche se sono cose un po’ normali per chi si occupa di architettura dell’informazione da molto tempo.
Manca pochissimo al quinto Italian IA Summit, che quest’anno abbiamo organizzato presso la nuovissima e tecnologicissima sede di Milano / Sesto San Giovanni dell’Università Statale di Milano.
Sono molte le novità di quest’anno: la pre-conferenza istituzionale con università e aziende, i workshop/seminari formativi richiesti a gran voce negli anni passati e la diretta streaming fornita dal CTU (grazie!) che spero riusciremo ad arricchire con interviste e backstage.
Abbiamo lavorato molto al programma, motivo per cui lo abbiamo reso pubblico solo ora, ma è veramente ghiotto:
giovedì 5 maggio (mattina): pre-conferenza “istituzionale” con l’università e le aziende (ci sarò anch’io in mezzo a parlare di come sta cambiando il nostro lavoro all’interno delle aziende)
giovedì 5 maggio (pomeriggio): workshop formativi sui temi dell’architettura dell’informazione e usabilità (a prezzo stracciato! ci sono ancora posti disponibili)
venerdì 6 maggio: all day conference con i keynote di Crumlish (autore di Designing social interfaces) e Palmarini (IBM)
sabato 7 maggio (mattina): conferenza con i keynote di Massimo Russo (Gruppo L’Espresso/Kataweb/LaRepubblica) e Resmini/Rosati che probabilmente ci presenteranno anche il loro nuovo libro (Pervasive IA).
bonus track: venerdì e sabato ci sarà una poster session con la presentazione di alcuni progetti.
Sono particolarmente contento di vedere che tra i relatori ci sono alcuni amici che da anni ci seguono e che ho esortato a partecipare. Mi spiace per i pochi esclusi, purtroppo la blind review dei paper quest’anno ha privilegiato temi nuovi e/o presentati sotto una luce nuova: speriamo di aver fatto le scelte giuste!
Concludo con i numeri e le features di quest’anno:
aula magna da 400 posti con mega video
diretta streaming, interviste e backstage
200 posti per i workshop
oltre 300 partecipanti già iscritti alla conferenza (ad oggi)
8 sponsor che ci consentono di mantenere gratuita la conferenza (grazie!)
frivolezze: 3 coffee break con poster session, 2 pranzi/aperitivi/cene (giovedì/venerdì) che ancora dobbiamo organizzare, ma alle quali invitiamo tutti gli amici e simpatizzanti.
Infine ringrazio il board di questo summit: un team che quest’anno abbiamo integrato con alcune new entry. Ragazzi, sono felice di essere parte di questo gruppo.
Beh, cosa aspetti, l’iscrizione alla conferenza è gratuita: iscriviti e partecipa! Ci vediamo a Milano!
Qualche giorno fa ho ricevuto dalla mia banca una mail che riportava questo testo:
dal 21 marzo 2011 è in vigore l’obbligo – per chi intende agire in giudizio relativamente a controversie concernenti, tra l’altro, i contratti bancari, finanziari e assicurativi –, introdotto dal decreto legislativo 4 marzo 2010, n. 28, di esperire il procedimento di mediazione ai sensi del predetto decreto. L’esperimento del procedimento di mediazione è condizione di procedibilità della domanda giudiziale.
Ora, io mi chiedo, secondo voi quante persone hanno capito il significato di questo linguaggio da azzeccagarbugli? Io continuo a leggerlo da giorni e ancora non ci ho capito molto. Non credo di essere il solo a “esperire” questo problema.
Un consiglio alle banche: qualche tempo fa Luisa Carrada aveva scritto un bell’articolo sul linguaggio bancario, perché non ve lo leggete?
Da tempo sono convinto che il copywriting e la scrittura dei testi siano il primo tassello per migliorare l’usabilità. Anche perché nella maggior parte dei test che ho fatto in vita mia ho visto che sono le parole (sbagliate o mancanti) a generare confusione e incertezza.
Sabato sera, presi forse da unsogno di città europea (o dall’incubo di trovare parcheggio), abbiamo deciso di uscire senza macchina. Era una bella serata e ci siamo detti: “andiamo a piedi, al ritorno prendiamo i mezzi o il taxi”.
Quindi siamo andati a piedi fino al quartiere Flaminio dove avevamo appuntamento per cena.
Al ritorno, circa a mezzanotte, salutiamo gli amici e decidiamo di chiamare un taxi. I vari numeri dei taxi non rispondevano, solo uno (la coop Samarcanda) ha risposto e dopo qualche tentativo ci ha detto però che “non ci sono taxi disponibili”.
Nel 2011, in una capitale europea, alle 24 di sabato sera, mica alle 5 di mattina del lunedì…
Successivamente abbiamo preso un tram fino a piazzale Flaminio, ma non siamo riusciti a trovare un autobus che ci portasse a casa (abitiamo comunque in zona centrale). Il nostro autobus non arrivava perché l’ultima corsa è alle 24 (!).
Nel 2011, in una capitale europea, di sabato sera.
Quindi abbiamo aspettato mezz’ora e poi abbiamo preso un altro autobus fino a piazza Fiume. Attraversando la piazza (sulle strisce) siamo quasi stati investiti da una macchina guidata da ggiovani che sfrecciava a tutta velocità con la radio a palla.
Infine, siamo andati all’isola dei taxi, dove ci aspettavano comodamente 4-5 taxi che prima però non erano disponibili, chissà come mai. Forse non volevano fare la fatica di guidare 5 minuti per il muro torto.
La cosa è veramente allucinante, ma fa capire a che livello sia la mobilità di una città che spende comunque vagonate di soldi per mantenere le caste, la lobby dei tassisti e un livello da terzo mondo dei servizi pubblici.
In tutta europa, il sabato sera i giovani prendono i mezzi o il taxi (che costa di meno, chissà come mai), ma da noi invece preferiscono guidare ubriachi. Per fare 5-10 km in città. Allucinante.
Ma se pensate che non sia un problema nostro o che non sia possibile cambiare questo stato di cose, allora proprio per questo paese non c’è nulla da fare.
Però a questo punto, ecco, toglietevi di mezzo voi, grazie.
ps: peraltro a quell’ora non c’è un posto dove comprare i biglietti per i mezzi pubblici, quindi pur volendo farlo diciamo che “ci siamo arrangiati”… E no, non potevamo tornare a piedi come all’andata, purtroppo (per motivi che non sto qui a spiegare).
Da noi non esiste, quindi vi faccio vedere qual’è il giornalismo vero (via Il Post), quello che pone domande serie e incalzanti. E io non sono convinto che sia come sparare sulla croce rossa: se uno è ministro se ne assume le responsabilità.
Scrive Sofri (quello giovane) che “il modo giusto di fare le interviste è quello: in teoria basta una domanda, la prima”. Ecco, magari qualcuno inizi a imparare, anche da noi.
Ai giornali italiani che in questi giorni titolano solo buzzword (“apocalisse” in primis) preferisco il Guardian: gli inglesi almeno si sforzano di informare e spiegare meglio che possono, anche con l’aiuto della sintesi visuale.
Mi chiamo Alberto Mucignat, vivo a Roma e faccio lo User Experience Designer, ovvero mi occupo di progettare siti e servizi web efficaci e facili da usare.
Per questo ho fondato Doralab, azienda che si occupa di progettazione della user experience, user-centered design e usabilità.
Nel tempo libero mi dedico alla natura: arrampico, vado in mtb e mi piace esplorare posti sconosciuti.
Segui i post del blog (feed rss)