Le 5 scuse che le aziende usano per non fare UX research (sbagliando)

La fase di ricerca con e sugli utenti è quella che viene spesso sacrificata nei progetti con un basso budget a disposizione. Tante sono le scuse che vengono sollevate per giustificare questa scelta, che quasi sempre – però – si rileva controproducente. In questo post abbiamo raccolto le giustificazioni più comuni cercando di confutarle una ad una.

Forse la frase più usata per escludere la fase di ricerca da un processo di design (o redesign) del prodotto è quella legata alla mancanza di tempo. I vincoli dovuti ai ritmi serrati della timeline di un progetto – soprattutto in un contesto competitivo che evolve molto rapidamente come quello attuale – tendono spesso a penalizzare il ruolo della UX research. Eppure l’idea che una ricerca sull’esperienza degli utenti richieda molto tempo per essere portata a termine non è assolutamente vera: la maggior parte delle tecniche di indagine richiede dai due giorni a una settimana di lavoro, a cui si deve aggiungere un elapsed più o meno simile per realizzare un report dei risultati snello ma completo.

Un ruolo fondamentale nel rendere la UX research compatibile con i tempi di progettazione e sviluppo è sicuramente quello ricoperto dalla corretta pianificazione dei suoi tempi di svolgimento, a partire da quelli relativi alla preparazione dei test fino a quelli della fase di reporting.

Un’altra motivazione molto frequente che frena il ricorso alla ricerca è ovviamente quella legata alle limitazioni del budget a disposizione. È indubbiamente vero che i metodi di indagine come i test di usabilità e i focus group – che richiedono spese per l’organizzazione del laboratorio, per il reclutamento degli utenti e per offrire loro un incentivo monetario alla partecipazione – siano soluzioni non sempre alla portata di tutti i progetti. È altrettanto vero, però, che esistono altre tecniche di UX research dal costo più contenuto: dall’analisi dei dati alle survey, dai test svolti online a distanza (con l’utente che può essere guidato dal ricercatore oppure svolgere il test in autonomia) fino ad arrivare a test in presenza meno strutturati, come quelli della guerrilla research.

Queste tecniche non permettono un controllo completo dell’utente e del test e spesso non consentono di andare troppo in profondità: la data analysis, ad esempio, descrive bene quello che accade durante l’esperienza utente ma è meno in grado di suggerire il perché di alcuni comportamenti che si verificano. Tuttavia, la possibilità di ottenere insights, pur con un basso livello di dettaglio, consente di indirizzare nel sentiero giusto gli sforzi della progettazione.

Non va poi trascurato un altro aspetto economico: spesso il mancato svolgimento della fase di analisi e di ricerca sin dagli step iniziali di un progetto comporta maggiori spese di redesign per risolvere le criticità individuate solo a posteriori.

Mettendo da parte le motivazioni legate alla scarsità di tempo e di budget a disposizione, una delle giustificazioni più comuni è la convinzione di non aver bisogno di testare il prodotto perché se ne conoscono già i problemi. Se nella migliore delle ipotesi questa convinzione è basata su dati e feedback che l’azienda ha a disposizione sul funzionamento del prodotto, nello scenario peggiore è il frutto di assumption non consolidate da riscontri.

Il primo dei due casi non è esente dal rischio di sottovalutare l’efficacia della UX research, perché i dati a disposizione potrebbero offrire un quadro della situazione molto parziale: di solito i log di utilizzo e i feedback degli utenti possono essere molto utili per descrivere il problema ma non per comprenderlo in profondità. I feedback non strutturati, inoltre, hanno il limite di raccogliere solamente quello che gli utenti ci vogliono raccontare e non tutto quello che sarebbe utile sapere sulla loro esperienza d’uso.

Lo scenario peggiore è quello in cui si fa affidamento certo su assumption che non sono state messe alla prova dei fatti. Tali convinzioni sono spesso il frutto di valutazioni personali, legate al ruolo ricoperto nell’organizzazione, alle competenze e al background della persona. Far leva su queste assumption può bloccare il processo di ricerca sulla UX ma può anche influire negativamente sull’esame dei risultati di una ricerca, che potrebbero essere utilizzati semplicemente come conferma dell’idea iniziale: in questo caso si è vittime del cosiddetto confirmation bias. Anche l’approccio al test con gli utenti deve essere quindi sgombero da ancoraggi troppo forti all’idea che l’azienda si è fatta sulla user experience dei suoi clienti.

Uno degli errori più comuni che si possono commettere è avere la presunzione di conoscere cosa vogliono i nostri utenti e come utilizzano realmente il nostro prodotto. In realtà non è così, ed è facilmente dimostrabile già dopo uno o due test svolti con veri utenti. Le abitudini, il contesto d’uso e il livello di competenza di ciascun utente fa in modo che si sviluppino modalità di utilizzo diverse da quelle pianificate. Nei primi approcci con un prodotto o un servizio le persone potrebbero trovare molte difficoltà nel capirne il funzionamento e adottare percorsi non lineari per eseguire i task. Quando lo si conosce molto a fondo, invece, alcuni utenti tendono a sviluppare, ove possibile, “scorciatoie” di utilizzo di un prodotto, con l’obiettivo di accorciare i tempi per arrivare al risultato finale, rispetto a quanto previsto da una procedura standard. Studiare questi comportamenti permette di analizzare errori, frustrazioni e strategie dell’utente: tutti elementi fondamentali per migliorare un prodotto.

Lo stesso vale, ovviamente, per indagare a fondo gli obiettivi e desideri degli utenti, che possono non coincidere con quelli del progettista o del produttore del servizio. È per questo che nel caso di prodotti destinati al B2C non è buona prassi reclutare personale interno all’azienda, soprattutto se coinvolti nel processo di ideazione e sviluppo, solo con l’obiettivo di risparmiare sul budget e sui tempi per i test. I veri utenti offrono dei feedback meno influenzati dai bias cognitivi che possono guidare il giudizio di chi progetta il prodotto.

L’ultimo degli errori che analizziamo in realtà non è – in realtà – una giustificazione per non fare UX research, ma un approccio sbagliato ad essa. Uno degli errori più comuni è quello di partire dalla scelta dello strumento di ricerca senza avere inquadrato esattamente il problema da analizzare e il tipo di risposta che vogliamo ottenere. Scegliere una tecnica di indagine senza aver definito le ipotesi e l’obiettivo può portare a produrre output e dati inadatti a trarre le conclusioni corrette.

Ciascun metodo di ricerca ha un suo focus e una sua capacità di rispondere meglio ai quesiti sulla user experience. Alcuni tipi di test consentono di esplorare quello che gli utenti fanno, altri di indagare quello che pensano e dicono mentre utilizzano un prodotto. Alcune tecniche permettono di quantificare il numero degli errori commessi, quanto di frequente vengono compiuti e quante persone vi incappano, altre di capire più nel dettaglio perché vengono commessi gli errori e quali possibili soluzioni è possibile mettere in atto per eliminarli o mitigarli. Un articolo del Nielsen Norman Group ha raccolto in un framework molto utile le caratteristiche di 20 metodi di UX research.

In questo articolo abbiamo cercato di capire (e di smontare) le principali resistenze allo svolgimento di una ricerca sugli utenti. Nel breve periodo sacrificare la UX research può apparire l’opzione migliore in termini economici e di tempo, ma l’accumularsi di scelte strategiche e di sviluppo non sempre in sintonia tra di loro e pensate per gli utenti può presentare presto il conto. Un conto pesante, fatto di utenti insoddisfatti, transazioni perse e una user experience non in linea con gli obiettivi di business.