Alberto Mucignat

Sempre con riferimento al tema della velocità, segnalo che Google Analytics ha integrato in maniera trasparente l’analisi velocità del proprio sito (via @pierotaglia).

Il report di velocità di GA è sicuramente importante per capire quali pagine hanno dei problemi, ma per un’analisi più approfondita esistono anche altri tool, tra cui il plugin Yahoo!Slow (che ho usato spesso) e Google Page Speed Service (mai utilizzato, ma sembra interessante).

Un post odierno di Econsultancy mette al primo posto la user experience assieme alla velocità del sito tra i 10 motivi che migliorano le conversion sulle landing page:

1. Provide the best experience
We like to use the phrase, “think humans and the robots will follow”. This means providing the best possible experience for your users in terms of site navigation and usage etc. Speed is becoming a growing factor not only in the Google algorithm, but tests by Google and by Amazon indicate users are increasingly using speed as a determining factor in where to purchase.

Lo segnalo perché dell’importanza della velocità nella user experience ne ho parlato molte volte (ultimamente in relazione alla sua importanza maggiore in campo mobile), ma anche perché lo ritengo sempre di più un parametro chiave che però ha un problema: è poco controllabile dal punto di vista del design, perché dipende sostanzialmente dall’area IT/sviluppo.

In ogni caso, è sempre più difficile distinguere la velocità dalla user experience e viceversa. Lo vedo nei test con gli utenti che facciamo, ma lo potete immaginare anche voi pensando alla vostra esperienza: la velocità dei siti e dei servizi web è componente fondamentale della user experience.

Inoltre, da tempo il web viene naturalmente comparato ai prodotti desktop e alle app nel caso mobile. Se pensiamo anche solo a quest’ultimo canale (le cui connessioni sono ancora piuttosto instabili, specialmente in viaggio e durante gli spostamenti), la velocità -e la user experience complessiva- gioca un ruolo fondamentale per la competitività.

Insomma, è importante, quindi lo ripeto: mettete la velocità al primo posto delle priorità lato sviluppo. Punto e basta.

Da qualche tempo il look di Gmail e dei prodotti Google è cambiato. Non senza qualche reazione stizzita, compresa la mia.

La cosa interessante è che in realtà il team di Gmail ha monitorato costantemente le reazioni degli utenti e ha corretto l’interfaccia di conseguenza.

In realtà, ieri (giorno dell’usabilità mondiale) è uscito un post molto bello che spiega come il team di Gmail abbia fatto test di usabilità per un lungo periodo prima di rilasciare il prodotto.

In particolare viene introdotto un tipo di test e osservazione degli utenti definito “Longitudinal study” che consiste nel ripetere il test con le stesse persone nel tempo:

As we continued to develop the new look, we evaluated our progress through additional usability studies with even more people. Much of what we captured from these studies was users’ first reactions to the new look. But Gmail is something people use repeatedly, not just once. So in addition to first impressions, we were also interested in seeing how people adjusted to the new look as they used it repeatedly in their daily lives. To find that out, we conducted a different kind of study called a longitudinal study. Longitudinal studies are used to observe the longer term effects our products have on people’s usage.

The longitudinal study consisted of turning on the new look for a group of Gmail users. We captured their initial reactions after their first experience. Then we let them use the new look in Gmail as they normally would as part of their everyday lives. As the days and weeks passed by, we periodically checked with them to see how they were adjusting to all the changes. Like with anything new, there were some changes that our participants initially needed time to adjust to, but later came to prefer as they used the new look more. On the other hand, problems that were not seen during the first couple times of use later emerged after more prolonged use. For example, many of the changes we made to the new left navigation were the result of people reporting their repeated experiences using labels and the chat area over time.

È un tipo di ricerca indicata quindi per prodotti il cui uso è prolungato nel tempo. Tuttavia, quasi tutti i servizi web che hanno un minimo di loyalty ricadono nella categoria.

Il fatto di utilizzare sempre gli stessi utenti secondo me ha due grandi pregi:

• rispetta l’evoluzione (e la “formazione”) degli utenti all’interno del servizio
• fa emergere i cambiamenti nell’utilizzo e fornisce insight per definire la UX del primo utilizzo e dell’utilizzo avanzato
• consente di scoprire i problemi durante gli utilizzi evoluti, che altrimenti non sarebbero emersi con un singolo test.

Mi è già capitato di utilizzare questo tipo di test in alcune ricerche, anche se devo dire che in pratica facevamo solo 2 sessioni di test: in una sessione verificavamo l’utilizzo di fronte alla novità e dopo un periodo di tempo testavamo il comportamento avanzato, consapevoli del fatto che gli utenti avrebbero nel frattempo acquisito informazioni ed esperienza con l’interfaccia.

Tuttavia qui si tratta di una cosa diversa: seguire un gruppo di utenti nel tempo, pianificare periodici test e osservare come cambiano ed evolvono i comportamenti.

Oggi Davide Casali ha scritto un post sulla lentezza del feedback della UI di Android. Ho già scritto diverse volte a proposito dell’importanza della velocità delle interazioni, ma il caso del mobile è ancora più emblematico.

Va detto che Android non può “controllare” l’hardware su cui gira, a differenza di Apple. Ma vorrei andare oltre Android e l’intreccio hw/sw. Penso a tutti i siti e le app mobile in genere, e faccio una considerazione più generale: se nel pc di casa/lavoro accettiamo forse un po’ di lentezza, su mobile la velocità è condizione necessaria.

Il tempo di una persona via mobile è sicuramente più parcellizzato e gli stimoli sono molto più rapidi e molto più sensibili al cambiamento rispetto al desktop. Per questo è necessario che la responsività dell’interfaccia sia immediata.

Convengo con Davide anche sulla chiosa finale: una delle cose più difficili è far capire ai clienti l’importanza della velocità. Un po’ perché di solito io lavoro con il Marketing, mentre è l’IT ad avere la responsabilità della performance. Un po’ perché la velicità è sempre considerata una “cosa tecnica”, che però ha effetti incredibili sulla user experience.

Insomma, per me la velocità è uno dei punti principali che hanno effetti sull’usabilità e la user experience in genere. È purtroppo un punto che i designer non riescono a controllare, ma è prioritario curare questo aspetto ed è compito nostro farlo presente a chi di dovere.

Emilio Simonetti mi segnala che è uscita la versione 2011 delle linee guida per i siti della pubblica amministrazione (ne avevo scritto qui), aggiornata grazie anche ai contributi emersi dalla consultazione pubblica.

Devo dire che a grandi linee mi sembra ricalchi quella dell’anno scorso, ma Emilio mi precisa:

Con riferimento particolare al tema dell’usabilità, non mancano rilevanti aggiornamenti, come quello relativo al “Piano di usabilità”. La nuova disposizione chiede che le amministrazioni considerino l’usabilità non più un intervento sporadico, ma una azione articolata e programmata, volta a realizzare in modo più incisivo la qualità dell’interazione dei cittadini con le interfacce web.

Non ho idea dei dati, però tra 2010 e 2011 sarebbe interessante sapere quanti progetti della PA hanno seguito queste linee guida (in particolar modo riferite all’usabilità). Raramente mi trovo a lavorare per la pubblica amministrazione (è in parte anche una mia scelta consapevole), quindi sono abbastanza curioso.

Dulcis in fundo: c’è anche un forum per discutere di usabilità per la PA, bella iniziativa.

Il Corriere Economia lancia oggi la notizia che Dacia inizierà a vendere le auto online, per la prima volta in Italia, per aprire il mercato europeo della vendita di auto online. Ora, al di là della novità della notizia mi chiedo: ma non avviene già?

Da qualche settimana anch’io ho acquistato una nuova auto, seguendo questi step:

• mi sono informato online sulla macchina che mi piaceva: ho confrontato diverse vetture nei siti dei produttori, visto tutte le foto possibili, mi sono informato nei forum a proposito dei problemi comuni, ecc
• sono andato in concessionario e ho visionato la macchina
• il venditore mi ha chiesto se volevo degli optional e mi ha suggerito, visto che avevo già visto la macchina online, di configurarla direttamente nel sito del produttore e di inviargli il pdf del modello configurato
• sono andato sul sito e ho configurato la vettura, poi ho inviato il pdf
• mi hanno inviato il preventivo e abbiamo proceduto all’acquisto.

Insomma, gran parte dell’acquisto è stato svolto online: la decisione dell’acquisto l’ho presa da solo online, non è stata forzata dal venditore, che ha solamente capito che macchina volevo e mi ha emesso il preventivo basandosi sugli optional che mi sono scelto.

Molti clienti probabilmente già fanno così, lo dimostra il fatto che il venditore non era per nulla sorpreso e mi ha anzi esortato ad andare sul sito a configurarla come volevo.

Quante case automobilistiche si rendono conto del potenziale della cosa? Oggi internet è un alleato fondamentale per vendere, di fatto l’online fa parte del comparto vendite, con un ruolo forse più diretto di quanto non si pensi.

Da qui in poi possiamo solo iniziare a capire come dovrebbero cambiare comparti marketing/commerciali di queste aziende: non più siti vetrina, ma investire nell’acquisizione del cliente.

Alcuni consigli? Ecco qua i primi che mi vengono in mente (mi baso su un paio di siti che ho utilizzato, ma parliamo di case automobilistiche piuttosto importanti):

• spesso esistono molti modelli/allestimenti delle stessa auto: offrire la possibilità di comparare in modo semplice i modelli/allestimenti, anziché nascondere i dettagli dietro sigle incomprensibili, che hanno senso solo per far sembrare cool le brochure patinate o per sembrare fighi nelle riviste del settore
• i configuratori sono spesso veramente fallimentari: lenti, fatti in flash, incliccabili, difficili da usare anche per un esperto, ecc. Ci vuole una pazienza e una determinazione di ferro per usarli.
• salvare/scaricare una configurazione non è mai banale, ritrovarla dopo qualche tempo richiede una mentalità zen e capacità quasi magiche (passando per registrazioni impossibili)
• seguire le pratiche online è ancora una chimera (ma, ripeto, non ho analizzato tutti i siti, ma solo un paio di produttori).

La nota positiva è che ci sono ampi margini di miglioramento, per chi li saprà cogliere. Se serve una consulenza, siamo qua.

A Doralab stiamo cercando interaction designer per attività di prototipazione di siti e servizi web/mobile. La sede di lavoro è Roma.

Se interessato, invia il CV a info@doralab.it. Prima però leggi bene tutto il resto qui sotto.

No part-time o lavoro a distanza, per piacere se non sei interessato a un lavoro a tempo pieno in sede da noi evita di mandare il cv.

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)
• conoscenza dei tool di comunicazione della user experience (flow chart, wireframe, sitemap, …)
• esperienza con strumenti di reportistica (PowerPoint, Keynote)
• esperienza di web design (html/css/js) e dei nuovi standard (html5/css3)
• 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 copywriting

Costituiscono titolo preferenziale

• laurea o diploma in design
• portfolio misto web/mobile
• precedenti nel settore tipografico
• esperienza di conduzione test di usabilità

Ultima nota: noi siamo un studio di progettazione e design, quindi sappi che non troverai una grande struttura, ma un ambiente umano dove si lavora assieme. 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.

Il nuovo sito di iCloud è decisamente un esempio di design mobile first, ovvero di iniziare a pensare i siti web prima per il mobile, adattandoli successivamente al web tradizionale. In realtà non so se sia proprio nato in questo modo, però l’idea è quella.

Anche il visual secondo me è molto bello: non è mai facile realizzare una semplice pagina di login con tutto quello spazio vuoto, chiedete a un designer. Probabile che anche l’interfaccia interna (a cui per ora hanno accesso solo gli sviluppatori) sarà mobile ready.

(Peraltro mi immagino un’azienda italiana, vedendo tutto quel vuoto: “Mettiamoci i banner di upselling! Promuoviamo i nuovi iMac!” ecc ecc.)

Comunque, guardate cosa succede se “tagliamo il vuoto”:

L’interfaccia sembra realizzata apposta per il mobile. I tasti e le form sono molto più grandi, prendono tutto lo spazio orizzontale. Perfino gli alert sono progettati con il look&feel di iOS:

In ogni caso il mobile first è una tendenza che per alcuni tipi di servizi può avere molto senso. Certo, a parte Apple, i normali siti non si possono permettere di avere un look&feel puramente iOS, altrimenti si tagliano fuori tutto il mercato Android (che è cospicuo e sta crescendo notevolmente, più del mercato iOS a seconda dei punti di vista).

Personalmente credo che l’approccio mobile first abbia molto senso per i mercati business o quelli in cui l’utente/cliente ha un flusso continuo tra web-mobile e viceversa. Quelli che, come me, passano dal desktop al cellulare, poi al notebook, all’ipad o al tablet, ecc, diverse volte nel corso della giornata.

Un’occhiata alle statistiche vi può dare un’idea di quanti siano questi utenti, ma anche se fossero pochi sono sicuramente degli utenti molto particolari (e fidelizzati) per cui bisogna iniziare a considerarli come veri e propri personaggi del nostro sito.

In generale, però, in futuro il passaggio sarà una cosa normale, per cui l’approccio mobile first dobbiamo iniziare a considerarlo fin da oggi per tutti i siti a cui lavoriamo (ma penso anche alle intranet e ai servizi b2b).

A intervalli regolari qualcuno mi chiede come fare per diventare UX designer o formarsi sui temi della user experience.

Qualche tempo fa ho segnalato suggerimenti e risorse per diventare UX designer, ma per una volta sono felice di poter segnalare un’attività formativa che reputo seria e di livello.

Gli amici del Dipartimento di Psicologia de La Sapienza di Roma hanno organizzato un Master sulla user experience che si terrà il prossimo anno.

La cosa interessante è che ci sono i contributi regionali che possono essere richiesti per farlo gratuitamente (variano da regione a regione, a quanto pare).

Insomma, se ti interessa iscriviti oppure segnalalo.

Lunedì sono stato a Better Software, dove ho parlato di lean ux, che è un po’ l’evoluzione dell’agile ux in chiave startup (ma non solo). Le slide sono disponibili da qualche giorno su slideshare, ed eccole qua:

Aggiungo a margine alcune considerazioni, anche per consentire a chi non c’era di analizzare le slide.

UX e Lean (slide 4-6)

Da quando ho iniziato a interessarmi al tema Lean UX mi è subito apparso chiaro come la user experience lavorasse su un concetto di valore simile a quello del pensiero Lean. Intendo che entrambe elaborano un concetto di valore con un ragionamento molto simile.

L’idea di focalizzarsi sul testimone e non sui corridori della staffetta è un esempio che vorrei aver inventato io. In realtà fa capire molto bene l’assurdità di alcuni metodi di gestione dei processi (direi “fordisti”) che tendono a ottimizzare riducendo le persone a oggetti che devono produrre velocemente e sempre con più efficacia. E questo vale moltissimo anche per chi lavora al design di prodotti digitali.

Dobbiamo quindi iniziare a concentrarci sul valore che viene deliverato anziché sull’ottimizzazione maniacale dei tempi e delle risorse. E nel caso della UX il valore è proprio quell’incrocio di interessi tra business (che realizza un prodotto sostanzialmente per guadagnarci) e utenti/clienti del prodotto (che valutano il valore del prodotto in base all’esperienza d’uso che ne ricavano).

Evitare gli sprechi? (slide 8-10)

Spesso al metodo Lean viene erroneamente associato il concetto della riduzione degli sprechi. Non è proprio esatto: il lean si concentra sul miglioramento continuo, che presume anche una ricerca degli sprechi, allo scopo di poterli ridurre. Viene cioè insegnato al personale come individuare gli sprechi nel loro lavoro.

Questo non presuppone una ricerca top-down degli sprechi, ma un continuo focus sull’ottenere il massimo valore con il minimo sforzo, che ogni persona svolge durante il proprio lavoro.

In realtà, io sono convinto che la UX abbia contribuito ad eliminare molti sprechi: le pratiche di design della UX hanno consentito di focalizzarci sul prodotto finale fin dalle prime fasi di idezione. Sketch delle pagine, wireframe e prototipi hanno progressivamente portato le aziende a ridurre le pile di documenti a favore di deliverable più “agili”.

Ma la “rivoluzione” è stata ancora più raffinata. Comunicare visivamente ci ha infatti permesso di evitare molti piccoli sprechi negli interstizi dei progetti: incomprensioni tra sviluppatori e designer, decine di mail di spiegazioni, interpretazioni errate di una frase, correzioni in post-produzione, ecc.

Infine, esiste un limbo, che è quello della generazione delle idee di design, dove lo spreco deve essere proprio coltivato: solo dalla molteplicità delle idee che riusciamo a generare possiamo scegliere la più adatta. E subito dopo dobbiamo iniziare a togliere: andare all’osso dell’idea, semplificare, togliere il superfluo.

In Aviator c’è una scena in cui Hughes/Di Caprio osserva il profilo della fusoliera di un aereo e dice qualcosa tipo: “tutti questi ribattini: via!”. A me questa immagine piace pensarla ispirata da Saint-Exupery, che pure era un amante del volo:

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

La morale è che si può arrivare a questo punto solo se si lavora cercando il miglioramento continuo del prodotto.

Cicli di lavorazione (slide 11-13)

L’idea che sta alla base della Lean UX è che il lavoro procede a cicli, con 3 fasi per ogni ciclo: build (costruisci), validate (verifica) e learn (impara).

Per noi che facciamo UX è un processo abbastanza noto: prototipazione, testing, debrief. In effetti, molte pratiche della UX sono completamente allineate al processo ciclico.

La cosa interessante è l’utilizzo di questo ciclo da parte delle aziende.

Un primo consiglio (slide 12) è quello di iniziare con una fase di discovery (quella che in passato, nel mio talk su Agile UX, avevo definito “Iteration 0″) che aiuti a creare un embrione del prodotto. Questa fase, nella mia esperienza, può anche essere più lunga di quanto si pensi, poiché è sicuramente necessario uno studio del mercato e uno studio del comportamento degli utenti.

Un secondo aspetto (che non ho trattato nella mia presentazione) è quello della gestione del team di lavoro. Spesso ci sono team di design e sviluppo separati. Altre volte ci sono agenzie esterne che si integrano nel processo. In queste situazioni la gestione del team diventa fondamentale per la buona riuscita del progetto.

La visione della UX (slide 14-16)

In tutto questo lavoro ciclico c’è la necessità di mantenere una visione coerente, che solo la pratica dello user-centered design può fornire.

Anzitutto, dobbiamo considerare alcuni livelli (layer) della user experience (a cui ne aggiungo uno post-presentazione):

• si parte dalla UX strategy: qual’è la vision, la strategia di design del nostro prodotto? (e questa deve essere centrata sul valore massimo tra business e utenti)
• personaggi e scenari: ci aiutano a trasformare la vision in scenari reali e ad applicarla a pattern di comportamento reali(sono forse il primo reality check)
• user stories: sarebbero i task dello user-centered design (cioè i task che possono essere svolti dagli utenti/clienti) e sono delle unità minime di rappresentazione della user experience
• iteration planning: è il momento in cui si decide cosa deve fare l’applicazione nelle sue varie versioni di rilascio.

Una chiave di volta del processo è la relazione tra scenari e user stories che ho già descritto in un post su Augmented design.

La visione d’insieme dovrebbe far capo al designer della UX: scenari, collocazione delle user story, ecc, derivano direttamente dalla strategia e dalla UX vision.

Solitamente l’iteration planning è un momento cruciale in cui si decide la pianificazione dello sviluppo. Si decide cioè quante e quali user story verranno realizzate in ogni iterazione di sviluppo.

In un contesto puramente agile, in cui anche il design è inserito nei cicli di lavoro, è necessario che all’iteration planning siano presenti anche dei designer. In realtà, l’iteration planning è proprio un’attività di design del prodotto (si decide come si evolverà il prototipo del prodotto), quindi secondo me chi decide l’iteration plan è anche UX designer.

Voglio dire: è importante che iniziamo a pensare all’iteration planning non solo come un momento di pianificazione risorse/tempo, ma anche come un momento chiave in cui si decide l’evoluzione del prodotto e la sua UX. Per questo è necessario che questo step sia facilitato da un responsabile della UX, che deve validare la roadmap e gestirne le eventuali modifiche successive (che ci saranno, se siamo veramente agili).

Lean UX: convergenza tra business, design e sviluppo (slide 17-19)

Il punto è che siamo in un momento storico in cui il business, il design e lo sviluppo stanno convergendo tutti verso pratiche comune:

• piccoli team cross-funzionali che collaborano a stretto contatto
• metodi di gestione informali e leggeri (wiki-like)
• cicli rapidi di lavorazione
• focus sull’utente/cliente finale.

Questo aspetto di convergenza è dato anche dalle pubblicazioni (vedi slide 7) che in questo periodo si stanno susseguendo su questi temi.

Per me, in questo momento storico, la figura chiave che può garantire il massimo del valore è un “designer della UX contaminato con il business“.

Alcuni (tipo Cooper) hanno proposto il concetto di “Product Stewardship”, in cui ci sono 2 figure responsabili di prodotto: Product manager (business side) e Product Steward (design/development side).

In realtà, il mio auspicio è che anche in Italia si inizi a pensare a figure come “Head of UX”, al posto dei vari marketing o product manager. In effetti oggi l’esperienza È il prodotto, ma se i manager non lo capisco il rischio è che facciano fallire il design dei prodotti.

Propongo quindi alcune condizioni di partenza per uno “UX Product Manager” o “Head of UX”:

• responsabile ultimo della UX di prodotto: nessuno oltre a lui ha più potere in merito)
• investire continuatamente nelle persone (scelta, formazione continua, mentoring)
• ricerca maniacale del miglioramento continuo (iterazioni e retrospettive con il team)
• equivalente a un C-level: se vogliamo che abbia peso nelle decisioni, non può essere un semplice quadro
• budget: iniziamo a prevedere un budget specifico per la UX? cosa ne dite di partire dal 10% del budget adv?

Comunicare i cambiamenti (slide 20-26)

Per andare un po’ sul pratico e abbassare un po’ i toni della mia presentazione, ho inserito una serie di esempi sul tema della comunicazione e dell’introduzione dei cambiamenti nelle interfacce. È un tema su cui conviene investire sempre di più per far percepire la coerenza di visione all’utente/cliente finale e “formarlo” a un utilizzo consapevole e pieno dell’interfaccia.

Una considerazione a margine è che mentre questo aspetto si è molto evoluto su web, nel caso delle app mobile è ancora difficile capire dove e come sono cambiate le cose a seguito di un upgrade.

Riflessioni finali

Sempre di più mi trovo a fare delle presentazioni e percepire di aver dato una visione d’insieme che ha delle radici profonde: sono temi su cui ragiono e lavoro da anni, che mi appassionano e che mi piace condividere.

Spero di aver comunque puntualizzato gli aspetti che non ero riuscito (per mancanza di tempo o di opportuna dialettica) a spiegare nel mio speech.

Tuttavia mi rimangono alcuni punti aperti su cui ragionare e lavorare ancora:

• il design dev’essere embeeded all’interno dei team di sviluppo?
• come possiamo fare in modo che le agenzie esterne o i consulenti riescano ad integrarsi meglio con i team di sviluppo senza perdere la testa o senza diventare un collo di bottiglia?
• com’è possibile rinunciare al design up-front e fare invece vero design incrementale?
• e infine: com’è possibile mantenere una visione d’insieme (pensate al puro visual design) durante cicli di lavorazione rapidi?

Infine, vi lascio con una riflessione di Tim McCoy (di Cooper.com):

Lean UX is not interaction design shoehorned into agile frameworks. Product vision, user research and modeling, and truly evolutionary iteration are central to this approach. It stresses lightweight, collaborative, right-fidelity UX techniques to generate, test, and evolve the design of your product.

E noi (parlo anche di me e della mia azienda) siamo pronti a questo passaggio?