Alberto Mucignat

random thoughts around web stuffs (è tutto un equilibrio sopra la follia…)

La customer experience degli esperti (featuring Trenitalia)

Scritto il a proposito di Customer Experience - 3 Commenti

Un tweet dell’amico Federico mi ha fatto venire in mente una cosa a proposito del sito Trenitalia, ma non solo:

In realtà, Federico è un utente esperto, perché usa internet quotidianamente, ma può considerarsi un utente esperto per il sito di Trenitalia? E in ogni caso: un utente esperto (o ricorrente) per il sito di Trenitalia è facilitato nell’esperienza d’uso che il sito propone (o impone)? E più in generale: esistono veramente utenti esperti?

Tempo fa un amico, che vive e lavora in USA da anni, ha cercato di acquistare un biglietto sul sito Trenitalia, abbandonando dopo un po’ di tentativi. Mi ha confidato di averlo trovato difficile da usare perfino per uno come lui che usa internet quotidianamente per i suoi acquisti.

Nel mio caso, utilizzo settimanalmente il sito di Trenitalia per acquistare, ma – al netto di problemi tecnici che ogni tanto avvengono – l’esperienza per me è ormai “serena”: so come fare e dove andare per comprare, so insomma cosa aspettarmi. Interagisco con il sito con estrema facilità per fare quello che faccio sempre e ormai so esattamente dove cliccare, tanto che non leggo nemmeno quello che c’è scritto sui pulsanti o nei microtesti a corredo, per quanto utili possano essere.

Non voglio dire che lo trovo facile o che ci metto poco: l’esperienza non è piacevole ed è forse troppo complessa, ma riesco (quasi) sempre a fare quello che mi serve, ovvero acquistare un biglietto. È un’esperienza comune che registriamo spesso anche negli utenti con cui la mia azienda fa test di usabilità. Nel caso però del mio amico americanizzato, lui è un esperto, ma non lo è per il sito Trenitalia, poiché non ne è un utilizzatore frequente.

Ci sono però un paio di considerazioni da fare a margine della mia esperienza di utente frequente.

Talvolta alcuni problemi tecnici possono complicare l’esperienza anche per un utente frequente. Non considerarli un problema di user experience sarebbe un errore: l’esperienza di utilizzo passa anche per i problemi tecnici, i messaggi di errore indecifrabili e senza scappatoie, i rallentamenti del sito, gli inspiegabili “azzeramenti” di tutto quello fatto in precedenza a causa di errori casuali o di un pulsante back cliccato “per sbaglio” (non è un errore tentare di tornare indietro per tentare di ovviare a problemi dell’interfaccia!).

Inoltre, bastano alcuni lievi cambiamenti all’interfaccia e perfino io rischio di perdermi, di non ritrovarmici più: un redesign anche banale comporta un rischio notevole. Infatti, solo dopo aver ritrovato il filo di quello che sto cercando di fare (il task primario) posso dire se la modifica è stata positiva oppure se mi crea ulteriori rallentamenti.

Nella sostanza, quello che mi differenzia da un utente “principiante” del sito sono queste caratteristiche:

- uno o più task che ripeto frequentemente (cercare dei treni, vedere se ci sono posti disponibili, perfezionare un acquisto, richiedere la fattura, ecc)
- una maggior attenzione al fattore tempo: anche per un principiante è importante, ma sicuramente è più invogliato a investire inizialmente del tempo. Chi invece ripete spesso gli stessi task vuole essere ulteriormente facilitato (memorizzare i miei dati, i dati di fatturazione, le ricerche tipiche, ecc)
- so cosa aspettarmi: spesso errori o problemi diventano normali e ho sviluppato nel tempo una serie di workaround, tra cui quello drastico di chiudere il browser e tornare qualche minuto dopo (per un utente principiante gli errori possono invece trasformarsi in un nightmare che lo portano all’abbandono definitivo in pochi secondi).
- incremento del carico cognitivo quando avvengono redesign anche minimi: l’abitudine richiede più energia per modificare i nostri comportamenti (anche solo la voglia di apprenderne uno nuovo) se siamo di fronte a un task urgente-ripetitivo
- incapacità di valutare le difficoltà di un utente principiante: per me il sito è facile (perlomeno l’utilizzo ripetitivo che ne faccio).

Per questi motivi (specialmente l’ultimo) tanti brand sbagliano a valutare l’esperienza di utilizzo del proprio sito: spesso si ritiene soddisfacente l’esperienza solo perché magari i questionari vengono somministrati a utenti frequenti.

Tuttavia, se ci pensate, ognuno dei punti che ho elencato possono servire da linee guida tattico/strategiche per il miglioramento del servizio. E se penso a un sito che affronta molto bene ogni punto elencato mi viene in mente l’esempio di Amazon, guarda un po’…

Allora come possiamo affrontare il design di servizi per queste tipologie di utenti molto differenti? Anzitutto bisogna distinguere meglio:

- utenti non esperti (es: neo internauti, passatemi il termine) e inesperti del sito
- utenti esperti di acquisti su internet e inesperti del sito
- utenti esperti di acquisti su internet e utenti frequenti del sito.

Ognuna di queste 3 tipologie andrebbe analizzata nel dettaglio, a partire dalla categoria “primaria”: quella cioè che è più strategica per il business (al momento non saprei dirlo per il sito in questione, mi mancano dati).

Nella mia esperienza come consulente ci si focalizza spesso sulla seconda categoria (tipicamente per un fattore di acquisizione clienti), dimenticando gli utenti frequenti che sono invece importantissimi per il business, forse più degli altri se parliamo di retention.

Tuttavia la prima categoria di utenti è sempre di maggiore importanza, perché negli ultimi anni abbiamo visto un incremento di utenti newbie dovuti all’abbassamento delle barriere di ingresso ad internet (penso soprattutto al mobile e all’uso di tablet da parte di over 50). Questa categoria è sicuramente importante in termini di acquisition anche per il livello di loyalty che ne deriva (i meno esperti sono quelli meno propensi a cambiare fornitore/sito una volta che vi si sono trovati bene).

Quindi per tornare alla considerazione iniziale, ha ragione Federico: bisogna testare in maniera massiccia il sito, però tenendo conto delle diverse categorie di utenti e del fatto che l’esperto non è mai un esperto ideale: messo di fronte a siti nuovi cercherà di applicare i (pochi) pattern che conosce bene. E paradossalmente è più facile abbandoni il sito se non è fatto bene in base alla sua “esperienza”.

La soluzione è dunque, per siti molto complessi o largamente utilizzati, quella di testare periodicamente con le diverse tipologie di utenti (oltre ad altre attività importanti quali l’analisi degli analytics per evidenziare pattern e nuovi comportamenti emergenti).

È un piano a medio-lungo termine, ma è uno dei pochi che alla fine porta a un miglioramente della famigerata loyalty. Una parola che sento spesso utilizzata in molte aziende che però hanno problemi importanti a livello di customer experience.

ps: ritrovo ora un articolo di Jakob Nielsen che conclude appunto: “Usability tests must study users over time as they develop expertise in using the site or service.” E il cerchio si chiude.

3 Commenti - Tag: , ,

La meta-negoziazione nei contratti B2B

Scritto il a proposito di WebMarket - 2 Commenti

Il mio amico Jacopo, al solito, ha tirato fuori un punto fondamentale sui contratti B2B descrivendolo in modo eccellente:

We play two games: a game and a meta-game.

The point is that every contract we are about to sign brings another negotiation in. It is a sort of meta-contract. The first contract is about the price and terms of the service you are going to buy or sell. The second one, on a higher level, helps structure the rules of the game you are playing and you are going to play in the future. This second invisible contract escapes notice because it is usually negotiated unconsciously. But you know it or not, every move you make trying reaching an agreement will forge the rules of the agreement itself.

Definitivo. Aggiungo solo che la questione riguarda non solo le persone coinvolte nella vendita, ma anche quelle che si occupano di presale e gli operativi, che poi dovranno mantenere le aspettative.

Forse mi permetterei di dire che non è troppo “inconscia” la seconda meta-negoziazione (almeno nel mio caso), ma il pensiero di Jacopo è comunque un piccolo capolavoro.

2 Commenti - Tag:

Tesla, kaizen e il punto di vista dei clienti

Scritto il a proposito di User experience - Commenta

(post lunghetto e simil-rant, me ne scuso in anticipo) ;-)

Ripesco solo ora un post di qualche tempo fa su Tesla e lo sviluppo continuo. Al di là della vecchia diatriba tra metodi agili, sviluppo continuo, waterfall, ecc, c’è un punto nuovo che mi pare corretto analizzare:

As many companies are discovering, incremental improvement doesn’t have the same cachet to a consumer as new and better. While it may seem irrational, inefficient and illogical, the reality is that people like shiny new toys. They want newer things. Often. And they want to be the ones who own them, control them and decide when they want to change them.


Questa analisi non mi convince pienamente, ma vale la pena andare in profondità. I concetti importanti espressi dal post sono due:

  1. il fatto che le persone non si aspettano miglioramenti continui, bensì vogliono cose nuove
  2. il fatto che le persone vogliono essere in controllo (anche delle cose nuove).


Se con il primo concetto non sono d’accordo molto, nella mia esperienza in effetti le persone sono terrorizzate dagli upgrade continui: c’è un alto rischio di ritrovarsi modificate delle funzionalità a cui erano affezionati e gli eventuali benefici dell’upgrade si possono apprezzare solamente dopo qualche tempo di utilizzo. Questo è forse il punto critico più importante degli sviluppi continui: aggiungere feature e migliorare le esistenti non deve assolutamente inficiare l’attuale esperienza d’uso.

Lo dico meglio: è veramente dura cambiare le feature volendole migliorare (di certo testare con le persone è fondamentale in questo) e avere anche una transizione indolore. Idealmente, l’aggiunta di nuove funzionalità non deve peggiorare o rallentare la vecchia esperienza a scapito di nuove feature magari secondarie per gli utenti esperti, ma quasi mai è così. Ricordate il vecchio Schema per la risoluzione dei problemi: “Funsiona? No sta tocarlo!” (scusate il dialetto, ma viene meglio in veneto).

Certamente è interessante l’esempio di Tesla: nel caso di un bene fisico, riuscire ad avere degli improvement è sicuramente un beneficio importante e che differenzia dai competitor in maniera sostanziale. Tuttavia il redesign completo è sicuramente un’azione necessaria dopo tot tempo: l’ottimizzazione continua rende impossibile l’applicazione di nuovi pattern, principi e linee guida di design.

Arriva cioè un momento in cui i cambiamenti continui richiedono un salto di paradigma.

Un primo punto è riuscire a capire quando questo momento è arrivato. Il principio del diminishing return è sicuramente un buon metodo per capirlo: quando i benefici per gli utenti sono minimi rispetto al costo dei cambiamenti è forse venuto il momento di fermarsi e ripensare completamente l’approccio.

Forse quando si passa dal “risolvere problemi noti” a “implementare nuove richieste degli utenti” (o nuove feature proposte dal team) sicuramente è necessaria una valutazione sulla necessità o meno di fare un cambio sostanziale di prodotto.

A Basecamp sono voluti diversi anni di miglioramento per riuscire a proporre un prodotto con un paradigma completamente nuovo. Non conosco il rate di passaggio dal vecchio al nuovo, ma per quanto mi riguarda siamo rimasti con il vecchio. E questo è un altro punto fondamentale: se il nuovo paradigma crea una frizione di utilizzo, il rischio è che la user base decida di non cambiare e rimanga con il vecchio (sempre che sia possibile, ma i ragazzi di 37signals su questo hanno lasciato la porta aperta, cosa molto rara in questo ambito).

Ed ecco un altro importante insegnamento: quando hai un progetto di successo, preparati a mantenerlo anche dopo un eventuale passaggio di paradigma, c’è sempre chi vuole continurare a usare il vecchio, sia pure pagando!

È anche il caso (per me) di OS Mavericks, che sto posticipando il più possibile. Un caso simile relativo ad Apple è stato il passaggio a iOS7 per i possessori di iPhone: salto di paradigma totale con poca attenzione al precedente utilizzo e parecchie incongruenze.

La risposta che sento spesso è che quelli che non vogliono “passare al nuovo” sono una minoranza, che le feature non più presenti o modificate sostanzialmente le utilizzavano solo una minoranza di utenti. Ebbene, attenzione alle minoranze, possono essere molto pericolose: un tempo consigliavo Basecamp a tutti, ora lo sconsiglio proprio perché secondo me la nuova versione non è così efficace. E se le minoranze coincidono con gli influencer il rischio è quello di perdere molta adoption rate.

Si dovrebbe cercare una sintesi in tutte queste osservazioni, ma i consigli credo son sempre poco specifici, dovendo ogni volta valutare attentamente caso per caso. Tuttavia ecco i mie punti:

  • portare avanti il miglioramento continuo fino a che i problemi noti sono risolti efficacemente
  • dopo la risoluzione dei problemi noti (o comunque quando la coda dei problemi influisce su una porzione risibile della user base) valutare l’aggiunta di nuove feature solo se necessarie e solo se si è molto convinti (questo punto è strategicamente complesso, ma altrettanto importante)
  • valutare le nuove feature sia un’ottica di cambiamento continuo che di salto di paradigma: cosa conviene fare?
  • garantire eventuali retro-compatibilità o l’utilizzo in toto del vecchio servizio
  • attenzione sempre alle minoranze attive (quelli che inviano feedback, i blog che si lamentano dei redesign, gli influencer, ecc).

Scegliere quello che conviene fare in termini costi/benefici al terzo punto può non essere semplice e mi piacerebbe sapere se esistono framework noti a supporto.

Un’ulteriore opzione può essere quella di fare “realign continui”: redesign periodici che vanno a modificare anche strutturalmente e progressivamente il comportamento del prodotto senza però snaturarlo nell’immediato.

Significa cioè fare dei “piccoli saltelli digeribili” in termini di user experience, seguendo un disegno di redesign strategico. Come dire per andare da A a B passando per una serie di passaggi che implichino cambiamenti anche importanti, ma facendoli a piccoli passi per renderli digeribili alla user base.

La differenza tra questo approccio e il miglioramento continuo è nella continua ricerca di un miglioramento strutturale, più che di un over-perfezionamento. In pratica, si dovrebbe evitare di avvicinarsi troppo all’effetto del diminishing return che ho descritto in precedenza, cercando anzi di anticipare i cambiamenti strutturali per evitarlo.

Avere cioè un prodotto che si rinnova continuamente a piccoli saltini, più che perfezionarsi maniacalmente per poi dover richiedere un redesign completo ex-novo. (Poveri giappi, mi rendo conto, loro che vivono di riso e kaizen…)

Ed ecco il rovescio della medaglia: la maggior parte delle aziende ha difficoltà a mantenere un committment alto verso determinate scelte durante un tempo medio-lungo, specialmente se queste sono strutturali. E questi sono approcci che richiedono committment delle figure aziendali con responsabilità strategiche, oltre a un piano di design molto dettagliato e preciso (design stategy)Soprattutto, richiede un UX team interno all’azienda che si faccia portatore di questa strategia, con un “Head of UX” equiparabile agli alti C-level, come dico da tempo.

Riprendo infine la parte dell’affermazione iniziale che ritengo comunque sempre valida: “And they [gli utenti] want to be the ones who own them [i prodotti], control them and decide when they want to change them.”. You betcha.

Food for thoughts.

Commenta - Tag:

Osservare i clienti: l’ascolto è superato

Scritto il a proposito di User experience, WebMarket - 3 Commenti

Oggi leggevo un post intitolato “We listened to the people, not the problem” (che peraltro a un certo punto contiene la solita citazione di Henry Ford):

We knew our job as product developers was to make choices on behalf of our users.
But somewhere along the way, after many Skype calls with potential customers — discussing all of their unique use-cases—we let our early customer development fog our vision.

The temptation of flexibility creeped in — and we dropped the ball.

We listened to the person, not the problem.

Sul tema ho predicato a lungo per cui vado dritto al punto.

Il punto è che più andiamo verso un mercato dove le nostre applicazioni, i prodotti e i servizi vengono usati da una marea di persone, più “l’ascolto dei clienti” è uno strumento rischioso.

Voglio dire che bisogna essere molto rigorosi e obiettivi per riuscire ad analizzare l’ascolto senza lasciarsi influenzare.

Di più: un buon lavoro strategico sul design di un prodotto o servizio digitale deve tenere fermi alcuni punti e lasciarsi influenzare su altri che possono cambiare. E in questo le opinioni delle persone possono trarre facilmente in inganno.

Nella mia esperienza ho sempre trovato più proficuo osservare il comportamento delle persone (tramite test di usabilità o altri tipi di ricerca simili), per diversi motivi:

  • il comportamento è difficile da fingere
  • il comportamento è chiaro anche quando è indeciso
  • un comportamento può essere comune a larghe fasce di persone, mentre ognuno ha un’opinione (anche solo lievemente) diversa.

Lo ripeto ancora dopo anni: metti qualcuno di fronte al tuo prodotto e osservalo mentre lo usa.

L’ascolto è superato.

3 Commenti - Tag:

Da dove nasce il design-centrismo di Apple

Scritto il a proposito di User experience - 2 Commenti

Tra tutte le precisazioni post-mortem e dopo l’uscita della biografia su Steve Jobs, mi ha colpito quella di Esslinger, fondatore di frog design.

In particolare, uno dei passaggi chiave per me è il seguente:

To make our success complete, Steve and I negotiated a sound process for implementing the Snow White design language. We agreed that frog would provide full design services under his direct report, and that Apple’s designers would be integrated into one group, reporting directly to me. We also defined design’s relationships with Apple’s engineering and marketing teams as collaborations. We knew these fundamental changes would provoke some resistance within the company, but Steve and I agreed that we had to move forward with them. I also created an economic plan for the work ahead. Steve stood by his word: Apple awarded frog an annual $2 million contract (close to $5 million in 2013 dollars) and put us in charge of all designs at the company. Even though, legally, I remained a consultant, I was named Corporate Manager of Design. Now, the real work would begin.

L’idea è che non basta avere una “vocazione verso il design”, ma un’azienda deve abbracciare il design ad alto livello, a partire dalla dirigenza. Insomma, fino a quando i designer non siederanno al board of directors la vostra azienda non darà peso al design così come fa Apple.

Dico questo perché spesso sento dirigenti e manager dire di “voler essere più design centrici” o di “puntare strategicamente sul design”, salvo però poi non avere nessun VP del design o talvolta nemmeno un team di design con una certa esperienza.

Tanto per esser chiari su quello che dissi circa un anno fa all’Agile UX Camp 2012 circa la necessità di avere più Head of UX in Italia:

2 Commenti - Tag:

La creatività residuale della TV (e in generale)

Scritto il a proposito di WebMarket - Commenta

Da tempo sono critico sulla parola creatività, ma oggi ho letto un intervento su Nuovo e Utile che mi ha fatto ragionare nuovamente sul tema.

Riporto il passaggio chiaave di Stefano Bassalone (i bold sono miei):

Da qui la crisi della creatività. O, per meglio dire, il concentrarsi della creatività sul come fare le nozze con i fichi secchi: aumentando il grado di narratività delle banali scalette dei soliti talk show, affinando l’eloquenza della grafica, spremendo l’impossibile dalle cinque o sei telecamere di studio e dai banchi di montaggio a base Apple o Microsoft. Una creatività residuale, da paese industrialmente sottosviluppato, come prova il basso livello delle retribuzioni di tutta la filiera dei mestieri coinvolti (star e boss della intermediazione esclusi). Peraltro a questa creatività va dato atto di riuscire bene o male a riempire le giornate della gente, in particolare del numero crescente di persone anziane che passano in media più di sette ore al giorno con la compagnia della tv. E poco altro.

Pensando più in generale, anche in altri settori, se anche fosse possibile parlare di qualcosa chiamato effettivamente creatività, penso che questa sia la dimostrazione di come una spirale negativa possa influenzare un’intera industria.

Voglio dire: non trovo modo di monetizzare, pago poco, la professionalità inizia ad abbassarsi, a questo punto ognuno si arrangia come può… Vi ricorda qualcosa?

Siamo un paese dove in molti settori ormai ci resta solo la “professionalità residuale”, che finisce di spremere quel po’ che rimane.

E questo è il rischio più grosso che corriamo: dobbiamo fare una battaglia per riacquistare professionalità, pagarle il giusto (o anche tanto), valorizzarle.

Certo per valorizzare servono manager di alto livello, che riescano a fare business e margini utilizzando le professionalità che gli servono (e pagandole decentemente, in maniera sana). Ma anche nel campo manageriale, la mia impressione è che siamo in residualità.

Commenta - Tag: 

Steve se ci sei batti un colpo

Scritto il a proposito di Tecnologia - Commenta

In attesa del WWDC13 della prossima settimana, Apple sta perdendo ancora quote di mercato in America, stavolta chiaramente a scapito di Windows:

kontar-06-03-13-02

 

Tuttavia pare stia anche conquistando quote sui late adopters che acquistano per la prima volta uno smartphone (proprio dove Windows è forte).

Ma Apple rimane un’azienda con una situazione finanziaria invidiabile e un valore in borsa sicuramente sottostimato (frutto più della valutazione sulla capacità di innovazione, che sul reale valore).

Detto questo anche il sottoscritto sta da tempo pensando a passare a un Samsung: se non fosse per l’ecosistema integrato tra tutti i miei device apple ci avrei già fatto un pensierino. Ma è proprio questo il punto: il lock-in di Apple è superiore a quello degli altri (ed è un asset fondamentale che gli investitori dovrebbero considerare).

Commenta - Tag: , ,

Il vantaggio competitivo dell’intervento umano

Scritto il a proposito di Innovazione, User experience - 1 Commento

Oggi il mio mito personale Derek Sivers ha scritto una cosa molto interessante per chi ha fatto startup o vuole farla. Il tema è la scalabilità del business (più o meno), ma alla fine uno startupper sa di cosa parlo: è normale per le piccole aziende o le startup dover fare delle cose “a mano”, senza automatizzarle. O spesso, senza volerle automatizzare, almeno in un primo momento.

La storia iniziale è molto illuminante e poi Derek tira in ballo un punto che mi sta particolarmente a cuore:

You can put rules into your online forms, so if someone puts a dash in their phone number, or writes “coming soon” as their URL, it tells them they’re wrong and makes them do it over again….

… or …

… you can have new submissions be checked-over quickly by a real person. It’s worth the 10 seconds of human effort, to keep the end-user experience easy but the internal data correct.

Mi è infatti capitato spesso di trovarmi davanti reparti IT che difendevano a spada tratta la “pulizia del db”, a scapito di controlli rigorosi nelle form che riusciavano a stressare anche dei monaci zen.

Ma spesso e volentieri, se il traffico non è eccessivo, basta una persona che controlli i dati e si risparmiano molti comportamenti assurdi delle form (e quasi sempre si aumentano anche le conversion, nel caso di ecommerce o vendita servizi).

Ricordo che ai tempi di Studenti.it avevamo un approccio di questo tipo: ogni contributo uploadato da un utente (appunti, temi, tesine, ecc) veniva valutato da un data entry, che oltre a correggere e uniformare i titoli, aggiungeva valore descrivendo bene il contenuto e catalogandolo in base a determinate parole chiave. È stato uno dei motivi del nostro successo e forse ancora oggi c’è qualcuno che controlla i contributi (sarebbe interessante sapere come è poi scalata questa operazione con i numeri odierni del sito).

Un altro esempio importante riguarda i testi dei prodotti in vendita in un ecommerce (nome del prodotto, descrizione, ecc): ne parla bene oggi Alessandra Farabegoli. Spesso è difficile convincere le aziende a mettere effort su questo punto, ma se guardiamo ai risultati ne vale veramente la pena.

Tornando in tema, penso che decidere quali siano le cose importanti da continuare a fare con esseri umani e quali invece automatizzare con dei software sia una delle scelte strategiche per il business:

When everyone else is trying to automate everything, using a little human intervention can be a competitive advantage.

The problem is when business owners see it as a cost, instead of an opportunity. Trying to minimize costs, instead of maximize income, quality, loyalty, happiness, connection, and all those other wonderful things that come from real human attention.

E soprattutto questo approccio ci consente di migliorare l’esperienza che facciamo provare ai nostri clienti, con “curiose” ricadute sul business.

1 Commento - Tag: , , , ,

Un job title non fa UX designer

Scritto il a proposito di User experience, WebMarket - 6 Commenti

Oggi ho linkato su Twitter un post che parlava più o meno seriamente del fatto che le job description nel mondo della user experience stanno diventando un po’ eccessive, tanto che è stato creato anche un generatore automatico di UX job title.

Ne scrivo perché noto in effetti una tendenza che definirei “job rebranding” nel nostro mondo: da qualche tempo, complice sicuramente linkedin e il personal marketing, molti designer hanno iniziato a definirsi UX designer, raggiugendo formule urticanti tipo “UX/UI designer” (solo per citare quella che considero più fastidiosa). Chiaramente su domande specifiche i vari candidati fanno scena muta, ammettendo infine che “ma io in realtà mi occupo di html/css”.

Per me essere UX designer significa avere uno sguardo più ampio del semplice design delle interfacce: analizzare e considerare il comportamento degli utenti (ormai cross-channel, quindi non solo legato a usingolo medium), lavorare molto con la parte business, occuparsi più di flussi che di pulsanti, analizzare anche quantitativamente i KPI legati all’esperienza, dare indicazioni e gestire il team di design, ecc (solo per fare alcuni esempi).

Per capirci: un UX designer non deve necessariamente saper fare html/css, anzi. Lo UX designer è una figura più tattica che operativa, che pian piano dovrebbe tendere a occuparsi anche di quella parte di strategia che tocca inevitabilmente le scelte di design.

Invece troppo spesso vedo e ricevo curriculum di web designer o frontend web developer (coloro che fanno html/css, per capirci) travestiti da esperti della user experience (magari senza aver mai fatto un test di usabilità). Da anni continuo a pensare che chi si concentra troppo sul codice perde inevitabilmente di vista gli essere umani: sono rari gli esempi di frontend developer efficaci in tal senso, il rischio è di configurarsi come genius designer, di cui ho già ampiamente parlato.

A questo punto credo sia necessaria una seria riflessione, che in parte è stata fatta da IWA (pdf), ma che necessita più comunicazione e divulgazione, oltre che più umiltà da parte dei (presunti) designer. (*)

Non possiamo lamentarci di questo paese se i primi a fare i furbetti siamo noi. Nessuno crede che tu sappia fare tutto. E se qualcuno lo pretende è proprio quel tipo di mercato contro il quale ci dobbiamo battere.

(*) non sono del tutto daccordo con la definizione IWA (troppo spostata sul lato visuale, che ho già opportunamente segnalato tempo fa e che hanno già modificato), ma rimane il fatto che almeno nel loro documento c’è una chiara distinzione con il “frontend web developer”. Tanto per capirci.

6 Commenti - Tag: ,

Oltre il singolo designer

Scritto il a proposito di User experience - 4 Commenti

Qualche settimana fa (eh, c’ho gli arretrati) Cennydd Bowles ha scritto un post su A list apart in cui cerca di argomentare perché il processo UCD è forse inefficente per le esigenze odierne del designer (mia semplificazione, per capire bene leggersi il post).

L’amico Gianandrea Giacoma ha chiesto un parere a un po’ di amici italiani e qualcuno ha risposto privatamente, mentre Davide Casali ne ha scritto un post. Dico la mia pubblicamente, per piacere di discussione.

Leggendo tra le righe i punti che tocca Bowles, a me colpisce quanto per lui l’UCD sia un processo con alcune caratteristiche che rischiano di limitare il designer. C’è un problema di fondo in questo ragionamento: il fatto è che non possiamo pensare che il processo UCD ruoti solo attorno al designer.

Un processo di design coinvolge invece diverse figure: il designer, l’information architect, lo user researcher solo per citare quelle essenziali secondo me. Oltre a queste va aggiunto il business owner (che va considerato “parte del team di design”, sempre e in ogni caso, ma qui Bowles ha centrato il punto). Ridurre la scelta del processo alla sola figura del designer è quindi riduttivo e sbagliato.

Di più, io credo che il processo UCD sia un’assicurazione contro il self-design: si evita che un designer da solo possa influenzare il progetto a tal punto da fargli perdere la bussola, non solo in relazione agli utenti, ma anche al business, come spesso accade e come infine sottolinea Bowles.

In fondo, forse l’idea che il genius designer possa risolvere tutto non è solo un problema italiano, ma questo già lo sapevamo.

4 Commenti - Tag: