UXmagazine nei primi tre mesi di vita a mio parere ha raggiunto dei numeri molto interessanti e sta perseguendo egregiamente il suo obiettivo di diffondere la cultura della progettazione. Per festeggiare questi primi risultati raggiunti abbiamo deciso di crearne una versione trimestrale scaricabile in pdf per tutti coloro che vorranno portarsi qualche lettura sulla spiaggia ;)
È così nato UXmagazine Book 1 che comprende tutti gli articoli pubblicati da maggio a luglio 2009 pronto da stampare e collezionare (presto anche attraverso Lulu). Buona lettura estiva ;)
I dubbi pre-camp erano molti, format un po’ diverso, pubblico un po’ diverso ma alla fine tutto è andato egregiamente. Anzi tra il centinaio di persone che hanno partecipato la maggior parte era alla sua prima esperienza con un barcamp e dai loro feedback diretti sembra che si siano divertite molto.
È stato un camp se vogliamo più formale degli altri ma finalmente siamo riusciti ad avere studenti, professionisti, ricercatori, startupper e responsabili di grandi aziende tutti in una stanza a scoprire ma sopprattutto discutere di experience design.
E che discussioni direi visto che gli spunti di tutti coloro che hanno parlato sono stati quel giusto mix tra argomenti di domani posti per un pubblico parzialmente neofita in materia ma che comunque aveva fame di comprendere. Si è parlato di Social Network Design, di mobilità, di errori progettuali, di sistemi complessi, di come le aziende giorno dopo giorno affrontano la sfida di progettare prodotti per la massa con i pochi fondi che lo stesso mercato ci da a disposizione (grazie Alessandro per il tuo incredibile contributo).
Stamattina quando mi sono svegliato ero molto soddisfatto perchè l’evento di ieri, nella sua modestia, è un segno del cambiamento, di come l’UX design è finalmente una realtà anche italiana dopo cinque anni di lotta per farlo emergere.
Grazie, grazie, grazie a tutti coloro che hanno partecipato e che sono stati la linfa di questo camp, e grazie a Diana, ai ragazzi del SML e a Nicola e Patrizia per il supporto nel renderlo possibile.
Poi per chi fosse interessato ad approfondire il mio speech di ieri sui progettisti appassionati ecco come promesso le slide.
È oramai già passato più di un anno da quando mi sono avvicinato all’acerbo mondo del design agile per studiarlo ed integrarlo nelle mie attività quotidiane e dopo diverse riflessioni e qualche mese di test in progetti reali ho finalmente finalizzato una bozza di processo agile.
Chi mi conosce da lungo tempo sa che, insoddisfatto ed un po’ frustrato, borbotto riflessioni su processi e metodi più o meno efficaci sin dal 2003, quando mi resi conto che non riuscivo mai a gestire con la dovuta qualità la modellazione di servizi online.
Tra il 2004 ed il 2006 con la nascita di Sketchin queste mie riflessioni si fecero più acute e coinvolsero più persone in più tornate (penso che Emanuele non ce la faceva più a sentirmi parlare di come l’approccio tradizionale all’IA era assolutamente fuori dal mercato) fino a concentrarsi mano a mano nel 2008.
A fine 2008 annunciai in un paio di eventi l’idea di fondere principi strategici dello user centered design, metodologici dello user experience design e tattici dell’agile che ho sperimentato in seguito in diversi progetti.
Ora ho finalmente formalizzato questo processo, che per il momento ho chiamato semplicemente “Agile UXD“, in un articolo per il lancio di UXmagazine.
Nell’articolo ho cercato di riportare a sommi capi le mie riflessioni che spero di integrare prossimamente con anche le caratteristiche e le metodologie di dettaglio del mio schema operativo. Nel mentre volevo chiedervi un feedback sulle stesse (in quanto fino ad oggi hanno retto un confronto generale) poichè sarebbe interessante trovare eventuali falle logiche sempre partendo dall’assunto che un processo non si adatta chiaramente a qualunque progetto.
Sono già trascorsi 15 giorni da quando ho annunciato su questo blog la nascita di UXmagazine, progetto editoriale partecipato sui temi della progettazione.
Devo dire che sono molto soddisfatto di come è venuto fuori e ringrazio tutto il mio team e gli amici che ci hanno messo l’anima per realizzare questo progetto :)
Agilità nel creare prodotti e servizi software
organizzare il lavoro in piccoli cicli iterativi molto focalizzati dove persone “concentrate” e “competenti” cercano di risolvere problemi nel minor fattore di rischio possibile
Ieri durante l’Agilecamp ho discusso in più momenti (culminati nel mio intervento.. di seguito la presentazione) di come i principi e le metodologie agili si possono innestare anche nel mondo della progettazione. La discussione in maniera un po’ curiosa si è focalizzata diverse volte sulle criticità che questi due mondi vivono nell’interfacciarsi ed in particolare io vedo come questioni critiche:
Sono appena arrivato a San Francisco e ho colto l’occasione del viaggio per riflettere un po’ su un intervento sull’agile design che ho seguito durante il Web 2.0 Expo di New York.
Seguire un design e uno sviluppo agile è il modello che ritengo in assoluto più affascinante per chi punta alla qualità. Un processo rapido e focalizzato al risultato che permette specialmente nel nostro settore di creare prodotti innovativi e funzionali in un modello crescente.
Insomma una vera e propria panacea per molti progetti dal punto di vista teorico ma che nasconde a mio vedere una serie di inconvenienti dal punto di vista della sostenibilità nel nostro mercato sud europeo.
Il punto è che i processi agili richiedono il coinvolgimento di figure di alto livello che collaborano tra di loro in periodi contigui di forte concentrazione.
Questo significa ottenere in tempi brevi prototipi o prime versioni funzionali del prodotto dalla qualità eccelsa e perfettamente in tempo per il mercato, ma, significa anche bloccare completamente interi team di progettazione e sviluppo per tempi medio-lunghi (si parla di avere prodotti pronti al lancio in 2 cicli / 4 settimane ma completi e di ottima qualità dopo qualche mese).
Non è da nascondere che nel nostro mercato non sempre si punta alla qualità e che i clienti chiedono spesso una chiusura del progetto in tempi brevi e con costi contenuti.
Questo cozza nella pratica di tutti i giorni con la pratica definita precedentemente e succede così che chi fa “agile” si trova strozzato in pochi cicli, in tempi impossibili o semplicemente deve affrontare più progetti “mediocramente” perchè non ha i fondi per affrontarne uno “seriamente”.
Alla fine il risultato è sempre lo stesso: il prodotto è incompleto o di scarsa qualità
La domanda che dunque mi pongo è bisogna cambiare la mentalità della clientela/mercato portandola a comprendere i vantaggi di questi processi oppure identificare nuove strade che intermedino il tutto?
