Tag: users needs

What users want or what users need?

Capita ancora troppo spesso che le aziende (italiane?) siano scettiche nei confronti della ricerca con le persone. Quasi sia un’ammissione di ignoranza da parte loro, il fatto di non sapere cosa le persone vogliano, e quindi sia inutile o persino dannoso ascoltarle.

Eppure quasi tutte mettono in piedi delle strategie di raccolta di feedback (che è un dono prezioso, come ci racconta Raffaele). Quindi va bene ascoltarle dopo aver fruito del nostro servizio o prodotto, ma quando dobbiamo progettarlo no? Che differenza c’è?

Temo sia una questione culturale. Qualcosa su cui dobbiamo lavorare tanto, noi progettisti (e intendo, con progettisti, chiunque abbia a che fare con dei clienti per impostare una strategia o ideare un concept che si rivolga a delle persone). Dobbiamo riuscire a far comprendere il valore di questa fase iniziale del lavoro, preziosissima, ai nostri committenti.

L’errore di base è che le aziende credono che con la ricerca noi andiamo a chiedere alle persone cosa vogliono, cosa gli piacerebbe avere o fare. Una sorta di lista dei desideri. Noi invece domandiamo altro, perché ci interessa indagare la vita delle persone e riuscire a tirar fuori di cosa hanno bisogno. Non è una differenza semantica, ma sostanziale: con i desideri espressi ci facciamo poco, mentre l’ascolto di una storia può significare recepire un bisogno inespresso che possa poi guidare una progettazione mirata. Centrata sulle persone, appunto.

Perché questa convinzione diffusa che ascoltare le persone sia, diciamola tutta, fuffa? Qualche idea me la sono fatta, grazie anche a commenti ascoltati o riferiti:

Abbiamo intervistato oltre sessanta persone per capire come progettare la nostra nuova sede. Alla fine non abbiamo ottenuto nessuna linea guida.

Le aziende vengono da un’esperienza negativa pregressa con la ricerca. Qualche sedicente agenzia, persino grandi nomi della consulenza, gli ha fatto sborsare una vagonata di soldi in passato per poi produrre risultati inconcludenti o fallimentari.

Succede, purtroppo. Ne paghiamo il prezzo tutti noi, che facciamo questo lavoro con professionalità. Oggi in molti si improvvisano esperti di UX, di design thinking, di qualunque cosa sia l’hype del momento. Se è importante fare ricerca con le persone, lo è altrettanto , se non di più, farla con chi ne ha davvero le competenze e l’esperienza.

Non possiamo metterci nelle mani di uno studentello di 22 anni: siamo noi che sappiamo cosa è meglio per loro.

Questa io la chiamo la sindrome dell’onniscienza del manager di turno (condita con un po’ di gerontocrazia). Se sapete tutto, come mai chiedete il feedback ai vostri clienti, dopo? Per migliorare il vostro prodotto o servizio? Benissimo, allora allarghiamo l’ascolto alle altre fasi del progetto, così invece di modificarlo dopo il lancio o rilascio magari lo rendiamo più rispondente alle esigenze del nostro target dall’inizio, risparmiando soldi e tempo. Potremmo perfino intercettare delle aree inesplorate e -pensate!- riuscire a ideare un prodotto innovativo.

Ma non siete voi gli esperti? Proponeteci delle soluzioni, basandovi su delle best practices correnti, e non perdiamo tempo.

Come consulente, io non mi sento un’esperta di soluzioni: piuttosto, ho esperienza nel metodo con cui arrivo a formularle. Ai miei clienti dico spesso che io non ho le risposte alle loro domande, ma che insieme possiamo provare a trovarle. Spiego loro come intendo farlo e poi intraprendiamo un viaggio in cui entrambi ci immergiamo nella realtà delle persone per ricavarne ispirazione (o insight) che guidino le nostre scelte progettuali.

E no, le best practices da sole non bastano: possono essere un punto di riferimento, ma non sostituiranno mai il valore della conoscenza specifica sia delle persone a cui ci rivolgiamo, sia del contesto particolare in cui interagiscono con il nostro prodotto o servizio. E poi, non dicevate di volere qualcosa di innovativo? 😉

Niente nuove, buone nuove

Scrivo al volo sulla base dell’ultimo post di Jared Spool che mi ha molto divertita e pochissimo stupita.

Jared racconta di come abbiano studiato l’inclinazione degli utenti a cambiare le impostazioni dei software, per scoprire che solo pochissimi lo fanno (meno del 5% del loro campione).

Nella loro prova avevano inserito la configurazione di Microsoft Office per un’impostazione di autosalvataggio che, di default, era disattivata. Curiosi di sapere come mai, hanno contattato direttamente la casa madre per chiedere lumi e la risposta è stata la seguente:

The reason the feature was disabled in that release was not because they had thought about the user’s needs. Instead, it was because a programmer had made a decision to initialize the config.ini file with all zeroes. Making a file filled with zeroes is a quick little program, so that’s what he wrote, assuming that, at some point later, someone would tell him what the “real defaults” should be. Nobody ever got around to telling him.

Since zero in binary means off, the autosave setting, along with a lot of other settings, were automatically disabled.

La cosa non mi sbalordisce affatto, essendomi trovata decine di volte in situazioni analoghe, sia da utente che, purtroppo, da progettista o designer che interveniva su qualcosa di giá esistente fatto da altri.

Il programmatore non va lasciato solo, perché altrimenti fa esattamente quello che farebbe chiunque altro: va per il minimo sforzo sperando di doverci mettere una piccola pezza dopo, se mai.

Ma soprattutto, perché il programmatore scrive codice in anticipo rispetto alla decisione di design? I miei amici dell’agile ma anche UX in genere non sarebbero affatto d’accordo.

L’altra cosa divertente che emerge dal pezzo di Jared è che il famoso 5% di customizzatori cui sopra, indovinate da chi è composto? Da programmatori e designers. Quelli che in genere sono poi responsabili di prendere le decisioni progettuali che si rifletteranno sull’usabilitá del prodotto digitale.

Grazie a questi dati possiamo a maggior ragione dire che chi progetta non coincide con l’utente: non ragiona come lui, non naviga come lei, e non usa i settaggi che gli mettiamo a disposizione. Quindi testiamole con loro, eh?