Alberto Mucignat

L’usabilità conta almeno il 30% della fedeltà del cliente verso il prodotto che usa e, di conseguenza, l’azienda/brand.

È una delle Top 10 research-based usability findings of 2010 di Measuring Usability (un sito da tenere d’occhio perché coniuga usabilità e numeri, quindi materiale utile per argomentare con i manager).

Tra gli altri finding miei preferiti:

• I test non moderati hanno risultati piuttosto simili a quelli classici (si intende quei siti che si offrono di testare in modalità remota il vostro sito con gli utenti). In effetti è un nuovo strumento che stiamo provando anche noi.
• Gli utenti sono in grado di trovare il 50% degli errori rispetto agli esperti di usabilità. Questo significa che chiedere agli utenti di descrivere i problemi che hanno con un prodotto digitale è un modo economico per avere delle informazioni preziose (senza contare che il più delle volte questi problemi sono già noti al call center o a chi si occupa di CRM).
• La valutazione di un sito dopo solo 5 secondi è la stessa anche dopo 10 minuti. In pratica l’utente capisce in pochi secondi se il sito è facile da usare o meno. È uno strumento che ho già utilizzato e in particolare è molto utile per landing page e homepage.

Beh, che dire: buon anno!

Ricordo che un mio amico manager IT in Silicon Valley mi raccontava come uno sviluppatore bravo scrivesse in media 4-5 nuove righe di codice al giorno. Sembrano poche, ma se proiettate su mesi/anni di lavoro, 4-5 righe di codice al giorno sono tante: all’inizio scrivi molto codice, poi inizi a cambiarlo e man mano che vai avanti fai piccole correzioni ai bug, riscrivi piccoli pezzi, ecc.

Nel design c’è un processo simile, specialmente per quel che riguarda il copy: si cambiano testi, si migliorano labeling e microtesti, pulsanti, posizioni, si allarga un po’ di qua, un po’ di la, si sposta sopra o sotto, o si allinea in maniera diversa. Comunque, guardando alla big picture, le modifiche sembrano poco influenti se comparate alla struttura della pagina definita inizialmente.

Ecco, una volta impostata la struttura è difficile cambiarla. Nello sviluppo si definisce il framework, si imposta il codice, si definiscono le classi principali. Nel design si definisce la struttura del sito, la navigazione, il layout della pagina, le griglie principali. Una volta definiti questi aspetti (se sono impostati bene) rimangono piuttosto stabili per tutto il progetto.

A ben pensare anche la scrittura di un libro è molto simile (almeno credo, visto che mi ci sono appena messo): fissi una scaletta e inizi a scrivere all’interno di quella struttura, cambiando le frasi, ri-editanto, spostando paragrafi e riorganizzando pezzi di contenuto.

E chissà in quanti altri campi si fissa una struttura e poi fanno/disfano micro parti: penso alle arti, alla musica, alla produzione di oggetti, agli inventori, ai tecnici elettronici, a chi crea nuovi prodotti… (il mio agilista preferito direbbe che solo chi costruisce opere fisiche, una volta decisa la struttura e iniziato a costruire, non può più cambiare per un problema di costo del cambiamento).

Ma insomma è un pattern: potremo differenziare i cambiamenti tra micro-cambiamenti e cambiamenti strutturali.

È relativamente facile gestire i primi, il problema è quando si arriva a dover cambiare, in parte o totalmente, la struttura principale. È un investimento che tutti tendiamo a preservare, anche solo perché ci siamo affezionati, ma spesso arriviamo a un punto in cui capiamo che c’è una oggettiva difficoltà a fare i piccoli cambiamenti, perché è la struttura generale a non andare più bene.

Ecco, questo è un momento delicatissimo e bisogna fare scelte che spesso sono dolorose e costano. Ma che libertà poterlo fare.

Dopo molti tentennamenti (e le pressioni di qualche amico) per quest’anno mi sono posto l’obiettivo di scrivere un libro sui temi della user experience, user-centered design, ecc. Non so se ci riuscirò, dati gli impegni sempre più fitti, ma vorrei perlomeno provarci.

In questo periodo sto raccogliendo le idee e sono già a buon punto, ma mi chiedevo: secondo te di cosa dovrei parlare?

Altre domande: quale aspetto della progettazione della user experience ti interessa di più? Quale aspetto è meno conosciuto nelle aziende con cui lavori?

E ancora, ben sapendo che ci sono già diversi libri sul mercato: ci sono argomenti che sono ancora trattati poco? Oppure che sono stati trattati fin troppo?

Grazie in anticipo.

Ecco, oggi Jacopo ha postato una perla che voglio sottolineare e di cui riporto il primo paragrafo perché è importante:

Un committente crede che tu ed il resto del tuo team di sviluppo possiate semplificare per delega, grazie ai metodi agili, il suo lavoro. Lui crede che possiate prendere il suo canovaccio, espanderlo nei dettagli, metterlo in piedi e portarlo pronto in tavola. Molti credono – come lui – che i metodi agili siano uno stupendo scenario in cui sponsorship illuminate da un’idea fulgida possano premere il pulsante rosso di veloci e precisi missili fire-and-forget che andranno a colpire il bersaglio del successo senza ulteriore necessità di azione e pensiero, certe volte addirittura senza alcun rischio d’impresa, “tanto facciamo tutto agile, no?”

Questo ragionamento è un capolavoro anche perché si può sostituire “UX” al posto di “agile” e “design” al posto di “sviluppo” senza perdere di senso, anzi guadagnando un ulteriore tassello.

La morale è che troppo spesso i clienti si aspettano che facciamo tutto da soli partendo dal canovaccio (che sarebbe il “brief” di cui un giorno parlerò, abbi pazienza).

Purtroppo però, lavorare sulla user experience, sul design di un prodotto, sul suo sviluppo, ecc, richiede dedizione anche da parte dei clienti, non solo da parte dei fornitori.

Da parte nostra forse dovremo ragionare sull’esperienza che diamo ai clienti e cercare di capire come coinvolgerli in maniera efficace e senza fargli perdere tempo inutile, perché il punto spesso è proprio questo.

Scopro solo ora una ricerca di Scott Berkun fatta nel 2008 sulle cause che portano al fallimento del design (via UX Movement).

Le due cause principali sono:

• Non-designer che prendono decisioni sul design
• Manager senza basi di design che prendono decisioni sul design.

Da notare che il 49% degli intervistati sono manager o gestiscono dei team nelle aziende.

Ora, personalmente anch’io credo ci sia un problema quando un manager entra a gamba tesa e decreta un cambiamento nel design senza avere una minima idea di cosa comporti, semplicemente perché “secondo lui bisogna fare così”.

E non parliamo di colori o stile, parliamo spesso di interazioni, struttura e testi delle pagine: in questo caso per proporre dei cambiamenti pertinenti occorre avere approfondite nozioni di design.

C’è da dire che nei prodotti digitali il business viene fatto attraverso il design, quindi è necessario (ripeto: necessario) coinvolgere manager e stakeholder nel processo di design.

C’è una frase della presentazione di Berkun (pdf, 6MB) che mi è rimasta impressa:

“In many organizations, design is not seen as a critical thinking skill, it is thought of as a process for execution once the hard decisions are made.” -Designer

Ecco, questo è forse un punto importante: vedere il design come una pura e semplice execution del business è un errore clamoroso. Il design È business, specialmente nel caso dei prodotti digitali (ricordate: The experience is the product).

Per concludere, ai manager/stakeholder (non designer) vorrei porre alcune domande:

• è possibile determinare delle “regole business” e accettare che vengano realizzate da chi ha competenze specifiche nel design?
• è possibile lavorare in modo che alcune decisioni di business vengano prese durante la fase di design?
• è possibile anche cambiare le decisioni business per supportare un design più innovativo?

E un consiglio ai designer: cercate di capire quali sono gli obiettivi e le regole del business, perché il “gioco” del design è proprio quello di riuscire a creare un prodotto efficace per il business (altrimenti si chiama “arte” e i vostri prospect sono le gallerie, le case d’aste e i filantropi collezionisti).

“No idea is simple when you need to plant it in somebody else’s mind.” (Inception, 2010)

Nell’immaginazione degli stakeholder (clienti, product owner, manager, ecc) ci sono due concetti che dobbiamo indagare e conoscere molto bene:

• l’idea che si sono costruiti del loro prodotto (specialmente per i nuovi progetti o i redesign)
• l’immagine ideale che hanno (o sognano di avere) dei loro utenti.

Li potremo chiamare il Castello (il prodotto, il sito, l’applicazione, il servizio) e il Principe (l’utente). Nella testa degli stakeholder questi due elementi sono chiarissimi e funzionano alla perfezione.

Il Castello è bellissimo e viene costruito nel tempo con pazienza e immaginazione: è fortificato e inattaccabile, bellissimo e imponente, tanto da dominare la vallata (i competitor stanno a valle, nelle baracche e nel fango). C’è voluto tempo per idearlo e non è facile dimostrare che si può costruire diversamente: per lo stakeholder il Castello è bellissimo così com’è.

Il Principe è nobile, perfetto, infallibile. Si muove a suo agio nel Castello, anche se talvolta si perde perché è stato consigliato male. Ad ogni modo, il Castello è il miglior posto costruito appositamente per lui, in base alle sue precise caratteristiche.

Può sembrare una forzatura pensare in questi termini all’idea di progetto e di utente, ma provate a spostare una pietra del Castello o fare una critica al comportamento del Principe e vedrete i risultati.

Sono due immagini difficili da attaccare e dalle quali il cliente non vuole distaccarsi. E spesso questa idea viene protetta così bene da essere perfino negata (“ah, dei nostri utenti sappiamo poco e niente”, “siamo aperti a tutte le idee, non abbiamo un’idea particolare del sito che vorremmo”).

Ma non è finita qui. E se i clienti non fossero gli unici a costruirsi un castello in testa? Anche i designer hanno i loro sogni e adorano difendere il loro castello e il loro principe.

Qual è la morale della storia?

Alla fine non ci sono né castelli né principi, spesso c’è semplicemente una piccola persona che cerca di compilare una form e non ci riesce.

“Do not try to bend the spoon — that’s impossible. Instead, only try to realize the truth: there is no spoon.” (The Matrix, 1999)

Da anni ormai predico contro la richiesta dei clienti a ricevere dei mockup del sito in fase di offerta. La richiesta è talmente assurda che ancora mi stupisco quando risuccede. Eppure alcune aziende e specialmente la pubblica amministrazione continuano imperterriti con questa richiesta, che per quanto mi riguarda continuerò a non soddisfare.

Non so nemmeno perché le web agency continuino a sopportare questa richiesta, credo fondamentalmente per incrementare la possibilità di prendere il cliente stupendolo con “effetti speciali”. Salvo poi dover mantenere le promesse attraversando un probabile bagno di sangue.

In realtà, ci sono alcuni motivi per cui i mockup in fase di offerta sono un’idiozia:

1. prima di capire come fare un mockup bisogna progettare la struttura del sito e definire i singoli elementi delle pagine, altrimenti cosa ci metti nel mockup? (basterebbe questo, ma andiamo avanti)
2. il visual design dipende dal mood, dai benchmark, dalla ricerca, ecc: tutte cose che non si possono fare con l’input di un semplice brief (*)
3. una volta presentato un mockup tutto il resto del lavoro deve riuscire a confermarlo, altrimenti come spieghi una grafica finale diversa da quella proposta all’inizio?

Potrei andare avanti, ma preferisco fermarmi.

Ma il vero motivo per cui tutti ci dovremmo rifiutare di fare i mockup prima dell’offerta è che il visual design è un lavoro per il quale dobbiamo essere pagati e che non si può inventare all’inizio tanto per ammorbidire e rassicurare il cliente.

Voglio dire, è come se chiedessimo a un architetto di farci vedere un’immagine ad alta risoluzione della casa prima ancora di conoscerne il progetto.

Forse per il cliente è un modo per capire la qualità della web agency. Purtroppo la qualità non si vede da un semplice mockup, anche perché il design è un lavoro di profondità e inizia molto prima della superficie colorata. Scegliere un’agenzia basandosi sui mockup è un po’ come scegliere una macchina con una bella carrozzeria senza avere la minima idea di come sono fatti gli interni.

Insomma, per concludere lancio il “Movimento contro i mockup pre-contrattuali”, sperando che abbia un seguito nutrito e che cambi una pessima abitudine del mercato.

E ai clienti chiedo: preferite un carrozziere o un designer? Cercate qualcuno che vi tinteggi la casa o un architetto?

(*) poi un giorno farò un post anche contro le offerte basate sui brief: come si può fare un’offerta dettagliata, addirittura dei mockup, avendo parlato mezz’oretta con qualcuno che spesso non è nemmeno un manager?

Segnalo un lavoro di Davide Bolchini (ricercatore universitario a Indianapolis) che mi ha sbloccato un problema piuttosto noto che semplifico: come rappresentare le esigenze business del cliente durante la raccolta dei requisiti (o, di solito, durante un brief veloce con i manager)?

In effetti spesso ci troviamo nella situazione in cui gli obiettivi business di un progetto sono completamente diversi da quelli dell’utente. Come risolvere questa contraddizione o, come la chiama Davide, questa tensione tra obiettivi dei clienti e degli utenti?

Nel paper “Exploring the tension between User’s and Main Stakeholder’s goals: the role of Client Scenarios” (pdf) Davide ci propone la sua ricetta:

Client Scenarios [...] allow modeling main stakeholder’s goals in relationship to (and not separately from) the requirements for the user experience.
[...] a client scenarios describes what main stakeholders want the user to do on the website.
[...] client scenarios are thus key intruments during analysis that allow stakeholders to project their own goals on the desired user experience, this making these goals much more concrete and visible as requirement-design input.
[...] main stakeholders have their own expectations with respect to the behavior of the user. The want the user to do preferably certain tasks, rather than others, and this is fundamental to meet the communication and business objectives of the main stakeholders.

In pratica si tratta di riuscire a portare il cliente a definire degli scenari che descrivano quello che si vorrebbe che l’utente facesse per soddisfare un obiettivo business.

Esempio: se un cliente ha l’obiettivo di vendere più prodotti per ogni cliente, uno scenario semplificato potrebbe essere “l’utente deve essere invogliato ad acquistare più prodotti” o qualcosa del genere.

Questo approccio non è affatto semplice, perché nella mia esperienza un cliente di solito:

1. dichiara un obiettivo business (“aumentare le vendite”, “migliorare la percezione del brand”, …)
2. non ha idea di come immaginare uno scenario utente che porti al raggiungimento dell’obiettivo
3. si aspetta che designer/web agency/whatever si occupi di far raggiungere l’obiettivo agli utenti.

Riformulo per essere più chiaro: il cliente e/o il manager spesso ha un’obiettivo business in mente e pensa che sia un nostro compito quello di tradurlo in qualcosa che l’utente faccia (la fantomatica “interazione”), salvo poi criticare random le soluzioni proposte. L’idea è di coinvolgerlo in questo processo di “traduzione” degli obiettivi business in un formato user-side, per stabilire un’idea chiara e condivisa su come dovrà funzionare il sistema per l’utente.

Forse l’idea dei client scenarios non è nuova e magari qualche “agile expert” mi dirà che esisteva già uno strumento del genere. Rimane il fatto che solo oggi, dopo anni, mi è chiaro come lavorare per riuscire a tirarli fuori da un meeting iniziale con il cliente.

D’ora in poi quando mi diranno “voglio migliorare la percezione del brand”, la mia risposta sarà: “e come ti immagini uno scenario di un utente che cerca di migliorare la sua percezione del vostro brand?”. La difficoltà sarà di non accettare la risposta “questo dovete dirmelo voi, è per questo che vi paghiamo”: l’obiettivo è definirlo assieme al cliente (ecco è questo il punto a cui volevo arrivare, se ti eri un po’ perso).

Per concludere, questo modello si incastra perfettamente con l’idea agile di spezzettare il progetto in scenari e user stories: i client scenario vengono introdotti e si integrano completamente con gli altri scenari. Da quel momento in poi sono scenari uguali agli altri e il processo di lavorazione rimane lo stesso, però garantisce di essere focalizzati (anche) sui reali obiettivi business del cliente.

Consiglio comunque di leggersi il lavoro di Davide e anche le altre sue ricerche. E ne approfitto per ringraziarlo qui pubblicamente per i contributi di qualità che ci ha messo a disposizione.

ps: qualcosa di molto simile l’ho trattato parlando di come impostare inizialmente un progetto e di come definire le priorità di un progetto. Poi ci sono altri miei post sul tema agile-ux.

L’amico Federico ha scritto alcune riflessioni sul ruolo dell’architettura dell’informazione (e più in generale della UX) con uno sguardo verso il futuro.

In generale sono d’accordo con lui e in qualche maniera tutto il ragionamento si ricollega al mio post di venerdì a proposito di pervasive ux.

Ma a un certo punto Federico fa un passaggio che è una trappola a cui dobbiamo stare attenti:

Oggi un’azienda spende 10 per comunicare attraverso un sito, poi ancora 10 per la versione mobile, poi ancora 10 per l’applicazione iPad, eccetera eccetera. Dobbiamo convincere questa azienda che domani, grazie al nostro lavoro, spenderà 10 per un’architettura centrale, poi 2 per il sito, 2 per il mobile, 2 per l’applicazione iPad. E se sarà sempre lo stesso architetto dell’informazione (che è anche UX designer) a progettare queste interazioni, l’azienda avrà anche la garanzia che siano usabili. [Nota: naturalmente i numeri di questo esempio sono indicativi e non corrispondono ad una stima effettiva]

Prima osservazione: non è detto che con un buon lavoro di IA/UX basta spendere 10 per un’architettura centrale e poi si spende poco per ogni declinazione. Non è detto che sia vero perché i vari media sono piuttosto diversi e richiedono un tipo di lavoro diverso, sebbene l’investimento iniziale porta un oggettivo guadagno.

Ma il rischio vero è un altro: si vede l’architettura dell’informazione come un costo da limitare. Io invece penso che la pratica del design della user experience sia centrale nei progetti e debba diventare un costo necessario che aggiunge valore ai progetti e sul quale bisogna aumentare gli investimenti.

Oggi ogni progetto digitale non può più prescindere da questo fatto e la maggior parte degli sforzi deve essere indirizzato a ottimizzare la user experience per fare business (che siano pagine viste, vendite o altro tipo di conversion).

Per esempio, cosa succederebbe oggi se in molte aziende venissero a mancare i progettisti web? Chi pensa a come far navigare gli utenti, a come farli interagire con il prodotto/servizio, quali informazioni fargli ricercare e in che modo, ecc?

Servono persone qualificate e specializzate per questo lavoro, sul quale bisogna investire, non tagliare costi. Voglio dire: questo È il lavoro del futuro, perché è questo che richiede il commercializzare dei prodotti/servizi digitali nell’era di internet.

Serve che le aziende capiscano che la user experience richiede manutenzione così come la richiede il software. E che il budget per questo lavoro non possono essere poche briciole rispetto ai budget di comunicazione.

Racconto una storia, iniziando con un piccolo test: che idea hai delle Poste italiane?

L’idea che la maggior parte degli italiani ha delle poste è piuttosto negativa. Questo perché l’esperienza con le poste è quasi sempre difficile e poco piacevole: la coda, la lentezza, la complicatezza, i ritardi nelle spedizioni, ecc.

Tuttavia le Poste italiane sono un’azienda pazzesca: tengono in piedi le comunicazioni fisiche in Italia (pensate alla mole dei pacchi, lettere, pagamenti che passano per le poste), oltre a rendere disponibili una miriade di servizi in ogni piccolo paesino d’Italia. Inoltre, negli ultimi anni la qualità dei servizi è aumentata.

Purtroppo è un’idea difficile da accettare completamente, almemo per me, perché la mia esperienza con le poste, fin da quando ero piccolo, è sempre stata prevalentemente negativa. Per quanto mi riguarda, ogni volta che penso di dover andare alle poste mi viene un fastidio che è difficile da descrivere, quasi viscerale.

Voglio dire che per il cliente l’immagine dell’azienda equivale all’esperienza derivata dell’uso dei prodotti/servizi. E se un’esperienza si protrae per lungo tempo, è un’idea difficile da sradicare: l’immagine dell’azienda verrà sempre associata a quel tipo di esperienza.

Ecco perché quando oggi sento ancora parlare (solo) di immagine coordinata, trovo che le aziende stiano continuando a lavorare su un concetto che è ormai ampiamente superato. Le aziende dovrebbero smetterla di cercare di imporre un’immagine aziendale e dovrebbero invece lavorare a migliorare l’esperienza che i loro prodotti e servizi forniscono agli utenti.

Non voglio dire che l’immagine coordinata sia un concetto sbagliato. Sono fermamente convinto che sia importante una coerenza visiva nella comunicazione aziendale, ma l’immagine aziendale è un concetto piuttosto vago nella testa dei clienti, mentre l’esperienza è fisica, tangibile, molto più concreta e difficile da scalfire.

Le aziende dovrebbero quindi lavorare mettendosi dalla parte dei clienti: come faccio per fornire il miglior servizio ai miei clienti sui diversi canali?

La potremo chiamare “esperienza coordinata”, oppure Pervasive User Experience: progettare per fornire un’esperienza efficace e coerente attraverso diversi canali.

Un esempio banale è oggi la versione web e mobile di un sito: oggi non è più possibile avere un sito mobile scadente perché gli utenti se ne accorgono facilmente, l’esperienza d’uso nei due canali deve essere coerente. Questo è dovuto anche al fatto che, per gli utenti i diversi canali si equivalgono dal punto di vista aziendale: ai clienti interessa poco se un’azienda non ritiene strategico il mobile, loro vogliono gli stessi servizi su ogni media che utilizzano.

Un punto di partenza è iniziare a lavorare a ritroso: dovremo progettare l’esperienza dell’utente (ad esempio come interagisce una persona che entra in un ufficio postale) e poi riprogettare l’organizzazione aziendale per supportare quella esperienza.

Questo aspetto ha un duplice problema: da una parte l’accettazione che il prodotto/servizio di valore diventa l’obiettivo aziendale (ma va?) e dall’altra la difficoltà di “piegare” l’organizzazione aziendale per supportare i cambiamenti iniziali e periodici che richiede la manutenzione della user experience.

È un cambiamento radicale, una rivoluzione per il business che come progettisti della user experience dobbiamo iniziare a portare.

ps: di esperienze multicanale ne parla anche il Multichannel Customer Experience Report di Econsultancy, nel quale si legge che “tre quarti delle aziende intervistate riconosce una stretta correlazione tra le perfrormance di business a lungo termine e la customer experience”.

pps: sull’argomento gli amici Resmini/Rosati hanno appena finito di scrivere un libro (Pervasive IA) che spero leggeremo presto nel nostro Rome UX Book Club.