Come alcuni sanno, negli ultimi mesi nel team di Sketchin abbiamo sperimentato diverse variazioni di approccio ai progetti nella costante ricerca di trovare una corretta via al design agile.

In particolare abbiamo cercato di condensare le iterazioni nell’ordine dei giorni o addirittura delle ore alla costante ricerca di quel try&catch con cui semplificare il concetto di approccio iterativo. In questo processo di esplorazione dell’agilità abbiamo coinvolto i nostri partner di Ideato:  i due Franceschi e Jacopo che a loro volta hanno adattato le loro pratiche quotidiane a questo nuovo incastro ancora tutto da definire.

L’ultimo progetto che abbiamo sviluppato è Ladies First, un interessante caso di studio per l’approccio adottato.

…continua la lettura »

È 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.

Che ne pensate?

Durante l’agilecamp di gennaio ho tenuto un’intervento su come il mondo dell’agile si può confrontare con lo sviluppo di servizi orientati all’utente. Ora grazie a Nicola abbiamo il video di questo intervento :)

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:

…continua la lettura »

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?

Su UXMatters, uno dei principali portali del mondo dell’experience design americano, e stato pubblicato un articolo/case history di Sketchin su un progetto portato a termine in breve tempo e secondo una metodologia agile.

Nell’articolo la mia riflessione sull’esperienza ha fatto emergere 4 fattori chiave che hanno determinato il successo del progetto e che secondo me dovrebbero essere i pilastri della progettazione agile:

1. The best designer for a project is one who knows the product domain
2. All activities in a UCD process are useful, but some more useful than others
3. Do fast paper prototyping, then quickly test your prototype on friends and relatives.
4. The ability to explain a design efficiently is vital to the success of a project.