AGILE UX ITALIA BARCAMP – FIRENZE, 31 MAGGIO 2012

AGILE UX ITALIA BARCAMP – FIRENZE, 31 MAGGIO 2012

Siamo qui per raccontare la nostra esperienza a questo interessante evento tenutosi a Firenze e ospitato dalla sede Dada Group.

Cercheremo di riassumere quanto detto dai molti speaker e di raccontarvi quanto abbiamo appreso sull’approccio Agile che sempre più si sta diffondendo.

Dopo una breve presentazione da parte degli organizzatori e il consueto benvenuto si parte subito.

La parola viene lasciata a Fabio Armani, CEO di OpenWare, che ci racconta come il mercato stia cambiando in questi anni e il motivo dell’evento che andiamo a raccontarvi è proprio quello di adattarsi a questi cambiamenti, quello di permettere di affrontare nuove sfide.

Due parole poi su LEAN UX, definita come evoluzione dell’Agile UX.

Fino ad ora la domanda che ci facevamo per la realizzazione di un prodotto era

‘Cosa dobbiamo fare?’
Successivamente, con l’avvento dell’Agile UX ci siamo chiesti anche
‘Come dobbiamo farlo?’
Ma adesso la domanda più importante è
‘Lo stiamo facendo bene?’

ed è proprio questo che si propone Lean Ux, una migliore focalizzazione degli obiettivi, una conoscenza approfondita degli utenti finali che utilizzeranno il nostro prodotto, una sempre maggiore e attiva collaborazione tra le entità che partecipano al progetto, la continua esternalizzazione di idee.
La presentazione è finita dunque, si parte con il Keynote, la parola ad Alberto Mucignat.
Anche lui ci dice che il mondo della User Experience (UX) sta cambiando. Ormai il puro design ha poca importanza se non ci sono dei contenuti interessanti. Una frase che mi ha colpito particolarmente è ‘Potete fare il pulsante più bello del mondo, ma senza la frase giusta gli utenti non cliccheranno‘.

Non è più questione di pubblicità, bisogna far percepire un valore al cliente.

Un punto cardine è il rapporto con gli utenti, è necessario conoscerli, passare del tempo con loro per capire quello di cui hanno bisogno.

C’è un bisogno disperato di Visual Designer in Italia, in molti si propongono come tali non essendolo affatto. Alcuni esempi:

  • C’è chi si propone come Interaction Designer, ma nelle specifiche leggiamo solo ‘video editing’ e ‘ottima conoscenza di Flash’. Questa non è INTERAZIONE.
  • C’è chi invece si spaccia per esperto di Design vantando esperienza nel disegno di brochures. Fare siti web non è come disegnare un volantino.
  • Gli esperti di grafica pura sono una categoria a sé stante, totalmente diversa dai Web Designer. Un errore tanto grave quanto comune è proprio quello di considerarli la stessa entità.

Colui che lavora alla UX non è un GENIO, non è il Roberto Baggio che al 93′ segna il goal della vittoria, dice Mucignat.

E’ solo qualcuno che lavora a dei processi che infine porteranno ad un risultato.

E’ vero però, lo studio di un design accurato richiede tempo, molto tempo ed il tempo è denaro. Ma se limitiamo questo aspetto perdiamo la User Experience. Ciò che lui consiglia è di non accettare compromessi, dobbiamo riuscire a dire di no, dobbiamo limitare le modifiche almeno per il primo rilascio.

Mucignat parla poi di grandi numeri. Il 10% del budget dedicato alla pubblicità andrebbe investito sulla User Experience, afferma. I presenti in sala rumoreggiano e sorridono. Poi mostra uno screenshot del sito Amazon e indica come la label ‘Ti è stato utile?’ con i relativi pulsanti ‘SI’ e ‘NO’. Mucignat afferma che questo tag apparentemente inutile ha fatto guadagnare all’azienda americana circa 2.7 Miliardi di dollari all’anno.

La gente in sala ride ancora.

Lo speaker sembra aspettarsi le reazioni e anticipa tutti dicendo che probabilmente stiamo pensando come questi numeri siano impossibili in Italia, ma da una recente statistica è emerso che l’Ecommerce in Italia vale circa 9 miliardi di Euro e risolvendo i problemi di usabilità potremmo arrivare ad un incremento del business di circa il 30%, vale a dire circa 3 miliardi di Euro.
Il primo talk finisce con un applauso.

La parola adesso a Susanna Ferrario per il talk ‘RESISTENZA AGILE

La speaker si presenta annunciando quanto sia stato soddisfacente, nuovo e divertente l’approccio Agile ai progetti. E’ qualcosa di completamente diverso rispetto a come siamo abituati a lavorare, ma alla fine lo vedremo come un modo di pensare dal quale sarà quasi impossibile separarcene.
Sfortunatamente è stata costretta ad abbandonare questo metodo di lavoro, ma è qui per raccontarci 8 punti forti appresi durante questa esperienza e dai quali non è riuscita a separarsi per lavorare.

1) Product Backlog
impariamo a lavorare seguendo una scaletta. Il lavoro sarà più frammentato, ma sapremo sempre cosa dobbiamo fare.

2) User Stories
dobbiamo cercare sì la soluzione, ma focalizziamoci soprattutto sul bisogno degli utenti.

3) Moscov & Kano Model
il prodotto non deve essere un Monolite, è importante focalizzare cosa è indispensabile e cosa è una delizia.

4) Acceptance Criteria
approfondiamo con il team gli aspetti di funzionalità e sicurezza, non più solo usabilità. Cerchiamo di fare anche qualcosa che ci piace.

5) Approccio Cross-Funzionale
Raduniamo allo stesso tavolo un team vario ed eterogeneo, analizziamo a 360° tutto il progetto, studiamo l’intera superficie dell’iceberg, non solo quella esterna e visibile a tutti. In questo modo gli eventuali problemi saranno chiari molto presto.

6) Daily Scrum
abbandoniamo i giri infiniti di mail che nessuno legge. Confrontiamoci piuttosto faccia a faccia ogni giorno, bastano 15 minuti. Avremo sicuramente una maggiore presa sul progetto.

7) Minimum Viable Product
evitiamo di rilasciare qualcosa che rientri nei tempi previsti, ma che nessuno vuole. Rilasciamo qualcosa di essenziale ma funzionale e utile. Testiamo il modello di business, se la direzione è giusta andiamo avanti, se è sbagliata ci fermiamo ed evitiamo di sprecare soldi.

8 ) Retrospective
creare una squadra, raccontare esperienze aiuta a migliorarsi, genera confronto, idee ed azioni. Rende evidente ciò che non va ma anche ciò che funziona.

Le pratiche Scrum agevolano sempre il lavoro.

Ciò che Susanna vuole dire al termine del suo talk è: provate l’approccio agile, provatelo se potete.

Parlano adesso Ilaria Mauric e Alessandro Violini che si/ci chiedono ‘PERCHE’ NON FACCIAMO PIU’ QUELLO CHE CI PIACE?

Nel 2008 il target era ‘faccio ciò che mi piace, nel modo più facile

Adesso è cambiato in ‘faccio la cosa più semplice e veloce, per consegnare valore al cliente‘ (e questo ci piace di più, aggiungono)

Nella loro esperienza raccontano che, prima di approcciarsi con l’Agile, molto spesso dovevano fare i conti con i seguenti fattori:

  • utente scontento del prodotto
  • cliente contento a metà (poteva essere fatto meglio)
  • team di lavoro scontento, decisioni prese a priori da altri
  • sforamento delle ore previste e lavorazioni extra

Come ripetuto nei talk precedenti, anche loro ripropongono l’interazione massima tra utente, cliente e l’intero team di lavoro. Il cliente fa parte del team e se possibile anche l’utente.

Ci invitano a parallelizzare la lavorazione ovvero:

  • più iterazioni
  • pair per la gestione del cliente: più persone parlano con il cliente, non più solo il commerciale

Bisogna essere pronti e disposti al cambiamento ci dicono, presentiamo al cliente perfino le bozze e gli schizzi ipotizzati su fogli di carta ed avremo molteplici vantaggi:

  1. qualora il cliente dovesse scartare la nostra idea il tempo perso sarà molto limitato
  2. il cliente si sentirà assistito.
  3. il cliente si concentrerà sul progetto e non sul dettaglio

Anche da parte loro il consiglio è il medesimo: provatelo provatelo provatelo.

E’ la volta di Yvonne Bindi che parlerà de ‘LE PAROLE CHE SI USANO
il talk inizia con la presentazione di due coppie di pulsanti. Sui primi due vi è scritto:
‘salva senza inviare’
‘invia la pagina’

sugli altri due invece soltanto
‘salva’
‘invia’

Yvonne ci spiega che il messaggio di un pulsante deve essere semplice, intuitivo, immediato. Gli utenti non devono fermarsi a pensare di fronte ad una scelta banale come quella sopra. O si salva o si invia. Punto.

Ci riporta poi l’esempio della scritta ‘Varco Aperto‘ che possiamo trovare mentre giriamo in macchina in alcune città. Il messaggio sta ad indicare che in quella determinata zona sono attivi i controlli di video sorveglianza e che quindi non si può passare. Un altro esempio invece viene dai cartelloni della stazione, dove per indicare il divieto di attraversamento binari si utilizzano una quindicina di parole.

I messaggi nella vita di tutti i giorni, così come nei siti web, dovrebbero essere più diretti, di più facile intuizione. Molto spesso riceviamo dei messaggi che ci trasmettono informazioni di cui non abbiamo bisogno, proprio come nel caso del ‘Varco Aperto’. Il destinatario del messaggio dovrebbe solo essere informato che in quel momento è vietato l’accesso, non che i controlli di videosorveglianza sono stati attivati.

Yvonne afferma che le persone apprezzerebbero molto più volentieri dei consigli a dei divieti e riporta così l’esempio della famosa linea gialla della metropolitana inglese: ‘MIND THE GAP‘. Solo tre parole per comunicare alle persone che non è saggio oltrepassare la linea. Stop.

Un altro talk è finito e subito ne inizia uno nuovo. La parola a M.Pesani e C.Pustorino.
Quello che i due ragazzi propongono per testare internamente il prodotto è quello di giocare di ruolo all’interno del team.

Pensiamo ad esempio al direttore di una banca che per un giorno si spoglia del proprio ruolo. Diviene così un cliente che intende aprire il suo primo conto. Così facendo potrà testare le varie procedure ed eventualmente migliorarle. Potrà rendersi conto di persona dove gli utenti troverebbero difficoltà.
Stessa cosa può avvenire all’interno di un team dove a turno se ne simula l’utilizzo che ne farà l’utente. Ovviamente chi esegue la simulazione dovrà conoscere il prodotto e aver fatto riunioni con il cliente.

Ci possiamo quindi ricondurre all’utilizzo delle Personas.
Vengono create varie schede di utenti tipo che utilizzeranno il sistema e se ne impersonano le caratteristiche personali. Il nostro prodotto potrà ad esempio essere utilizzato da un ragazzino che ha una buona conoscenza del web, dal pensionato al suo primo utilizzo di un computer, da un tecnico. Questo permette di testare il sistema e l’interfaccia con maggior cognizione di causa e il team lavorerà per ciò che gli utenti vogliono e non per quello che viene richieste dal capo.
Questo tipo di test non va ovviamente a sostituire test di usabilità su larga scala che sono ben più costosi, sono però un buon sistema iniziale a basso costo per testare il nostro prodotto.

Una problematica che è emersa durante i vari talk è che in un contesto Agile può essere difficile fare delle stime dei tempi e quindi dei costi da proporre al cliente, la cosa migliore sarebbe non farli proprio. Il problema delle stime è che vengono fatte in una fase dove non si ha una grande conoscenza del progetto. Può quindi essere di aiuto l’introduzione di contratti “Agili”.

Ad esempio si possono creare iterazioni da 5-10 giorni proponendo di volta in volta delle consegne (codice, mockup, prototipi), il cliente pagherà quindi per ogni consegna accettata. Questo sistema porta benefici al cliente che vede avanzare concretamente il progetto e può decidere quali modifiche effettuare senza dover sottostare a decisioni prese durante la prima analisi.

Una delle parti più difficile di un progetto è appunto la stima dei tempi (ci possono essere problemi non previsti), qualora un contratto come quello sopra non fosse possibile perché il cliente vuole assolutamente una stima e costi del progetto è possibile ricondurci ad una curva di incertezza che segue l’andamento di una funzione gaussiana: dato un preventivo con tempi medi X la stima e i costi possono variare in positivo o in negativo di Y%.

Se poi andiamo a fare una media dei tempi reali impiegati in un anno di progetti, vedremo che la nostra curva di incertezza si avvicinerà molto alla stima media.

Concludiamo ringraziando tutto lo staff di organizzatori, tutti gli speaker e i loro interessantissimi talk, l’ottimo buffet offerto da Dada, nonchè la sala ristoro.

 

Niccolò Baldini – @baldini_n
Fabio Ballerini – @ballerinifb

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *