Un nuovo approccio al design agile a cura di Luca Mascaro

La progettazione centrata sugli utenti (UCD) nasce come definizione diversi anni fa per organizzare in un processo strutturato, in un contesto dove fare software voleva dire lavorare su grandi sistemi molto complessi e strutturati. Per fare un’esempio storico buona parte delle formalizzazioni fatte dall’ISO o da associazioni come l’UPA sono state fatte negli anni precedenti e di inizio dell’era di internet. In ogni caso il processo di progettazione centrata sugli utenti e soprattutto i metodi in essa contenuti nascevano principalmente per prevedere tutto ciò che all’utente sarebbe potuto servire e come avrebbe voluto utilizzare il software. Purtroppo (o per fortuna) l’avvento del web nella sua forma odierna ha dimostrato i limiti di questa via in quasi tutte quelle applicazioni che richiedono una grande flessibilità, ma qual’è l’alternativa?

Per circa 10 anni progettisti ed ingegneri interessati all’HCI si sono posti questa domanda cercando di adattare il processo originale verso una sua forma più snella. Essendo che lo UCD portava comunque un innegabile vantaggio in termini di aumento dell’usabilità, diminuzione dei cambiamenti di requisiti e aveva comunque delle caratteristiche minime di flessibilità date dalla sua capacità di iterare verso l’inizio del nuovo secolo sembrava essersi raggiunto un buon compromesso con quell’insieme di tecniche e metodologie integrative che oggi vengono chiamate “user experience design” (UXD).

Con questo nuovo approccio al design ci si avvicinava parecchio alle esigenze di tutti quei progetti software per applicazioni e portali online che richiedevano un esperienza d’uso gradevole, semplice ed efficace (e non unicamente concentrata sull’usabilità) ed allo stesso tempo una minima capacità di evolvere nel tempo.

Nel 2004 però, con l’avvento del 2.0, emerse a livello di design e gestione del prodotto/servizio una nuova tendenza chiamata perpetual beta che in pratica richiedeva allo stesso di continuare ad evolvere a ciclo continuo seguendo i feedback portati dagli utenti direttamente sulla versione rilasciata al pubblico. Questa novità richiedeva un’ulteriore integrazione allo UXD/UCD in quanto il ciclo di sviluppo e di vita di una versione poteva arrivare a durare solo poche settimane prima di evolvere.

L’introduzione dell’agile nel design

Questa necessità di rispondere ad un cambiamento continuo rappresenta oggi il livello massimo di flessibilità richiesta al mondo del design dell’esperienza d’uso e una possibile risposta ci è stata data dal mondo dello sviluppo software che doveva realizzare tecnicamente questi servizi. Il mondo dello sviluppo ha infatti trovato una via per rispondere al continuo cambiamento attraverso le metodologie agili.

Le metodologie Agili nascono sulla base di una serie di principi tecnici e umanistici molto semplici permettono di accettare e gestire un cambiamento continuo dei requisiti. In pratica si potrebbero riassumere tali medotologie nell’idea di organizzare il lavoro in tanti piccoli cicli iterativi, molto focalizzati su pochi punti, dove persone “concentrate” e “competenti” cercano di risolvere problemi nel minor fattore di rischio possibile per il progetto.

Queste ultime permettono di fatto di cambiar rotta a piacimento su un progetto (seguendo dunque le esigenze degli utenti) in maniera relativamente rapida (il che non vuole dire però che il servizio completo si ottenga più velocemente) e senza compromettere l’impianto del progetto stesso elidendo così in parte il rischio di fallimento.

Data l’apparente idoneità di questo approccio il mondo del design da un paio di anni lo sta integrando nei suoi progetti sperimentando successi ma anche fallimenti ed iniziando oggi a comprendere quali sono le criticità di questo approccio. Infatti se l’adozione di principi di agilità aiuta l’UXD a muoversi nel mondo di questi servizi il continuo cambiamento senza delle basi progettuali solide e senza una strategia di lungo termine ha portato più volte il risultato del progetto a diventare un po’ un’aberrazione di se stesso dove l’utente pur ricevendo le singole funzionalità secondo i suoi desideri si trova in un’ambiente ostico che gli cambia spesso sotto i piedi con ovvi problemi di usabilità.

Anche nel piccolo mondo del mio team ci siamo resi conto più volte di come una gestione puramente tattica, giorno per giorno, di un progetto può portare a delle soluzioni non ottimali e dunque nell’arco degli ultimi mesi ci siamo interrogati su come si potrebbe fare evolvere ulteriormente il processo UXD.

Un nuovo processo “agile UXD”

Osservando gli errori commessi ed i risultati che ottenevamo ci rendevamo conto di come lo UXD/UCD tradizionale ci portava una serie di vantaggi di qualità e controllo che si perdevano nell’agile puro a vantaggio di una flessibilità estrema. La riflessione che è emersa a quel punto è però la constatazione di come questi due approcci così in antitesi (uno completamente strategico e l’altro tattico) sarebbero stati molto più efficaci nel seguire le richieste degli utenti se fossero stati fusi in un unico approccio.

L’utente infatti non ci chiede altro che ambienti consistenti e coerenti dove mano a mano emergono funzionalità sviluppate secondo le sue esigenze. La cosa curiosa è che l’ambientazione consistente nel tempo è una caratteristica data dalle prime fasi dello UCD mentre la capacità di evolvere si ottiene bene nell’agile dopo i primi cicli di “rodaggio”.

L’idea di processo che abbiamo dunque sviluppato e che stiamo testando con successo è quella di un processo “agile UXD” che durante le prime fasi più tradizionali si occupi di comprendere bene le macro-esigenze degli utenti, definire alcuni obiettivi ed una strategia per raggiungerli. Il risultato di questa fase di ricerca e definizione viene consolidando in un macro-progetto del sistema che funge da inibitore dell’approccio agile che viene poi perseguito nel tempo.

Questo nuovo processo permette di fatto di rispondere a standard qualitativi più alti a scapito di un inferiore accellerazione iniziale, accettabile comunque in un mercato che continua a richiedere sia flessibilità sia qualità.

Tags: agile, agile design, agile UXD, approcci, Design delle interfacce e dell'interazione, HCI, metodo, perpetual beta, processo, Progettare e vivere l'esperienza d'uso, UCD, UPA, usabilità, user centered design, user experience, UXD, web 2.0