Il bias di conferma sta rovinando il tuo prodotto digitale?

Hai lavorato per mesi al lancio di una nuova feature del tuo prodotto digitale. L’hai ideata, validata, disegnata e hai analizzato tutti i dati a tua disposizione. Doveva essere la svolta, eri certo che gli utenti attivi l’avrebbero adorata e che flotte di nuovi utenti si sarebbero riversate sulla tua app. Finalmente il lancio avviene e… Non succede niente.

Come può succedere che una feature che pareva tanto importante si riveli in realtà un totale fiasco? Una delle possibili cause è il bias di conferma. Ma cos’è e come incide su un prodotto digitale? Scopriamolo nei prossimi paragrafi.

Cos’è il bias di conferma

Il bias di conferma è un pattern cognitivo che porta a confermare delle opinioni (o pregiudizi) che già possediamo. Facciamo un esempio: se pensiamo che tutti i programmatori siano uomini, nerd e con capelli e barba incolti, trovandoci in una stanza piena di developer (ad esempio, al Codemotion) non faremo caso a tutte le partecipanti di sesso femminile o a tutti i partecipanti col taglio fresco di barbiere.

In pratica, siamo portati a prestare più attenzione agli esempi che confermano le nostre ipotesi. Di conseguenza, tenderemo a trascurare i dati che invece le smentirebbero. E non si tratta di un processo volontario; è una strategia che automaticamente applichiamo quando interpretiamo il mondo che ci circonda.

Questa selezione delle informazioni, come tutto ciò che avviene nel nostro cervello, non è casuale: come altri i bias cognitivi, la sua funzione è quella di ridurre il carico cognitivo. Confermare una storia già nota, una visione già affermata, permette di evitare l’affaticamento mentale derivante dal dover rivalutare le proprie posizioni. E abbiamo già parlato in un altro articolo di come tutti noi puntiamo a ridurre al minimo il dispendio di energie.

Come il bias di conferma incide sul tuo prodotto digitale

Può sembrare incredibile che questo meccanismo possa incidere sulla tua applicazione. Eppure, è inevitabile che lo faccia, e potenzialmente potrebbe agire su diverse fasi del lavoro.

Facciamo alcuni esempi in diverse fasi dello sviluppo di una nuova funzionalità:

• In fase di ideazione, un’idea per una nuova feature di cui ci si è fortemente innamorati può venir difesa a spada tratta, anche quando nessun dato sembra sostenerne l’utilità. Si finisce per partire dalla soluzione per ricavare il problema, anche quando quest’ultimo non esiste.
• La validazione può avvenire tenendo conto solo dei feedback positivi; in maniera inconscia, si può cedere alla tendenza a prendere meno seriamente le critiche alla feature rispetto all’opinione di chi invece la apprezza.
• Durante il design della feature, possono venir testate solamente le varianti ritenute plausibili, che cioè confermano che la feature debba apparire in una certa maniera.
• Infine, nell’analisi dei dati è possibile che vengano scelti i KPI sulla base di ciò che ci si aspetta che la feature produca, anziché valutare quali siano i più importanti per il prodotto.

In pratica, qualsiasi fase del processo può essere potenzialmente intaccata dal bias di conferma. La conseguenza è una situazione come quella descritta nell’introduzione: sembravano esserci le premesse per un grande successo, e invece il risultato è deludente.

Affidarsi ai dati non è sufficiente

Si può evitare di incorrere nel bias di conferma se si segue un procedimento data-driven? D’altro canto, se le tue scelte si basano su dati, non sono forse i dati a parlare? Sì, ma non sempre lo fanno in modo affidabile. Vediamo perché.

Il bias di conferma porta a:

• Cercare informazioni che confermino la teoria
• Ricordare selettivamente gli elementi a favore della propria idea
• Interpretare i dati come conferme della propria idea

Concretamente, ciò può voler dire:

• Alle persone intervistate per ottenere un feedback vengono poste domande che ispirino già la risposta. Ne abbiamo parlato nel dettaglio in un altro articolo.
• Gli unici case study che vengono presi in considerazione quando si sta facendo un’analisi comparativa sono quelli che supportano l’idea iniziale.
• Si prende una decisione con pochi dati: se dopo qualche intervista emergono dei segnali, seppur deboli, di interesse per la feature, non si procede con ulteriori interviste.
• Si sceglie di non indagare possibili criticità: se in un’intervista viene espressa un’opinione contraria, o se un riscontro positivo potrebbe essere spiegato da altri elementi, non si approfondiscono questi potenziali aspetti critici.

In tutti questi casi, non si può dire che non ci si sia affidati a criteri oggettivi, ma il metodo di raccolta e analisi è comunque inficiato dal bias.

E non solo: in un contesto aziendale, il rischio è che questa malinterpretazione dei dati diventi una dinamica collettiva che si autorinforza nella convinzione del gruppo di agire in maniera deliberata.

Come evitare che il bias di conferma rovini la tua app

Il bias di conferma è inconscio e automatico. Ciò significa che dobbiamo arrenderci al fatto che incida sulla nostra applicazione? Ovviamente no. Ma vuol dire che dovremo prestarci attenzione e riconoscere quando si presenta.

Come capire se si stanno prendendo decisioni poco oggettive

Il primo step per combattere gli effetti del bias di conferma è saperlo riconoscere. Alcune frasi possono essere indicatori piuttosto affidabili. Alcuni esempi sono:

• “Gli utenti non hanno capito la feature”
• “Okay, ma quel caso è un’eccezione”
• “Come ci aspettavamo, i dati mostrano…”

Perché queste frasi sono problematiche? Perché ci mostrano tre diversi problemi: un’attribuzione erronea del fallimento, la mancanza di considerazione per gli elementi contrari alla propria idea e la presenza di un’ipotesi attesa che viene difesa prima dell’analisi dei dati.

Un altro segnale che ci si sta facendo trascinare da preconcetti è quando le decisioni precedono le evidenze: ad esempio, si procede a implementare una feature dedicata a un certo segmento di utenza perché si ritiene che questi lo desiderino, senza aver prima approfondito i loro reali desideri tramite interviste, questionari o revisionando i feedback.

Ma non temere: è sempre possibile riportare il processo in carreggiata, purché si sia disposti ad adottare delle contromisure efficienti.

L’antidoto contro il bias di conferma

Una volta imparato a riconoscere quando il bias sta intaccando il prodotto, bisogna anche sapere come difendere l’imparzialità delle decisioni che vengono prese.

Anche se non esiste un singolo modo di combattere il bias di conferma, abbiamo raccolto alcuni suggerimenti che noi di Mabiloft abbiamo sperimentato sulla nostra pelle, e che tuttora implementiamo per evitare di incappare in questa distorsione del processo.

In conclusione, è normale che un processo complesso come la creazione e il mantenimento di un’applicazione possa incorrere in questo tipo di bias. Ma per la buona riuscita del prodotto è necessario saperlo riconoscere e correre ai ripari. Solo così il prodotto finale sarà in grado di rispondere veramente alle esigenze degli utenti.

E tu? Pensi che la crescita del tuo prodotto sia stata rallentata o limitata da questo bias? Se hai un prodotto digitale che desideri far crescere, possiamo aiutarti. Scrivici senza impegno o consulta il sito dedicato.