WebExpo è un evento di fama internazionale, tutto dedicato al web e ai suoi aspetti da power user, che quest’anno si svolge a Praga; si divide in tre track principali, che sono rispettivamente assegnate ad ognuno dei core topic di cui la rete è permeata. Sto parlando di Development, Design e Business. Vi sto parlando di tutto questo, perché tra gli speaker del WebExpo di Praga che ci sarà dal 19 al 21 settembre di quest’anno (quindi tra qualche giorno) ci sarà anche un italiano a rappresentare il nostro modo di pensare e vedere le cose: sto parlando di Carlo Frinolli, Creative Director di nois3lab, UX designer, e Mozilla Representative.

Ho pensato di fargli qualche domanda al volo sul suo lavoro, e su quello che dirà a WebExpo, così ci siamo accordati ed è stato molto disponibile.

Il tuo speech si intitola “Visual Design Thinking”. Di cosa parlerai alla platea del WebExpo 2013?

Il sottotitolo dell’intervento è “Telling stories starts from listening to people, and co-creating with them”, che in apparenza può sembrare molto distante da ciò che ci immaginiamo per visual design. Quando con Chiara Albanesi (@lucciole) abbiamo immaginato questo approccio, che non è necessariamente innovativo di per sé, ma è una sistematizzazione di un insieme di cose, focalizzate sulla gestione di progetti visual, ci siamo chiesti come poter affrontare l’incubo non solo dei progetti waterfall, ma anche come educare i clienti facendogli percepire il valore del nostro contributo

Vogliamo infatti raccontare come dire visual design sia nominare un complesso di interazioni, esperienze, potenzialità, e come questo non sia per nulla limitabile al “fare bei disegnini”. Parliamo di un processo bottom up, che parta dalla comprensione profonda del progetto prima di fare uno schizzetto elegante. La comunicazione visiva inizia molto prima della realizzazione di un’interfaccia, e non si esaurisce in questa. È (quel che sosteniamo è che dovrebbe essere) elemento chiave già nell’approccio, e quindi nei metodi atti a renderla il più possibile “su misura” per chi ne farà uso.

Raccontare storie è la forma più intrinsecamente umana di trasmettere informazioni. Quella visiva invece, è la forma più immediata. Partire con il farsi raccontare la storia del progetto (se ne ha) da un cliente ci aiuterà a capire potenzialità e confini, una cosa che un documento di requisiti tecnici più o meno stringenti non farà. Intendiamoci: non vogliamo sostituire le specs con le storie, ma affiancarle a un contesto, che ci faccia capire perché quella specifica è stata pensata così.

Nel talk si proveranno ad unire i punti di questa prospettiva più ampia di approccio alla progettazione visiva, che crediamo possano essere utili a scardinare molti degli ostacoli, intoppi, cigolii, che chiunque di noi ha incontrato nell’affrontare un progetto, sempre in bilico tra i due poli “vorrei il nostro logo più grande” e “una buona UX”.

Nella progettazione la metodologia agile e la sua applicazione scrum hanno suscitato sempre più interesse: le usi? Pensi che aiutino a tirare fuori buoni prodotti?

Se dicessi: sono uno scrum master, mentirei. Ho avuto però modo di lavorare con alcuni team che le implementano e devo dire onestamente che da una parte appaiono bizzarre, dall’altra sono molto utili e pragmatiche. Sulla bizzarria però ci facciamo presto l’abitudine: anni fa nessuno si sarebbe sognato di ritwittare o sharare qualcosa su Facebook. Senza andare troppo indietro nel tempo a scavare peraltro.

Il mio intendimento però è proprio quello di fare un uso ragionato e ponderato delle metodologie agili, adottandole guidato da qualcuno che sappia come farlo. Il punto per cui è naturale arrivare a queste metodologie è che i processi a cascata (waterfall direbbe qualcuno), non solo non funzionano sui mezzi digitali di oggi, ma sono dannosi. Rischiano di allungare il time to market di qualunque progetto, fanno perdere focus, e non prioritizzano alcun elemento. Ti trovi davanti un blobbone di cose da fare e/o sistemare, ci vuole una quantità di tempo indefinita per realizzarle, e quando il cliente lo vedrà non avrà più la stessa percezione del progetto che aveva quando te l’ha commissionato.

Avrà cambiato idea, capito cose, imparato da altri e tu non avrai avuto modo di metabolizzare niente perché sei chiuso nella tua stanzetta a costruire quel mostro. Diversamente con un approccio iterativo e atomico riesci a soddisfare quell’esigenza particolare, in un tempo ragionevole, e incrementalmente. Il che permette di testare il funzionamento di una soluzione in maniera più precisa.

Il design su web ha subito anno dopo anno delle svolte epocali: pensi che ormai un buon design equivalga a progettare (praticamente) una web application, o design e frontend development sono due campi ancora molto diversi?

Credo che questi confini siano francamente molto sfumati ora. Se pensi che un webdesigner oramai non si limita più a passare una quantità indefinibile di file grafici ai ragazzi che tagliano e trasformano in black magic html/css, ma si trova a prototipare direttamente in questi linguaggi la propria applicazione web lo capisci da solo. Per esempio l’ultimo non recentissimo redesign su Smashing Magazine hanno dichiarato di averlo fatto direttamente sul browser, senza passare dall’amato (e odiato) Photoshop. Se ci aggiungi che le tecnologie web (che magari ricordiamocelo sono per definizione aperte e difficilmente proprietarie se parliamo di HTML/CSS/Javascript), hanno compiuto passi avanti notevoli negli ultimi 4/5 anni – paradossalmente, anche grazie alla scelta di Apple di non includere flash su iOS, e mi preparo al flame che quest’affermazione genererà – allora risulta cristallino: sviluppo e interfaccia sono intimamente legati. E lo sono perché se è vero che l’interfaccia È il prodotto, allora l’utente, qualunque esso sia, avrà a che fare con questa, la quale gli permetterà di interagire con l’applicazione di turno, sia essa un sito o non, attraverso le funzionalità offerte, e sviluppate. Il legame quindi non solo è chiaro, ma è inscindibile. Per avere un’applicazione web di successo il design della stessa dev’essere complessivo, organico e possibilmente bottom-up.

La mia domanda precedente partiva dallo stesso punto di questa: il web evolve continuamente, eppure ci troviamo davanti sempre la stessa finestra. Secondo te i browser fanno abbastanza?

Non tanto tempo fa, quando Chrome non era ancora diventato il browser tra i più usati, almeno tra noi hipster della tecnologia, beh i browser erano messi piuttosto male, e noi webdesigner piangevamo lacrime di sangue. In fondo Firebug ha cominciato a vedere la luce nel 2006, non nel 1999… Di passi in avanti ne sono stati fatti tanti, ma certo l’aumento delle prestazioni dei computer/tablet/telefoni e quant’altro, unitamente alla diffusione di linguaggi standard e alla loro implementazione pedissequa da parte dei browser (quindi sì, sto escludendo Microsoft almeno fino a Explorer 10), di certo hanno fatto molto. Abbastanza, soprattutto in ambito mobile, non direi carlo quest’ultimissima frase non si capisce.

Un’applicazione completamente web, su device un po’ meno pompati, soprattutto con Android fatica abbastanza in termini di prestazioni che, se ci pensate, non sono una fisima da geek: se un’animazione è scattosa, una pagina non si carica, un dato non appare, voi siete già altrove. È una potenziale conversione che non avviene, un cliente perso. Questo però è un discorso tipicamente legato al codice, e lo sta facendo chi porta una proposta di talk che su un processo di design. Ciò non fa che confermare che l’approccio dev’essere necessariamente organico e olistico, ma soprattuto inclusivo, lavorativamente parlando,rispetto a tutti gli stakeholder del progetto, ivi compresi gli sviluppatori. Altrimenti si riproduce la classica, e stucchevole, dicotomia tra designer e developer, che francamente nel 2013 avrebbe anche scocciato. :)

Secondo te nelle piattaforme nascenti (come Firefox OS) quanto pesa la UX durante i processi decisionali? Hai la sensazione che siano veramente passi in avanti fatti “per l’utente”?

La mia impressione è che Firefox OS sia un prodotto di grande potenziale considerando il segmento di mercato che vuole affrontare. Però è un prodotto giovanissimo: la prima demo che ho visto risale al novembre 2011… In questo caso la UX è sicuramente stata un elemento importante ma gioco forza credo si siano concentrati sul far maturare il prodotto in termini di codice e funzionalità. Non scordiamoci che è il primo sistema operativo mobile che è scritto interamente in HTML/CSS/Javascript, e che standardizza l’accesso all’hardware del telefono tramite una API pubblica e sottoposta al W3C. Questo, al di là dell’evidente odore di supercazzola che emana, è un cambiamento piuttosto importante rispetto agli altri big player: Mozilla ha proposto che questo sia uno standard adottabile da tutti, adottandolo per primo. Il che è un filo differente da “faccio la mia cosa nella casa”. È un lavoro piuttosto titanico per costruire un primo mattone, su cui poggiare il resto dell’architettura. Premesso questo, rispondo alla tua domanda: stiamo vedendo un prodotto molto interessante e assolutamente dignitoso per il segmento di mercato, ma non un prodotto stupefacente. Limiti ne ha, come ne aveva moltissimi anche il primo iPhone, ovviamente.

Però penso anche che adesso venga il bello: ora che il prodotto è maturato ed è stato lanciato, ci si diverte, anche rispetto a UX innovative e passi avanti per l’utente. Peraltro non tralascerei neanche gli strascichi che il caso Prism e il Datagate in generale lascerà sulla fiducia degli utenti nelle corporation americane. Fai caso a una cosa, per esempio: nel lanciare Touch ID Apple ci ha tenuto a sottolineare che quelle informazioni non saranno mai caricate su iCloud. Un caso? Mozilla, e finisco l’apologesi da Mozilla Representative, è da Firefox Sync che carica sulla “nuvola” i dati dell’utente criptandoli prima localmente e poi storandoli sui suoi server. Un approccio un filo diverso dagli altri.

Photo credits: Alessio Jacona