Inauguriamo con questo numero della rivista un ciclo di articoli incentrati sul mondo della User eXperience. La definizione di cosa sia la UX e di come si possa incentrare la progettazione dei sistemi su di essa sarà il tema portante della serie, con esempi provenienti dal mondo reale.
Introduzione
Nell’ideare questa serie che tratterà la progettazione basata sull’esperienza utente, ho avuto qualche dubbio, perche‘ ho pensato che il lettore “tipico” di MokaByte probabilmente riterrà l’argomento molto più vicino all’universo dei designerpiù che dei developer. In realtà, però, negli ultimi tempi sulle pagine della rivista sono stati trattati argomenti legati sia al web design che alla progettazione di interfacce, e abbiamo allora deciso di gettare un po’ di luce sulla tematica dell’User eXperience Design cercando di dimostrare, nei limiti della praticità, come certe conoscenze e competenze siano importanti per le varie categorie di personale implicato nella progettazione e nello sviluppo di sistemi.
Progettazione vs sviluppo
In un mercato del software come quello italiano, la distinzione di ciò che è design e ciò che sviluppo è sempre più fumosa. In questo senso, il design basato sull’esperienza utente, significa molto di più di rendere le cose belle o comode o intuitive. La User eXperience (UX) è un dato da cui partire per diverse categorie di “attori” coinvolte nei nostri progetti.
Iniziamo con gli utenti, coloro i quali, in teoria, dovrebbero essere i nostri committenti. Progettare per l’utente e quinti impostare un’intera analisi in questa direzione, è innanzitutto una metodologia e non, come molti potrebbero ritenere, uno step di progetto. Così come le metodologie agili vanno a coprire e rendere più produttiva la fase di sviluppo introducendo dinamiche e best practice, l’User eXperience Design cerca di migliorare la definizione e la comprensione degli obbiettivi di progetto. Questo tipo di metodologia mira a ottenere un risultato solido e resistente, a fronte di requisiti e analisi tradizionali che sono perfettibili.
Attori e strumenti
La pipeline tradizionale di sviluppo prevede che un analista funzionale o un esperto di dominio definiscano e formalizzino insieme al cliente i requisiti dell’applicazione. Questa documentazione poi verrà arricchita e trasmessa ai livelli sempre più alti della catena di sviluppo, dai project manager, agli architetti, ai technical leader fino a giungere agli sviluppatori.
Una documentazione è la concretizzazione di pensieri e concetti, un mezzo che per definizione è soggetto a una lossy compression in termini informativi e soprattutto è sempre soggetto a interpretazione.
Di fatto, gli strumenti che utilizziamo per trasferire conoscenza sono intrinsecamente ambigui e, per quanto possiamo cercare di limitare il problema, non potremo mai evitarlo. Tanto più gli step di produzione sono settorizzati e incanalati in una struttura “a cascata”, tanto più questo risulta evidente.
I bisogni dell’utente
Se risaliamo la catena di responsabilità, però, ci accorgiamo che il problema si trova ancora più a monte: le persone (e quindi anche il nostro cliente) non sono necessariamente in grado di comunicare correttamente quello di cui hanno bisogno.
C’è una famosa frase, attribuita con qualche dubbio al costruttore automobilistico Henry Ford, che comunque rappresenta esattamente questo concetto:
“Se avessi chiesto alle persone che cosa desideravano, mi avrebbero risposto che gli servivano cavalli più veloci”.
È una frase provocatoria, ma che indica chiaramente come spesso il cliente finale desideri solo qualcosa di migliore rispetto a prima, senza essere in grado di cambiare totalmente il paradigma di ciò che viene prodotto.
È inutile e controproducente semplicemente chiedere al committente cosa si deve fare o progettare, per la semplice ragione che le persone sono in grado di descrivere (male) unicamente quello che effettivamente conoscono e non sono assolutamente capaci di discernere fra quello che desiderano e quello di cui hanno effettivamente bisogno.
Con questo presupposto, il sistema tradizionale di analisi fallisce, perchè i requisiti del cliente saranno sempre e inevitabilmente una indicazione fallace o fuorviante del prodotto corretto che si desidera ottenere.
Se vogliamo esasperare ulteriormente lo scenario, ci basta immaginare di aggiungere all’equazione anche un’anima commerciale al team di analisi… In molti penso riconosceranno l’antipattern del: “E questo potrebbe servire?”. “Ma sì dài, perchè no?”. Ecco, poi dobbiamo moltiplicare questo antipattern per n funzionalità aggiuntive/accessorie che incidono per l’80% sull’effort di sviluppo e solo per il 20% sull’effettivo utilizzo (la beneamata regola di Pareto, che alla fine ha sempre il suo empirico valore).
Figura 1 – In questa celebre vignetta, il design di un sistema viene esaminato dai diversi punti di vista. Ciò che effettivamente serve al cliente è spesso “sovradimensionato” da un processo di anlisi inadeguato.
Il design incentrato sull’utente
Il fulcro dell’UX Design e quindi di tutte le discipline User Centered (cioè incentrate sull’utente) è quello di rivoluzionare la fase di raccolta informazioni e dati per non limitarsi a trascrivere i requisiti, ma per comprenderli effettivamente e contrattarli realmente con il committente, senza deciderli a tavolino, ma ricavandoli con strumenti di ricerca e statistica.
Innanzitutto, inizieremo cercando di capire insieme di cosa effettivamente stiamo trattando, tenteremo di fare un po’ di chiarezza sulle terminologie e sui significati delle parole che si usano in questa disciplina e cercheremo di evidenziare le differenze che esistono fra le diverse branche dell’UX Design.
User eXperience, abbreviato in UX, è una buzz word di questi ultimi tempi. Sento continuamente manager, stakeholdere i miei stessi committenti che ne parlano e la invocano come se si trattasse di un nuovo Graal da inseguire a tutti i costi, un po’ come qualche tempo addietro avveniva con buzz word tipo mobile o ancora più indietro, con i termini Web 2.0 e Social (quest’ultima spesso abbinata a un qualche sostantivo).
Che cos’è l’esperienza
Ma che cos’è una esperienza? Si può disegnare una esperienza? Astraendo un secondo dall’ambiente informatico, l’esperienza che ci interessa definire non è altro che la somma di tutti gli aspetti risultanti dall’interazione di una persona con un prodotto, un servizio o un contesto ambientale. La definizione tecnica ci è fornita dalla ISO 9241-210 come: “a person perceptions and responses that result from the use or anticipated use of a product, system or service.”
L’esperienza è tanto più intensa quanto sono forti i momenti di coinvolgimento fra persone e il servizio o il marchio (brand) di un’azienda, tanto più duraturi quanto sono persistenti e vivide le memorie che questi momenti creano.
Una esperienza è una entità così piena di sfaccettature che non può essere definita in valore assoluto positiva o negativa, ma deve essere valutata sempre sulla base di delineati obbiettivi, che sono operativi da parte degli utenti e di business da parte delle aziende. Senza alcun sforzo di conciliazione, questi obbiettivi raramente coincidono; quando invece è ben chiaro dove si vuole arrivare e come, rispondere alle domande “Cosa stiamo producendo?” e “Per quale ragione?” diventa triviale.
Una esperienza è talmente complessa che non si può disegnare nel senso stretto del termine: sarebbe come vivere il sogno di un altro. Però è un qualcosa che si può progettare: se ragioniamo in termini di una trasmissione pianificata di un certo tipo di messaggio, la progettazione di una esperienza significa impacchettare il contenuto del messaggio in maniera tale da renderlo abbastanza poco ambiguo per non essere frainteso e abbastanza libero per essere interpretato e calato nel contesto di ogni ascoltatore.
Visto anche il significato del termine inglese design, quando usiamo il termine “disegnare”, deve essere chiaro che intendiamo sempre “progettare”: creatitivà ed estro sono belle qualità, ma l’Experience Designer deve seguire attentamente precise regole e rispettare certi vincoli. “Progettare esperienze” coinvolge diverse discipline comunicative (dal marketing al corporate branding), e operazionali (dalla customer service alla logistica). Ogni singolo mattone di ogni disciplina, anche legati ad ambiti apparentemente lontati, come la progettazione industriale o l’arredamento d’interni, contribuisce a costruire l’esperienza.
Un esempio pratico è la Ferrari Experience: la casa di Maranello produce automobili da corsa in diverse modelli e colorazioni, ma la Ferrari Experience progettata dalla casa madre è unica e molto distintiva: è fortemente legata al rosso dominante, a un certo tipo di interni che si può riscontrare nei flag store, alla metafora del mondo delle corse che viene ripresa nella linea di abbigliamento, alla storicità del marchio che si riflette sulla terminologia e nei nomi. Il branding Ferrari suscita in tutte le persone la medesima immagine complessiva e questo è tutt’altro che casualità o fortuna.
Figura 2 – La “Ferrari experience” è fortemente legata a una serie di elementi tipici (il rosso, i tipi di interno etc.) adeguatamente combinati per suscitare nelle persone la stessa immagine complessiva.
Sicuramente si tratta di marketing ma, visti i numerosi canali coinvolti, affermare che si tratta unicamente di marketing è quantomai riduttivo. La carattereristica principe di un Experience Design è dunque la multidisciplinarietà e la multicanalità su cui vengono veicolati i messaggi, la cura dei dettagli e, se vogliamo, anche la sottigliezza di questi stessi dettagli che in certi casi neppure la coscienza attiva è in grado di percepire.
Componenti emozionali e culturali
Al di là degli aspetti strettamente funzionali necessari per creare una esperienza, ci sono anche delle componenti, per così dire, “emozionali” oltre che culturali e sociali, che sono importantissimi nel creare una “esperienza utente” [2]
Il sapore di un ingrediente particolare che ci ricorda un piatto della nostra infanzia (vi ricordate di Ratatouille della Pixar?), un rumore a cui non facciamo nemmeno attenzione, ma che porta con sè tutta una serie di significati (ad esempio il rumore dei vecchi tasselli dei tabelloni ferroviari), il profumo della carta stampata che, ancora oggi in epoca di ebook, tutti i “nostalgici” continuano a evocare… Questi sono tutti dettagli che non vengono mai lasciati al caso, ma che vengono con cura selezionati e costruiti per fornire, appunto, un’esperienza.
Siete veramente certi che il materiale della confezione di una nota marca di biscotti di qualche anno fa fosse così spessa e rumorosa esclusivamente per necessità funzionali? Il fatto che il color crema e la rumorosità ricordassero la consistenza e il rumore dei vecchi sacchetti di carta marrone per il pane può davvero essere considerata solo una coincidenza fortunata? Oggi quel tipo di package è scomparso, perchè è scomparsa anche quella fetta di persone che erano in grado di godere a pieno di quel tipo di esperienza: gli adulti di oggi non hanno avuto una storia personale intrecciata con oggetti di quel tipo; acquistare pane e biscotti in una panetteria non è più tanto usuale, nè scontato.
Disegnare esperienze significa sempre attingere alla storia, alle conoscenze, al percorso individuale delle persone per far leva su elementi comuni alla cultura e alla memoria sociale.
È semplicistico quindi ritenere che le strategie che funzionano del “mondo reale” siano inefficaci nel contesto “mondo software”. Nel design e nelle interfacce software siamo comunque dominati dalle meccaniche che ci portiamo dietro dal mondo reale, sotto forma di aspettative d’uso e appigli cognitivi.
L’User Experience
Il termine User Experience (UX) viene coniato da Donald Norman pionere della disciplina nella metà degli anni Novanta [1], nell’era della piena espansione informatica.
Figura 3 – Donald Norman (n. 1935), eclettica figura di ingegnere e filosofo, è l’esperto di scienze cognitive che ha messo a punto la definizione di “esperienza dell’utente”. Il suo approccio iniziale, fondamentalmente funzionalista, è stato in seguito raffinato per far posto alle componenti emozionali del design.
L’User Experience Design è un subset dell’Experience Design: anteponendo il termine User, stiamo dando una forte connotazione all’esperienza che vogliamo progettare.
Ci riferiamo a una persona come ad un utente (User) quando questo si trova a interagire con un dispositivo elettronico o un sistema software. L’UX può quindi essere definita come l’insieme delle impressioni, dei sentimenti e delle interazioni che questa persona prova operando su questi sistemi. È difficile ad esempio definire user un bambino intento a utilizzare un giocattolo.
La centralità dell’interfaccia
A differenza di altre esperienze (Customer Experience, Emotional Experience, Product/Service Experience) nella User Experience l’unico punto di accesso ai sistemi informatico/elettronici, è attualmente attraverso uno schermo o, se vogliamo generalizzare, attraverso una interfaccia. Per questa ragione, viene naturale considerare l’UX strettamente correlata all’interfaccia, di fatto unico punto di leva per modulare l’interazione fra utente e macchina.
Non a caso Jef Raskin in “Humane Interface” afferma che se l’interfaccia fallisce alla luce degli obbiettivi dell’utente, è un fallimento per l’intera applicazione, per quanto possa essere valida.
Figura 4 – In quanto rappresenta il punto di accesso ai sistemi, l’interfaccia è centrale (per la sua comprensibilità) nello studio della User eXperience.
Nonostante la definizione di UX sia esplicitata in maniera tutto sommato troppo generale e ambigua dallo standard ISO 9241-210, l’UX Design è una disciplina estremamente soggettiva per natura, poiche‘ verte su sentimenti individuali e personali che influenzano l’utente, attraverso l’unicità di ciascun bagaglio culturale e storia pregressa.
Per questa ragione UX Design non è qualcosa di magico; una interfaccia ottima progettata bene, non necessariamente funzionerà in ogni occasione; di fatto sappiamo tutti che il Write Once, Run Everywhere è sempre stato un oscuro miraggio. Quello che possiamo fare è promuovere certi comportamenti, agevolarli, suggerirli, ma non possiamo crearli, imporli nè tantomeno predirli con matematica certezza.
Il processo decisionale in UX
Pensare con un approccio UX, va oltre il semplice fornire ai clienti quello che dicono di volere o semplicemente fornire una lista di funzionalità.
Figura 5 – Il processo decisionale con un approccio di tipo UX va ben oltre il semplice gradimento del cliente: troppo spesso però, esso viene inteso, in maniera sbagliata, proprio nel modo rappresentato nell’illustrazione.
La questione è davvero molto sottile, in quanto misurare la bontà di una interfaccia è un problema tutt’altro che semplice, dal momento che dobbiamo necessariamente prendere in considerazione tutti i diversi aspetti di una interfaccia di applicazione che non possono e non devono essere unicamente estetici:
- la fluidità delle interazioni;
- la facilità e la velocità di inserimento dati;
- la chiarezza e la responsività del sistema;
- l’intuitività e la naturalezza nel flusso di lavoro;
- la comprensibilità delle informazioni e delle funzionalità;
- una veloce e facile curva di apprendimento;
- l’accuratezza delle informazioni presentate, in termini di correttezza e contestualità.
L’ultimo punto da prendere in considerazione è effettivamente l’estetica dell’interfaccia, il suo appeal visuale, ma sempre in relazione al contesto d’uso.
Le proprietà di un’interfaccia
A differenza dell’User Centered Design (disciplina relativamente teorica nel quale si pone l’utente sempre al centro degli obiettivi), l’UX Design non è solo e unicamente legato agli utenti, così come non è legato alle tecnologie, alle mode o alle epoche in maniera totalmente esclusiva.
Lo scopo ultimo dell’UX, per sua natura interdisciplinare, è quello di poter influenzare tutti gli aspetti che ruotano intorno ad un software nel momento in cui il servizio si interfaccia con un cliente. Ognuno di questi aspetti può essere riassunto con una singola e distintiva proprietà che Peter Morville ha raccolto in grafico a cui generalmente si fa riferimento come UX honeycomb (a causa della forma “a favo”, con le celle esagonali come quelle realizzate dalle api negli alveari).
Figura 6 – Il grafico “UX honeycomb” con i diversi aspetti inerenti la User eXperience.
Avremo modo di trattare queste proprietà, quando e come esse entrano in gioco a seconda di quale aspetto vogliamo enfatizzare nella nostra applicazione.
Potenziare tutti questi elementi in maniera uguale è ovviamente impraticabile, ci si deve quindi focalizzare solo su quelli che ci interessano direttamente e trovare metriche di misurazione efficienti nel nostro contesto per poter quantificare i parametri di output corretti: efficacia, efficienza, coinvolgimento, fedeltà, velocità.
I metodi tradizionali di misurazione come le analytics per il web, non possono essere utilizzati in maniera classica perchè non riescono a dare una misurazione veritiera dei parametri che vogliamo considerare: il numero di page view su un servizio che gli utenti sono obbligati a utilizzare anche controvoglia è totalmente inutile.
UX design e usabilità
Di fatto è difficile porre metriche dove non esiste un prima e un dopo per poter fare paragoni, ma quando esiste questo contesto, si prospetta uno scenario ancora peggiore, dove uno specialista UX è evocato in modalità forense, ossia “il nostro prodotto non vende o non viene usato, dobbiamo aumentare l’usabilità e ci serve un UX Designer”.
Uno degli errori più frequenti è confondere UX con l’usabilità, ma di fatto l’usabilità non è altro che uno dei mattoni dell’UX [3]; esistono prodotti che hanno experience fenomenali ma sono tutt’altro che usabili e, d’altro canto, strumenti estremamente usabili tuttavia non offrono più di quello e non garantiscono una completa e positiva UX.
Lo stesso errore non deve essere fatto nel confondere l’UX con una qualsiasi delle sue componenti: UX non è solo User Interface, UX non è solo Information Architecture, UX non è solo Human Computer Interaction. La User eXperience è qualcosa di complesso in cui tutti questi aspetti, siano essi di tipo funzionale o emozionale o culturale, si fondono insieme per creare un insieme percepito come esperienza positiva (di nuovo, si pensi alla Ferrari Experience). Sotto il termine UX quindi si celano una pletora di elementi che vanno a coprire tutti i diversi aspetti di un’applicazione che abbiamo elencato poc’anzi.
Ognuna di queste voci contribuisce a costruire l’User Experience finale, ma, come è possibile dedurre dalla loro ampiezza e diversità, ciascuna di queste categorie è una disciplina a se’ stante e interviene su un distinto livello di comunicazione.
Conclusioni
Raramente, specialmente nel contesto italiano, in una azienda esiste una figura specifica per ciascuno di questi settori, e quindi, nel nostro ruolo di designer o developer siamo chiamati a rendere conto anche in questi campi, anche se non ci competono direttamente.
Il prossimo mese ci occuperemo più a fondo di questi ruoli e cercheremo di scoprire insieme le competenze di ciascuno di essi per essere in grado di capire quale ruolo effettivamente serve nel nostro lavoro o quale tipo di figura vogliamo costruirci.
Riferimenti
[1] Donald Norman “La caffettiera del masochista. Psicopatologia degli oggetti quotidiani”, Giunti, 1990
[2] Donald Norman, “Emotional design. Perche‘ amiamo (o odiamo) gli oggetti della vita quotidiana” Apogeo, 2004.
[3] Nicolas Demange, “UX is not UI”
http://www.slideshare.net/nicolasdemange/ux-is-not-ui-10294039