Finite le ultime cose, da domani mi ritiro un po’ in friuli (montagne arrivo!) per poi proseguire verso altri luoghi nascosti in mezzo al mare.
Nelle ultime settimane ho battagliato con un trasloco, lavori di ristrutturazione, ben 4 matrimoni nei giorni di solleone, chiusura di progetti, stress e stanchezze varie, ecc. Le ultime fatiche le ho rivolte a strutturare Doralab per i mesi che verranno dopo agosto: da settembre sarà veramente impegnativo e ci saranno delle novità interessanti per il mercato italiano 
In questo periodo mi sono ritrovato spesso solo, a pensare a quello che sto facendo e al futuro. E ringrazio i pochi con cui riesco a confrontarmi (i miei collaboratori, i partner, gli amici): credo di avere attorno delle belle persone che stanno facendo un gran percorso, nonostante viviamo in un paese che cerca sempre di metterci i bastoni tra le ruote.
Insomma, caro lettore del blog (dicono che siate sempre più rari) ti lascio con un pensiero che ho letto qualche giorno fa nel blog del Folletto. Davide cita un articolo sulla solitudine e leadership tratto da una lettura di un professore a West Point, dal quale io ho tratto le mie personali considerazioni, as usual.
A parte le approfondite analisi su Cuore di tenebra (con il parallelo su Apocalypse now, di cui sono un esperto maniacale), trovo molto interessanti le osservazioni di Deresiewicz sulla necessità di solitudine per riuscire ad elaborare un pensiero critico e ragionare su noi stessi.
Per una volta non faccio citazioni, l’articolo è uno di quelli che va letti e basta.
Posso solo dire che stamattina, mentre facevo colazione da solo nel terrazzo nuovo, ho guardato il cielo e ho immaginato di essere in un bivacco di montagna. E ho capito perché mi fa bene andare in giro per le mie montagne: perché mi aiuta a lavorare sulla “solitudine dei pensieri”, che è una cosa piuttosto importante per chi fa il mio lavoro.
Insomma, amico lettore, avrai capito che son cotto e ho bisogno di riposare per ricaricare le pile. O forse ho solo bisogno che Oli torni dalla germania
Comunque sia, ci si rilegge a settembre. Buone vacanze anche a te.
A Doralab stiamo cercando interaction designer per attività di prototipazione di siti e servizi web/mobile.
Siamo in un periodo di sviluppo dell’azienda e quindi siamo interessati sia a figure junior che senior. La sede di lavoro è Roma.
Se interessato, invia il CV a info@doralab.it. Prima però leggi bene tutto il resto qui sotto.
Interaction designer
Si occupa di progettare, prototipare e documentare l’esperienza d’uso degli utenti per servizi web/mobile lavorando in team con figure di Information Architect e Usability Analyst. Il candidato ideale ha esperienza di almeno 3 anni in web agency e utilizza tool visuali di prototipazione rapida (es: Visio, Omnigraffle, Axure).
Requisiti richiesti
- esperienza di almeno 3 anni come designer (5 per le figure senior)
- solide basi di basic design (layout, cromatologia, griglie, tipografia, etc)
- buone doti di disegno a mano libera (sketching e wireframing)
- conoscenza dei tool di comunicazione della user experience (flow chart, wireframe, sitemap, …)
- conoscenza strumenti di reportistica (PowerPoint, Keynote)
- esperienza di web design (html/css/js)
- conoscenza della lingua inglese
Altre conoscenze e attitudini richieste
- conoscenza dell’ambiente Mac OS X
- conoscenza Adobe CS (Photoshop, Illustrator, InDesign)
- esperienza in ambito mobile
- capacità di sintesi
- buone doti di copywriting
- cura dei particolari
Titoli preferenziali
- laurea o diploma in design
- portfolio misto web/mobile
- esperienza con i test di usabilità
Ultima nota importante: noi siamo un piccolo studio di progettazione e design, quindi sappi che non troverai una grande struttura, ma un ambiente umano dove si lavora assieme, in team, veramente. Se sei uno a cui piace lavorare da solo o fare il “genius designer” lascia stare, grazie.
Se interessato, invia il CV a info@doralab.it.
Econsultancy ha pubblicato il report sul site search (a pagamento), ovvero sulla ricerca interna ai siti. Riporto uno stralcio che trovate anche nel summary del report (pdf gratuito):
The most widely perceived advantage of effective site search is a better user experience, with 83% of companies saying this is a “major benefit”. Increased site usage and increased sales are the next biggest benefits. Two-thirds (65%) of respondents say more site usage is a major benefit, and 64% say additional sales is a key advantage.
Insomma, lavorare sulla ricerca interna aiuta a migliorare le vendite/conversioni e quindi ad aumentare il business.
Detto questo, della ricerca interna ho parlato di recente e vedendo il report ho scoperto che molte aziende (nel mondo) trovano importante la ricerca interna al sito.
Tuttavia le attività di miglioramento della ricerca si concentrano sul miglioramento del motore di ricerca (ah, sempre il software!), mentre l’analisi delle query di ricerca interne è una pratica poco diffusa. Eppure, secondo il report, questa attività porta enormi benefici alle aziende:
- consente di mappare i trend e i prodotti più ricercati (e far emergere quelli meno ricercati)
- consente di conoscere le preferenze degli utenti
- è utile per migliorare l’usabilità del sito
- può essere una base per le campagne SEO/PPC
- aiuta a mappare i termini utilizzati nelle landing page
- è utile per una ulteriore segmentazione degli utenti.
Infine, tra i motivi per cui è difficile migliorare la ricerca interna, troviamo:
- mancanza di conoscenza ed esperienza: non si conoscono i benefici e gli effetti di un investimento sulla ricerca interna
- mancanza di budget per migliorare l’usabilità e il design.
Sul tema della ricerca interna, di recente sono apparsi due libri, ognuno dei quali scritto dai due co-autori del mitico Polar Bear:
Oggi il buon caro Jacopo ha riesumato un post di quattro anni fa con un commento che mi ha fatto ripensare a come oggi lavoriamo su wireframe e prototipi. È un tema di cui ha parlato anche Ilaria sollevando delle domande interessanti in coda al suo post.
A proposito di wireframe e prototipazione ho scritto nel tempo diverse cose:
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?
Da tempo discuto con il mio intranet-guru Giacomo Mason se abbia senso o meno progettare le intranet, visto che ci sono dei software preconfezionati (che lui chiama “Sharepoint e i suoi fratelli”) che sono belli e pronti (almeno così dicono le brochure).
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.
Da tempo i massimi esperti di usabilità mondiale sostengono che l’utente su web non legge, ma scansiona la pagina alla ricerca delle informazioni. L’ho sempre considerato anch’io un comportamento assai comune, a causa del quale bisogna progettare e scrivere i contenuti in maniera efficace.
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.
Nel mio ultimo post ho descritto un paradosso della conversion nel caso di siti di prenotazione viaggi. Dopo aver letto le esperienze di quelli che hanno commentato (soprattutto su friendfeed) continuo a pensare che sia importante dichiarare subito i costi, ma bisogna anche testare e andare avanti a piccole modifiche. Ma soprattutto il parere degli utenti è fondamentale, specialmente se volete fare un business che duri nel tempo: nel mondo dei servizi online la user experience sarà sempre più determinante.
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.
Immaginiamo una persona che vuole prenotare un viaggio aereo attraverso un sito. Cerca e clicca sul viaggio più economico. Inizia il processo di acquisto, compila tutti i suoi dati e alla fine, poco prima di pagare, scopre che il prezzo ha subito un aumento di 10 euro per le commissioni del sito.
È 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?
Un report sull’usabilità dei siti di turismo (via Andrea Cappello) riporta un dato interessante, che rilancio perché ho parlato spesso di usabilità legata all’ecommerce.
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.
Apro un ciclo di pensieri su quello che provo a definire augmented design: trattasi della capacità di rappresentare un prodotto digitale usando una combinazione tra il formato visuale e quello testuale.
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”
