A proposito di wireframe e prototipazione ho scritto nel tempo diverse cose:

• I Wireframe sono contratti: comunicazione e specifiche in un unico strumento
• Wireframe rulez: i 3 benefici chiave dei wireframe
• Bassa fedeltà: la chiave per progettare e ottenere feedback sulle informazioni
• Augmented design e agile UX: utilizzare wireframe/prototipi in ambienti agili.

Sebbene potrei fare alcune correzioni, credo che questi pensieri siano ancora validi. Solo una precisazione: spesso parlo di wireframe e prototipi intendendo sostanzialmente la stessa cosa. Per me oggi la differenza tra wireframe e prototipo è solo nell’interattività: il wireframe è statico, il prototipo è interattivo, ma valgono le stesse regole (flessibilità, modificabilità, bassa fedeltà).

Per fare un esempio, se si utilizzano software come Omnigraffle, Visio o Axure è possibile creare wireframe interattivi, che io chiamo prototipi. Si può anche rendere interattivo un wireframe con tecniche di paper prototyping, ma in ogni caso i tool oggi consentono una buona flessibilità.

Voglio essere ancora più specifico: quando parlo di prototipo intendo un artefatto del design che non interagisce in alcun modo con un server, ma è semplicemente un’evoluzione dei wireframe verso una forma più interattiva (link tra pagine, pulsanti funzionanti, menù a tendina, overlay, box che si espandono/contraggono, etc).

Detto questo, vorrei ribadire i due motivi principali per cui si utilizzano wireframe o prototipi per il lavoro nel design dal punto di vista dei benefici che portano al progetto e al committente:

• consentono di testare: sia i wireframe che i prototipi consentono di testare il sito con gli utenti, garantendo un feedback per correggere il design
• documentano il progetto: anche se spesso è necessario un ulteriore lavoro di documentazione, i wireframe/prototipi sono un impareggiabile strumento di comunicazione.

Detto questo, ritorno alle domande di Jacopo e Ilaria e cerco di rispondere.

• usare wireframe o html/css: i nostri obiettivi principali sono testare e documentare, quindi qualsiasi formato va bene, purché sia facilmente modificabile da tutti, compreso chi non ha familiarità con i codici (vedi Wireframe rulez)
• dove collocare il wireframe: il wireframe appartiene alla fase di design e avviene prima del visual design e dello sviluppo. Se lavoriamo in maniera agile non cambia: all’interno dei cicli, prima bisogna “prototipare/wireframizzare”.
• quand’è che il cliente vede il prodotto finito: il prodotto finito non esiste! scherzi a parte, il vero punto è che il cliente deve invece abituarsi a lavorare in bassa fedeltà, per capire come funzionerà il prodotto, dare feedback e garantire committment sul progetto.
• quanto cambia dal prototipo alla grafica: la mia risposta è che, tranne quando il visual gioca un ruolo importante nel prodotto, il design finale deve rispecchiare il wireframe, salvo eventuali necessità di disposizione grafica (spazi e dimensioni). Per velocizzare, si possono usare griglie già nell’impostazione del wireframe, guadagnando notevolmente sui tempi di sviluppo (vedi Augmented design)
• quando definire la “grafica”: la grafica, o meglio il visual design, è un’attività che può iniziare presto con la raccolta dei “requisiti” (mood board, brand identity, etc), ma che deve per forza attendere una versione evoluta dei prototipi/wireframe per entrare nel vivo. Quindi avviene dopo che sono stati prodotti i wireframe.
• se il progetto non passa, chi paga i wireframe: beh, ragazzi, i wireframe/prototipi sono un lavoro che deve avvenire prima dello sviluppo e che chiaramente dev’essere pagato.

L’ultimo punto è veramente cruciale, perché segna una milestone per lo sviluppo del design nel nostro belpaese.

Dobbiamo abituare i clienti a lavorare in modo diverso, nuovo: prima si fa il progetto, poi si sviluppa. In fondo non succede lo stesso quando costruiamo una casa? Qualcuno ha mai costruito un palazzo senza prima chiedere a un architetto di fare il progetto?

Molte aziende infatti si rivolgono ai designer dopo che è stato acquistato Sharepoint dicendo che adesso bisogna customizzarlo. Ma il lavoro dei designer non è customizzare Sharepoint, bensì progettare una intranet che sia efficace e facile da usare (e che venga utilizzata).

Qualche giorno fa, Giacomo ha scritto un bell’approfontimento su questo tema, da cui riporto queste frasi:

Anche la migliore piattaforma resta qualcosa di più astratto del peggior design (geniale, ndb) perché, mentre quest’ultimo si confronta comunque con i reali problemi dei dipendenti di un’organizzazione, la prima definisce uno standard buono per tutti e per nessuno, a cui bisognerà, nel migliore dei casi, “rimettere mano”.

Ciò non toglie che molte intranet si assomiglino tra di loro, ma questo avviene meno per la presenza di piattaforme che uniformano i contenuti e più per il ricorrere di problemi comuni alle aziende, che, fortunatamente, possono essere trasformati in pattern di design. (…)

Questo rende più semplice, ma non elimina il problema del design. Che eccede sempre le piattaforme per collocarsi in un territorio neutro nel quale tecnologie, pratiche, esigenze e pattern diventano progetto concreto.

Basterebbe questo a chiudere il discorso.

Purtroppo spesso il mandato per il rifacimento della intranet viene assegnato al reparto IT, il quale per prima cosa sceglie una piattaforma software. Anche se questa tendenza sta cambiando, è una forte limitazione al design delle intranet con la quale ci troviamo quotidianamente a fare i conti. Con evidenti ricadute sull’usabilità e sull’adozione della intranet da parte dei dipendenti.

Aggiungo infine quello che ho scritto nell’appendice sullo user-centered design che apparirà in fondo al libro di Giacomo sulle intranet 2.0 (in libreria da settembre, a quanto mi dice):

Molte persone ritengono che non sia necessario progettare le singole pagine di una intranet, poiché spesso le intranet vengono costruite partendo da software già disponibili.  Questo è un chiaro errore: i software si basano su un concetto di “funzionalità”, che è molto diverso dal concetto di “bisogni umani”. Nella mia esperienza, l’impiego di software preconfezionati (spesso installati e configurati alla buona) è un rischio perché risultano molto difficili da essere compresi e utilizzati. Ricordiamoci che se non vengono usate dalle persone, le intranet rimangono solamente delle cattedrali abbandonate nel deserto.

E dio solo sa quante cattedrali abbiamo in Italia. E quante ancora ne stiamo costruendo.

Oggi uno studio con l’eyetracking sui comportamenti di lettura dei giornali on e off-line mi arriva attraverso uno spunto interessante:

(…) people read on the web almost exactly the way they read anywhere else: they skim till they find what they need. This is manifestly not the same thing as “users don’t read,” and claiming that it is will almost certainly lead to stupid content and UX choices. The whole anti-reading campaign is based on a fundamental misunderstanding about the ways in which people read printed text, and the difference between their behaviors as online and offline readers.

La cosa è piuttosto importante, poiché pare che i cosiddetti scanner leggano sostanzialmente quanto i lettori metodici. In pratica, quando gli utenti decidono di leggere, sia i metodici che gli scanner leggono circa il 77% del testo online.

È un comportamento che noto anch’io negli utenti durante i test quando c’è una forte motivazione: leggono/scansionano ogni piccola parte del testo, spesso vivisezionando le frasi troppo sintetiche.

Corollario Mucignat (visto anche il post di ieri): gli utenti leggono, scansionano, scrollano, cliccano… se ne hanno bisogno. E il bisogno dipende dalla loro motivazione e dall’obiettivo che hanno in mente. E dal tipo di sito che stanno navigando o dall’applicazione che stanno utilizzando.

Comunque oggi leggevo di a/b testing e lo sguardo mi è caduto (sarà l’eyetracking che mi contagia) su un articolo che spiega perché le cosiddette “mad libs” style form di cui ha parlato recentemente LukeW possono peggiorare le conversion anziché aumentarle.

Personalmente credo che nel caso citato, la form iniziale fosse più semplice da comprendere della seconda, da cui i risultati peggiorativi. Infatti l’autore del post consiglia saggiamente che ognuno faccia i propri test prima di cambiare una form.

In verità, molti esempi citati nel post di Smashing Magazine sono discutibili e i risultati dipendono molto dal tipo di sito, dal tipo di form, dal servizio che viene offerto, dal tono e dallo stile del sito, dal prodotto, dall’implementazione, dall’immagine aziendale, ecc. In poche parole i risultati dipendono dal tuo sito, che è diverso dagli altri.

Dico questo perché spesso mi chiedono: “dicono che questa cosa funziona meglio: me la consigli?”. Altre volte mi dicono: “tu l’hai fatto così, ma c’è un tizio in australia che l’ha fatto diverso e funziona: cosa facciamo?”.

Vorrei quindi dirti, caro amico e cara amica che mi segui assiduamente, che non c’è mai una soluzione sicura per tutti i problemi. Il mio consiglio resta sempre lo stesso: analizzare il tuo punto di partenza, testarlo con gli utenti, fare refinement e poi semmai a/b testing e ottimizzazione.

Perché il tuo sito è sempre diverso dagli altri (specialmente per gli utenti). E a parte alcune best practice consolidate, tutto cambia così velocemente che l’unica soluzione è il testing/refinement continuo della user experience dei tuoi clienti.

Dimentichiamoci quindi delle best practice: testare è l’unico modo per dormire tranquilli la notte.

È una situazione piuttosto comune. Ne parlavamo anche nei commenti al mio post sull’usabilità per il turismo. Secondo la ricerca che citavo, l’aumento dei costi porta all’abbandono da parte del 43% degli utenti.

Sulla validità di questo dato credo che molto dipenda dal tipo di servizio e dalla motivazione degli utenti, ma è chiaro che l’esperienza negativa è forte e ha conseguenze anche sui futuri acquisti.

Il consiglio sarebbe quindi di evidenziare subito tali costi all’inizio del processo oppure direttamente compresi nel costo del viaggio. A questo punto però c’è da chiedersi: quanti utenti non acquisteranno perché c’è un aumento dei prezzi?

È quello che chiamo paradosso della conversion:  spesso scopro che durante un processo di acquisto c’è un’informazione che porta al blocco degli utenti, i quali chiedono che venga specificata con più chiarezza all’inizio. Solitamente però i clienti frenano: far vedere subito i costi nascosti può limitare gli acquisti da parte di tutti gli altri utenti.

Infatti, spesso se l’utente investe del tempo nell’acquisto, alla fine ci pensa due volte prima di mandare tutto a monte. Questa è la situazione ideale, ma i dati dimostrano il contrario. Soprattutto, ripeto, gli utenti non sono stupidi, sono persone: in futuro ci penseranno due volte prima di tornare ad acquistare in un certo sito.

Comunque, per evitare di peggiorare la conversion, come prima cosa si dovrebbero sperimentare diverse soluzioni (in A/B testing, per esempio):

• commessione specificata chiaramente
• commissione compresa nel prezzo
• altre variazioni.

Sicuramente, conta moltissimo il copywriting e consiglierei un link a una pagina o popup che spiega in dettaglio il perché dei costi aggiuntivi.

In ogni caso, credo che la cosa migliore sia la chiarezza e probabilmente conta molto il riuscire a ribaltare in postivo le condizioni negative per l’utente (sembra un paradosso anche questo, ma è principalmente copywriting).

Per esempio, un sito potrebbe utilizzare la chiarezza come un fattore distintivo rispetto ai competitor: “L’unico sito che ti dice subito chiaramente tutti i costi”.

Comunque è un terreno piuttosto minato e va percorso a piccole modifiche, testando e ritestando, come insegna Amazon.

Hai mai avuto esperienze su questo tema? Idee, suggerimenti che vuoi condividere?

Una volta superata la barriera del prezzo, l’usabilità del sito ha un’importanza notevole sull’acquisto, basta vedere quali sono i motivi che hanno portato all’abbandono da parte degli utenti:

Certo più che di usabilità parlerei di vera e propria esperienza dell’utente. E soprattutto, qui stiamo parlando di utenti che hanno già deciso un acquisto.

La user experience comincia però dal momento in cui l’utente atterra nel sito: a partire dall’interesse alla ricerca di informazioni, dalla comparazione alla scelta del prodotto, fino al carrello e al processo di acquisto.

Purtroppo è un aspetto trascurato, ma se si vuole aumentare seriamente le conversion bisogna investire in tutta l’esperienza utente: dall’inizio alla fine. E “in largo”, soprattutto, perché l’utente rinchiuso nel funnel è un sogno dei manager.

Il tarlo mi è venuto da quando con Jacopo abbiamo lavorato a un progetto impostando il lavoro di scrittura delle user story partendo dagli scenari utente. Da poco ho scoperto che questo metodo è stato chiamato User story mapping (da leggere sull’argomento: “Usage-centered user stories & story mapping”, parte 1 e parte 2)

L’idea di “agganciare” le user story agli scenari è piuttosto importante poiché sono convinto che sia il trait d’union tra design e sviluppo, soprattutto nella fase iniziale (ne ho parlato anche al RomeCamp2008).

Un punto importante è che secondo me gli scenari dovrebbero essere individuati prima della stesura delle user story, attraverso la ricerca con gli utenti e la produzione dei personaggi.

Insomma, fin qui tutto ok, nel senso che ormai ne parlo da un po’ di tempo e sono quindi argomenti noti.

Negli ultimi mesi però ha iniziato ad aleggiare questa idea di Jacopo sulle #AugmentedUserStory: l’idea di associare un wireframe alle user story, o viceversa.

In effetti, quando facciamo up-front design è possibile derivare le user stories direttamente dai prototipi digitali o dai wireframe. In questo modo, oltre ad avere una descrizione testuale delle funzionalità da implementare, c’è anche una rappresentazione visuale a supporto.

Ma il punto è proprio questo: perché parlare di rappresentazione visuale “a supporto” delle user story?

Perché non parlare invece di “augmented design” inteso come tutto quello che può servire a specificare meglio il design di un prodotto digitale?

In fondo è già quello che facciamo quando cerchiamo di comunicare il design e che Dan Brown ha ben descritto nel suo libro chiamato appunto “Communicating design“.

Per fare un esempio Doralab ormai impostiamo i progetti seguendo un processo di questo tipo:

• analisi e ricerca con utenti
• produzione di personaggi e scenari
• design e prototipazione
• test e verifiche con utenti.

Gli scenari guidano il processo di design e quindi tutti i deliverable (user journey, concept maps, page flow, wireframe, prototipi, …), oltre ai test con gli utenti, seguono l’impostazione a scenari.

Viene dunque automatico pensare di basare la scrittura delle user story e il lavoro di sviluppo sugli scenari, anche per dare coerenza al planning delle varie release (possiamo cioè basarci sugli scenari anche nel decidere quali storie dobbiamo implementare per il prossimo rilascio).

A questo punto, la descrizione del design è completa: per ogni scenario ci sono una serie di wireframe/pagine che vengono descritte nel dettaglio attraverso le user story.

Ecco, tutto questo lo chiamo “augmented design”, perché stiamo sostanzialmente lavorando per arricchire il lavoro di progettazione, dettagliarlo, descriverlo meglio. Per favorire il lavoro di sviluppo, ma anche “viceversa”

A parte le considerazioni sui problemi inerenti la privacy, trovo interessante la visualizzazione, che può essere utilizzata anche in fase progettuale.

Certo basterebbe una tabella, che forse sarebbe anche più chiara. Però la tabella ha poco appeal, mentre il modello a spicchi d’arancia ha riscosso un bel po’ di tam-tam in rete.

Come spesso accade, gli stessi dati in un formato diverso catturano un interesse maggiore. Insomma, questa è capace che funzioni anche coi manager.

Avendo solo mezz’ora ho dovuto sintetizzare, ma spero di aver detto comunque qualcosa di sensato. Di seguito trovate le mie slide e come al solito spero di ricevere il vostro feedback.

L’evento è stato molto interessante (300 persone e decine di talk) e mi ha permesso di parlare a un pubblico che di solito non raggiungo.

Complimenti ai ragazzi di Develer, che hanno fatto un gran lavoro con un’unica pecca: alcune sale erano un po’ troppo piccole e diverse persone non sono riuscite a entrare per seguire il mio workshop.

Alla scuola elementare c’erano i platani piantati da mio padre. Quando lui era piccolo, gli studenti della scuola ogni anno piantavano un albero a primavera. La chiamavano “festa degli alberi” e l’ho sempre trovata una cosa fantastica. Ho piantato alberi anch’io alcune volte, che emozioni.

In ogni posto dove ho vissuto a Padova, durante gli anni dell’università, ricordo i platani: sul lungo Piovego, in centro, perfino nel cortile dell’appartamento storico in cui ho abitato per anni.

Per questo ho un rapporto di affetto con i platani, ci sono sempre stati nella mia vita.

Quando ritrovo un platano, è più forte di me: spesso li accarezzo, ci parlo, li conforto. Quando vedo che tagliano dei platani, sto male anch’io, soffro come loro.

(Sembra stupido, ma ho capito di non essere pazzo quando ho letto il primo e unico libro vero di Mauro Corona: Il volo della martora. O forse sono matto come Mauro, chissà).

Di recente ho cercato di mitigare la lontananza dei miei adorati platani furlani coi faggi dei Lucretili, che passo spesso a salutare.

Insomma capite, è un legame forte quello che mi lega agli alberi.

Per questo non posso che essere in perfetta sintonia con Renzo Piano e la sua visione della città degli alberi:

Mi sono sentito dire che gli alberi in un contesto urbano hanno bisogno di terra per le radici, e gliela abbiamo data. Mi sono sentito dire che gli alberi in città soffrono, e abbiamo trovato il modo di farli stare bene. D’altronde, se soffrono gli alberi figuriamoci la gente e i bambini. Mi hanno fatto notare che alcuni alberi provocano allergie, e abbiamo selezionato piante che non emettono pollini. E poi che perdono le foglie, e bisogna raccoglierle: giusto. E poi che coprono le insegne dei negozi: vedete voi. E infine, che rubano spazio ai parcheggi per le automobili. E su questo hanno ragione: gli alberi prendono inevitabilmente il posto dei parcheggi e del traffico automobilistico. Ma è proprio quello che ci vuole: questo è l’aspetto più importante, nella visione umanisticamente corretta delle nostre città nel futuro. Occorre assolutamente salvarle dal traffico e dall’enorme quantità di parcheggi che le stanno soffocando. Più parcheggi si fanno e più traffico si attira, come la fisica insegna. Alcune città più dotate di trasporti pubblici l’hanno capito: a Londra è vietato costruire parcheggi in centro, a Stoccolma per disincentivare l’uso dell’auto una fermata del tram non è mai più lontana di trecento passi, e se il mezzo non arriva entro venti minuti il passeggero mancato ha diritto al taxi gratis. Occorre mettere tutte le risorse per costruire trasporti pubblici e dotare le nostre città di parcheggi di cintura. È chiaro che gli alberi in città hanno un ruolo importante in questa visione. C’è chi, cinicamente, dice che questo non avverrà mai. Scommettiamo che sì? È ormai inevitabile: spendiamo meno in parcheggi e sottopassi, e investiamo nel traffico pubblico.

Sottoscrivo tutto, parola per parola.