Questa è la traduzione dell'articolo Sketching in Code: the Magic of Prototyping di David Verba pubblicato originariamente su A List Apart il 17 Giugno 2008. La traduzione viene qui presentata con il consenso dell'editore e dell'autore.
Nel corso dell'ultimo anno ho notato sempre più discussioni intorno alla creazione di prototipi come metodo di sviluppo di applicazioni web. Al di là delle conversazioni casuali, il lavoro con i prototipi è divenuto argomento di post su molti blog o nelle presentazioni in varie conferenze. Le ragioni di questa crescita di interesse includono innanzitutto i tanti benefici che i prototipi possono portare con sé nello sviluppo di buone applicazioni web. Dalle migliorate possibilità di collaborazione alla disponibilità di soluzioni efficaci a svariati problemi, questi benefici hanno reso lo sviluppo di prototipi un approccio da prendere in considerazione per i nostri progetti.
Wireframe
Uno degli sviluppi nel mondo delle applicazioni web che ha reso l'approccio basato su prototipi più attraente è stato l'avvento di Ajax e delle RIA (Rich Internet Applications). Prima dell'arrivo di questi approcci più interattivi, erano i wireframe ad avere un ruolo di preminenza. Potevano essere usati in diversi contesti, con alta o bassa qualità e fedeltà, per soddisfare finalità e obiettivi differenti. Potevamo usare wireframe leggeri per esplorare soluzioni alternative all'inizio di un progetto. Potevamo usare versioni più fedeli e rifinite come documentazione per gli sviluppatori e i designer che avrebbero lavorato all'applicazione. Potevamo usare i wireframe per spiegare ai clienti che aspetto avrebbero avuto le pagine. In molti casi erano una parte cruciale delle consegne associate ad un progetto. Insomma, i wireframe erano lo strumento da usare per la documentazione di un'applicazione web.
Con l'avvento di Ajax, però, i wireframe hanno iniziato ad essere un po' inadeguati. Quando lasciamo il mondo delle interazioni basate su pagina, come si documenta anche la più semplice delle interazioni? Grafici e diagrammi di flusso non funzionano. Anche con un solo elemento interattivo su una pagina dobbiamo spesso generare più di un wireframe o usare molte annotazioni per visualizzare i diversi e possibili stati dell'interazione. E ovviamente quando gli elementi interattivi sulla pagina sono molteplici e tra loro interconnessi il problema diviene ancor più complicato.
Queste limitazioni sono di per sé sufficientemente difficili da gestire, ma la situazione peggiora quando iniziamo a considerare non solo il design ma anche lo sviluppo. Lo sviluppo che coinvolge Ajax e RIA richiede una comunicazione più stretta tra sviluppatori e designer; e questa comunicazione deve spesso essere iterativa. Mettere un sacco di wireframe sul muro a disposizione dello sviluppatore non funziona. L'informazione critica richiesta per questo tipo di scambio spesso non può essere catturata in un wireframe. Insomma, i tentativi di usare i wireframe per gestire interazioni complesse sono davvero problematici.
La magia sta nei prototipi
I prototipi ci consentono di restare concentrati sui nostri obiettivi reali. Ho visto quantità infinite di ore spese nella creazione di migliaia di pagine di documentazione che non sono mai state usate. In sé non sarebbe un fatto grave se avessimo a disposizione infinite risorse in termini di sviluppatori. Purtroppo ciò raramente avviene e personalmente ho spesso visto dei tagli alle features di un'applicazione prima del lancio di un prodotto a favore della creazione di una migliore documentazione. Con i prototipi il focus è sempre sull'applicazione e sul modo per renderla migliore. Con i prototipi è molto più semplice rimanere concentrati sul valore da dare all'utente finale.
Inoltre, lavorare con i prototipi significa riuscire a veicolare la magia di un'applicazione web. Lavoro in questo settore da anni e incontro ancora siti web che mi entusiasmano. Possono esserci piccole interazioni e tocchi di genio che mi fanno esclamare: "Accidenti, è fatto bene!" Posso trovare sempre qualcosa di sorprendente, inaspettato o semplicemente ben concepito. Questi momenti hanno in sé un impatto emozionale e viscerale che non posso trarre da un wireframe o dalla documentazione su carta. Spesso il tutto è basato sull'interattività o su funzionalità che distingueranno dalla massa il nostro prodotto. L'unico modo per veicolare queste sfaccettature di un'applicazione interattiva è usare dei prototipi interattivi.
Benefici dei prototipi
Lavorare con i prototipi ci consente di vedere i problemi in maniera più chiara nel corso del processo di progettazione e sviluppo. Quando si va oltre un sito aziendale basato su contenuti e ci si sposta verso applicazioni che hanno funzionalità ricche e complesse, la nostra abilità di mettersi davanti ad un progetto e prevedere le potenziali interazioni diminuisce. Il campo dei potenziali problemi è semplicemente troppo complesso. Questa è la ragione per cui abbiamo iniziato a usare i wireframe. Spesso l'unico modo per capire veramente dove potrebbero sorgere i problemi o per trovare le soluzioni consiste nel buttare giù qualche schizzo. Usiamo i wireframe proprio per fare uno schizzo del contenuto e del layout, ma nel momento in cui ci dedichiamo a interfacce più complesse e interattive, i wireframe non sono più efficaci. Dovremmo fare uno schizzo, per così dire, della funzionalità su cui stiamo lavorando, per verificare come l'applicazione si comporta realmente.
Un altro ambito in cui i prototipi sono una soluzione vincente è quello delle presentazioni ai clienti e/o a chi prende decisioni nell'ambito del progetto. I prototipi possono aiutarci a vendere meglio una soluzione che è radicalmente diversa da quella attuale del cliente. L'approccio tradizionale consiste nel creare una magnifica presentazione in PowerPoint e spendere una giornata sostenendo la bontà del nostro approccio. Invece, mettiamo un cliente davanti ad un prototipo funzionante e mostriamogli perché il nostro approccio è valido.
Infine, non dimentichiamo gli utenti. Nello user-centered design, uno dei primi passi consiste nel cercare feedback da parte degli utenti. Spesso sono utenti attuali o potenziali del prodotto che si sta sviluppando. È un approccio molto valido, ma se l'utente in questione ha una certa familiarità con il prodotto attuale, può essere difficile per lui immaginare un approccio completamente differente. Come noi, sviluppatori e designer, non possiamo sempre prevedere le implicazioni delle nostre decisioni fin quando non le vediamo in azione, gli utenti sono soggetti agli stessi vincoli. Gli utenti possono magari richiedere funzionalità che sono per loro necessarie solo per scoprire, quando usano la nuova applicazione, che quella funzionalità non era poi così utile. Usando prototipi interattivi si riesce ad ottenere invece un feedback efficace ed accurato sin dall'inizio.
Ci sono anche un paio di benefici nascosti. Il primo è che l'uso di prototipi rende più veloce la collaborazione. Spesso i prototipi richiedono che designer e sviluppatori lavorino gomito a gomito su qualcosa di concreto in un lasso di tempo molto ristretto, si riesce così a tenere insieme in una stessa stanza queste persone, facendo in modo che possano comunicare. In secondo luogo, designer e sviluppatori iniziano a capire cosa è possibile. Più tardi, quando si troveranno da soli o lavoreranno ad un altro progetto, potranno capire meglio cosa è facile o difficile mettere in atto in specifiche situazioni.
I prototipi nel processo di sviluppo
Dunque, dove si colloca il ruolo dei prototipi nel processo di sviluppo? Possono essere usati nel modo appropriato in qualunque momento. Ci sono diversi di tipi di prototipi, da quelli semplici e appena abbozzati ai mockup dettagliati e pienamente funzionanti. Quello che è importante è scegliere l'approccio corretto per il problema che si sta affrontando.
Considerate in che momento usarli nel corso dello sviluppo del progetto e chi sarà a guardarli e usarli. Forse potreste usarli all'inizio per fare una sessione di brainstorming di idee e per valutare in profondità queste ultime più velocemente che in una sessione alla lavagna. In questo caso può andare bene un prototipo molto leggero. Nel processo di sviluppo, poi, potreste avere bisogno di qualcosa di più robusto. Se poi il prototipo deve essere una rappresentazione dell'applicazione da far testare al cliente, è necessario che abbia una qualche forma di visual design e un set completo di funzionalità.
Le inevitabili limitazioni
Ci sono ovviamente delle limitazioni intrinseche nell'approccio basato sui prototipi che vale la pena menzionare. Un problema può essere rappresentato dalla fedeltà. Nulla di nuovo sotto questo aspetto; si ha lo stesso problema con i wireframe. Quante volte abbiamo presentato un wireframe che era troppo fedele ricevendo un feedback del tipo "Possiamo schiarire quella sfumatura di verde?" oppure "Dovremmo dare un tono più fresco al logo". Al contrario, possiamo presentare wireframe che sono pochissimo fedeli e andiamo incontro al problema dell'accettazione da parte del cliente. Gli stessi problemi, dunque, possono sorgere con i prototipi se non li presentiamo nel contesto appropriato. Se hanno una fedeltà troppo bassa, a prescindere dalle funzionalità che possono rappresentare, può essere difficile prenderli davvero sul serio o percepirne il valore. Se hanno una fedeltà molto alta rischiamo di ottenere il classico responso "Grande! Facciamo partire tutto il prossimo martedì!"
Considerate anche che le annotazioni sono complicate. Gli approcci basati su una documentazione molto corposa non registrano solo la decisione finale e il risultato del progetto, registrano anche il cammino percorso per arrivare a quel risultato. Includono le decisioni messe in atto e quelle non messe in atto, chi le ha prese, quando e perché. Ma dal momento che è spesso difficile annotare un prototipo funzionante, alcune cose possono essere trascurate. Possiamo per esempio avere un certo elemento nell'angolo superiore destro e non sapere se è lì perché ci è stato messo all'inizio per non essere più spostato o se quel posizionamento è il frutto di un accesa discussione all'interno del team. Se si guarda al prototipo finale questa distinzione potrebbe non essere chiara. In pratica, è sempre opportuno evidenziare esplicitamente questo tipo di informazioni.
Risolvere il problema giusto
Un pensiero finale: è fondamentale, quando si adotta questo approccio, risolvere il problema giusto. Un impulso comune è quello di complicare oltre i limiti il processo intero. Ricordate che uno dei motivi per cui i proponenti del cosiddetto Agile Development guardano con occhio critico alla documentazione è che preferiscono rimanere concentrati sul prodotto finale. Questa attitudine dovrebbe tradursi in un approccio che coinvolge anche l'adozione dei prototipi. Un utile principio guida è quello di usare il metodo più veloce e leggero in grado di offrire i risultati che si vogliono ottenere.
Dunque, se il vostro prossimo progetto può trarre benefici da una maggiore collaborazione, considerate i prototipi. Se volete fornire un miglior risultato finale ai clienti e ai visitatori, considerate i prototipi. Se iniziate con poco, i costi sono minimi e raramente ho sentito gente lamentarsi perché avrebbero non voluto fare un prototipo. Raramente ci sono ricette magiche quando si parla di sviluppo web, ma i prototipi sono un passo in quella direzione. Provateli.
