Come migliorare il processo di acquisto

Sono fortunato. Negli ultimi anni ho avuto la possibilità di partecipare alla progettazione e realizzazione di alcuni tra gli e-commerce più importanti nati in Italia.

È bello, interessante e istruttivo lavorare per un e-commerce, perché il sito non è fine a sé stesso, ma a supporto della vendita e non solo deve funzionare, ma deve funzionare bene, benissimo.

Per chi lavora nel campo della user experience un sito di e-commerce presenta anche delle opportunità uniche per proporre e mettere in cantiere dei miglioramenti e verificarne immediatamente il risultato.

Tra le diverse aree di un sito di e-commerce mi piace mettermi al lavoro sul processo di checkout perché rappresenta una vera e propria sfida dove ogni testo, etichetta, bottone deve essere limato e lucidato per bene. Il processo di checkout è infatti composto da funzionalità che svolgono il duplice scopo di proporre al cliente (o, almeno, si spera lo diventi!) delle precise informazioni sulle operazioni che sta per compiere e di ricevere informazioni su come desidera concludere l’acquisto.

Avere la possibilità di compiere sessioni di multivariate testing a un processo di checkout penso sia un’esperienza che ogni specialista di user experience dovrebbe provare.

In più di un’occasione mi sarebbe piaciuto parlarne in un intervento, ma l’argomento è complesso e un articolo di pochi paragrafi, ma anche il capitolo di un libro rischiano di banalizzare o non far apprezzare l’attenzione e le strategie necessarie per la progettazione e verifica di un processo di checkout che funzioni in tutti i suoi aspetti.

Anche la stesura di una o più checklist di riferimento (di cui sono innamorato) ha poco senso, se non con un documento di dettaglio a corredo.

Ecco perché preferisco consigliarvi due interessanti report che si concentrano sul processo di acquisto approfondendone ogni dettaglio.

Il primo è E-Commerce Checkout Usability, scritto da Jamie Appleseed e Christian Holst del Baymard Institute. Si basa su sessioni di usability test che hanno coinvolto 10 utenti durante la navigazione di 15 siti di e-commerce: 1-800-Flowers, AllPosters, American Apparel, Amnesty Shop, Apple, HobbyTron, Levi’s, NewEgg, Nordstrom, Oakley, Perfume.com, PetSmart, Thomann, Walmart e Zappos.

Il risultato sono 63 linee guida raggruppate in 6 categorie (data input, copywriting, layout, navigation, flow, focus) che in 140 pagine affrontano con ricchezza di esempi, positivi e negativi, il processo di checkout. Alcune indicazioni sono sicuramente note a chi si occupa di user experience (come la progettazione dei form, argomento tra l’altro molto ben affrontato da Luke Wroblewski in Web Form Design), altre sono forse meno scontate.

Peccato che tra i molti esempi presentati pochi siano dedicati alla pagina del carrello, visto che logicamente è strettamente e strategicamente correlata al processo di checkout ed è forse la più importante dell’intero processo.

Interessante invece l’inclusione in appendice di 4 pagine di una checklist pronta da stampare.

Il report costa 78 dollari.

Il secondo studio che vi voglio presentare è E-commerce User Experience, vol. 4: Shopping Cart, Checkout and Registration realizzato da Amy Schade e Jakob Nielsen per il Nielsen Norman Group (e, quindi, non c’è bisogno di molte presentazioni). Il report fa parte di una serie di altri 13 report dedicati all’e-commerce, ma è comunque acquistabile singolarmente per 98 dollari.

E si tratta comunque di soldi ben spesi, perché gli autori non lesinano linee guida e esempi, tanto che il report di estende per più di 300 pagine ricche di screenshot, tabelle di approfondimento e best practices.

In questo caso il report nasce da una versione precedente del 2000 (di cui sono rimaste alcune linee guida) a cui sono stati aggiunti in questa nuova versione i risultati di user testing e eye tracking di utenti in più città europee, americane e asiatiche.

Rispetto al report del Baymard Institute, quello del Nielsen Norman Group risulta più approfondito e quindi richiede sicuramente un certo impegno per essere studiato in tutte le sue parti anche perché spesso le indicazioni più interessanti non stanno tanto nella linea guida in sé, ma nei dettagli presentati nel testo.

Non si può comunque definire un report noioso da leggere, visto che gli autori citano spesso le espressioni degli utenti sottoposti al test (giusto per fare un esempio: “That’s really a pain in the ass”).

Quale dei due report acquistare? Se non vi spaventa studiare più di 300 pagine, il report del Nielsen Norman group è sicuramente approfondito e dettagliato, ma se vi interessa un report comunque ricco di esempi, e con una comoda checklist pronta da stampare ed applicare, il report del del Baymard Institute rappresenta un’ottima alternativa, che vi permette anche di risparmiare qualche dollaro.

Progettare con la carta

Da qualche mese sto sperimentando con soddisfazione uno strumento diverso per quella fase di progettazione che segue la definizione della strategia online e precede la creazione di prototipi. Prendo un foglio di carta e realizzo a mano bozzetti che possono poi essere condivisi e valutati insieme al team di User Experience.

Nulla di nuovo o che non avessi mai provato, ma che avevo abbandonato troppo frettolosamente ritenendola una pratica poco professionale.

Mi hanno aiutato a cambiare idea due letture: Paper Prototyping di Carolyn Snyder e il più recente Prototyping scritto da Todd Zaki Warfel per i tipi di Rosenfeld Media. Entrambi i testi forniscono ottimi suggerimenti su come realizzare prototipi con la carta e il libro di Carolyn Snyder arriva anche a spiegare come utilizzare questi prototipi in veri e proprie sessioni di test di usabilità con gli utenti.

Non mi spingo quasi mai, con la carta, fino alla fase di creazione dei prototipi. La carta mi aiuta a fissare sottoforma di bozzetti (sketch) diverse idee di interfaccia e interazione che possono poi essere valutate, scartate, scelte insieme al team UX. Si tratta quindi di un approccio quantitativo, che mira a produrre in tempi molto brevi diversi bozzetti che possano poi essere analizzati dal team e soprattutto criticati senza la paura di aver mandato all’aria ore o giorni di lavoro. Ogni bozzetto non dovrebbe richiedere più di mezz’ora per la stesura.

Trovo l’uso della carta efficace anche lavorando con team remoti: basta uno scanner e in pochi minuti il bozzetto è condivisibile con il resto del mondo.

Normalmente non uso un foglio di carta bianca, ma mi faccio aiutare stampando dei semplici template che includono l’interfaccia del browser e qualche guida di supporto (per esempio le risoluzione più diffuse). In internet è possibile trovarne decine: personalmente mi trovo molto bene con il lavoro svolto da UIStencil (il template è disponibile in formato PDF).

I diversi bozzetti sono poi criticati insieme al resto del team UX, solitamente fissandoli a una parete o a una lavagna.

Zaki Warfel in Prototyping riassume bene come dovrebbe svolgersi questo processo.

PT001: Figure 2.1Diagram of the iterative design and critique process. Warfel, Todd Zaki. 2009. Prototyping: A Practitioner’s Guide. New York: Rosenfeld Media. http://www.rosenfeldmedia.com/books/prototyping/

Si tratta, come è facile vedere nello schema, di un processo iterativo.

Lo sketching (creazione dei bozzetti) è la parte generativa del processo, il cui obiettivo è proporre diverse idee senza prestare attenzione ai dettagli o alle inconsistenze (fast and furious).

Lo scopo della critica dei bozzetti è quello di trovare, tra le tante idee, la migliore. Chi ha realizzato il bozzetto ne elenca i punti di forza, i colleghi del team UX evidenziano lacune e richiedono approfondimenti. Questa fase dovrebbe durare pochi minuti, perché il dettaglio della proposta avviene nella fase di creazione dei prototipi vera e propria.

A questo punto, cioè per la creazione dei prototipi e per i testi di usabilità con gli utenti abbandono la carta. Preferisco infatti farmi aiutare da strumenti che permettano di simulare un po’ più nel dettaglio le transizioni tipiche di una pagina web, come le interazioni Ajax. In questo senso il mio strumento preferito è Axure RP: costoso, ma che permette di realizzare veri e propri prototipi piuttosto che wireframe, sui quali la carta vince ancora.

Così non va Delicious

Come tutti i web project manager degni di questo nome, ho incubi nei quali il progetto in corso si trasforma in una vera e propria odissea, spesso con le sembianze di una messa online in cui tutto quello che poteva è andato storto.

Questi incubi non si sono per fortuna mai del tutto trasformati in realtà (ho comunque commesso errori), ma purtroppo è quanto è accaduto con il rilascio del nuovo Delicious, il famoso sito di social boomarking di cui sono, o meglio ero, felice utente da anni.

Per i pochi che non lo sapessero, Delicious è un servizio acquisito nel 2005 da Yahoo! e, dopo anni di semi-abbandono, rilevato ad aprile di quest’anno da AVOS System, società dei fondatori di YouTube.

Già da tempo ero a conoscenza della cessione, avendo ricevuto e prontamente risposto a un’email che invitava ad accettare i termini del servizio e la politica di privacy del nuovo proprietario, pena la perdita di tutti i bookmark.

Quello che non mi sarei mai aspettato è di ritrovarmi, il 27 settembre, con un servizio completamente diverso da quello fino ad allora utilizzato, mancante delle caratteristiche basilari e pieno zeppo di errori di funzionamento tanto da sembrare, come ho scritto in Google +, una versione preliminare a uso interno.

Penso sia utile cercare di elencare gli errori principali commessi da AVOS nel proporre il servizio, perché questo tipo di supervisione è uno dei compiti principali del web project manager, anche nel caso di migrazione.

Errori di comunicazione

La prima cosa che mi sono chiesto, visto il risultato, è se fosse proprio necessario andare online con una nuova versione del servizio che stravolgeva la precedente. L’ho inizialmente vista come una mossa per dimostrare che quanto non è stato fatto da Yahoo! in 6 anni di proprietà per l’evoluzione del prodotto, la nuova società è stata in grado di farlo in pochi mesi.

Ho poi scoperto che non si è trattato di un vezzo, ma di una necessità, in quanto gran parte del codice di Delicious si basa su framework interni che Yahoo! non ha ceduto e questo ha richiesto una riscrittura significativa.

Mi sarebbe piaciuto saperlo in anticipo. Sono tornato per scrupolo a leggere l’email che invitava alla transizione, ma che si limita a recitare

To continue using Delicious, you must agree to let Yahoo! transfer your bookmarks and Delicious account information to AVOS

sottintendendo che l’operazione è immediata e si potrà continuare ad utilizzare Delicious, lo stesso Delicious di sempre.

Un po’ di trasparenza in più l’utente se la sarebbe meritata, magari anche solo per compiere un’esportazione di sicurezza, ma soprattutto per capire che avrebbe dovuto mettere in discussione la stabilità del prodotto (back to beta).

Errori di strategia

Siamo sicuri che gli utenti non aspettassero altro che l’introduzione degli “stack”, cioè una collezione di link costruita intorno a una tema comune? Ma, soprattutto, che a favore degli stack sacrificassero altre funzionalità prima presenti come i network di amici, i gruppi di tag, la cancellazione e la possibilità di rinominare i tag? La lista di funzionalità del vecchio sito ancora da migrare è parecchio corposa.

Errori di usabilità

Il problema di un sistema a folksonomy è che tende alla proliferazione di tag utilizzati poche volte. Per evitare in parte questa situazione è sufficiente che il tag venga completato dal sistema mentre si scrive, non fosse altro per evitare la generazione di termini sia al singolare sia al plurale. Ma questa semplice e ormai diffusa caratteristica non fa più parte del nuovo Delicious.

Nella vostra pagina compare l’elenco dei tag ordinati dai più utilizzati ai meno. Da qualche giorno è facile capirlo, perché a lato del tag è indicato il numero di volte che avete usato un tag, ma non era così al lancio. Ad aspettarvi c’era una lista, a prima vista disordinata, di tag, e per di più incompleta: non avevate modo di accedere ai tag meno usati.

Errori di programmazione

Dopo 5 minuti di navigazione nel nuovo sito mi sono accorto di un grave errore: mancava la navigazione su più pagine dei propri link una volta scelto un tag. Mi spiego meglio: se selezionavo “project management” tra i miei bookmark, il sistema mi restituiva la prima pagina con alcuni risultati… senza darmi modo di spostarmi ai meno recenti. Anche questa problematica è stata corretta dopo qualche giorno.

Ancora qualche giorno in più lo ha invece richiesto la correzione di problematiche sia relative alle API (impedendo, di fatto, a servizi terzi di accedere ai contenuti), sia agli RSS e alle procedure di esportazione. Trattandosi in tutti e 3 i casi di comunicazioni verso il mondo esterno, l’impressione di alcuni utenti è stata quella di trovarsi in una stanza in cui c’è un principio di incendio e le porte chiuse a chiave dall’esterno.

Errori di copywriting

Diversi utenti hanno scritto su Twitter di non riuscire più ad accedere alla lista dei propri bookmark. Dopo il panico iniziale, l’arcano è stato risolto. Nella nuova versione non si chiamano più “bookmark”, ma semplicemente “link”. Era necessario modificare questa convenzione?

P.S.: da qualche giorno Fucinaweb ha una pagina in Facebook, un esperimento, ma se avete modo passate per un saluto, vi trovate non solo l’elenco degli interventi di Fucinaweb quando sono pubblicati, ma anche link a risorse e articoli di interesse per chi si occupa di Project Management e User Experience.