Ho seguito i feed, i giornali (solo i titoli, che il resto su iPhone è a pagamento) e i socialcosi senza interagire, come se ricevessi dei telegrammi da oltreoceano e ci volesse del tempo (o della voglia) per poter rispondere.

Non è un paragone forzato. Nell’era dei media digitali, in Italia questo agosto hanno tenuto banco le lettere.

Quella di Anderson (Wired) in cui si teorizza che il web è morto, mentre internet è viva e vegeta. Secondo me è una forzatura e ci sono anche alcuni errori grossolani di valutazione che da Wired US non mi aspettavo.

Ne ha già parlato Luca e non ho molto da aggiungere, se non che probabilmente non ha più senso parlare solo di web, ma di “esperienze digitali”, intendendo un insieme che va dal web al mobile, passando per tutte le piattaforme di fruizione (touch/no-touch, netbook/portatili, desktop, smartphone, ebook reader, ecc). Detto questo, il web continuerà ad essere sempre il fulcro dei contenuti, specie quelli informativi e di comunicazione, imvho.

Poi le lettere politiche, quelle di Bersani e Veltroni. Contrapposte a quella di Anderson (che parla comunque del futuro) mi paiono lettere che vengono dal passato (e in effetti Veltroni parla del passato), che non abbiamo faticato a seppellire nella poca sabbia che ci è rimasta attaccata alle scarpe dopo il mare. La morale è che Veltroni ha perso, basta. Bersani=D’Alema, quindi basta. E con questi qui, nemmeno in 10k anni riusciamo a vincere le elezioni (aveva ragionissima Moretti).

Poi è quasi successa una crisi in parlamento, con Fini protagonista, ma alla fine ancora non è successo granchè. Forse si andrà alle elezioni, forse no, intanto questo paese sopporta, sopravvive, galleggia mollemente (scusa se scado nelle metafore vacanziere).

Però.

In fondo al tunnel c’è ancora un lumicino, una parte di Italia che mi piace, con la quale mi trovo ogni giorno a chiacchierare, ridere, lavorare. Ecco, sto cercando di focalizzarmi su questo, sperando che funzioni.

Insomma, buona ripresa anche a te.

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.

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.

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:

• Search patterns: l’abbiamo letto di recente e discusso al Rome UX Book Club
• Search analytics: forse quello più interessante perché parla dell’analisi delle ricerche interne (e non vedo l’ora che esca).

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.