Cosa ci insegna il fallimento della New Coke su user research e design

Alla fine degli anni ’70, la Pepsi rimaneva indietro rispetto alla Coca-Cola nella competizione per diventare la leader nel settore della cola. Ma poi Pepsi ha scoperto che nei blind test sul gusto, la gente in realtà preferiva il gusto più dolce della Pepsi. Per diffondere la notizia, Pepsi realizzò una famosa campagna pubblicitaria, chiamata Pepsi Challenge, che mostrava gente che assaggiava i due marchi di cola senza sapere quali fossero e ogni volta veniva scelta la Pepsi.

L’articolo prosegue sotto

Mentre la Pepsi guadagnava costantemente quote di mercato nei primi anni ’80, la Coca-Cola eseguì lo stesso test e trovò lo stesso risultato: semplicemente, la gente preferiva la Pepsi quando assaggiava i due affiancati. Così, dopo aver condotto ricerche di mercato approfondite, la soluzione di Coca-Cola fu quella di creare una versione più dolce della sua famosa cola: la New Coke. Nei test di assaggio, la gente preferiva la nuova formula di Coca Cola sia alla normale formula di Coca Cola sia a quella di Pepsi.

Nonostante questo successo nei test, quando la società portò sul mercato la New Coke, i clienti si ribellarono. La nuova Coca-Cola si era rivelata uno dei più grandi errori della storia del marketing. In pochi mesi, Coca-Cola ritornò alla sua formula originale con il marchio “Coca-Cola Classic” sugli scaffali.

Alla fine, le vendite hanno dimostrato che le persone preferivano Coca-Cola Classic. Ma la ricerca di Coca-Cola aveva previsto esattamente l’opposto. Ma allora, cosa è andato storto?

I test hanno indotto le persone a bere uno o due sorsi di ciascuna coca in isolamento e poi a decidere quale preferivano in base a quello. Il problema è che non è così che le persone bevono cola nella vita reale. Potremmo berne una lattina durante il pasto. E non beviamo quasi mai solo uno o due sorsi. La user research riguarda tanto il modo in cui viene condotta la ricerca quanto il prodotto oggetto della ricerca.

Ai fini della progettazione e della ricerca di servizi digitali e siti Web, il punto è che le persone possono comportarsi in modo diverso nella user research rispetto a quanto non facciano nella vita reale. Dobbiamo essere consapevoli del modo in cui progettiamo e gestiamo sessioni di ricerca utente e del modo in cui interpretiamo i risultati per tenere in considerazione i comportamenti reali, ed evitare interpretazioni che portano a un sacco di lavoro non necessario e a un impatto negativo sull’esperienza utente.

Per mostrare come questo si applica al web design, mi piacerebbe condividere tre esempi presi da un progetto a cui ho lavorato. Il progetto era per un servizio digitale del governo, che i funzionari pubblici usano per prenotare e gestire gli appuntamenti. Il servizio dovrebbe sostituire un sistema di prenotazione di terzi chiamato BookingBug. Ci siamo interessati a tre esigenze degli utenti:

  • prenotare un appuntamento,
  • vedere gli appuntamenti del giorno
  • e cancellare un appuntamento.

Prenotare un appuntamento#section1

Dovevamo dare agli utenti un modo per prenotare un appuntamento, che consisteva nella selezione di un luogo, di un tipo di appuntamento e di una persona da incontrare. L’ordine di questi campi è importante: non tutti i tipi di appuntamento possono essere condotti in ogni luogo e non tutto il personale è addestrato a condurre ogni tipo di appuntamento.

Screenshot di un'app per prenotare un appuntamento

La prima iterazione della journey di prenotazione, con tre select box in una pagina.

Il nostro progetto iniziale prevedeva tre caselle di selezione in una pagina. La selezione di un’opzione nella prima casella di selezione avrebbe causato l’aggiornamento dei valori nelle caselle successive, ma poiché si trattava solo di un prototipo, non è stato creato nel test. Gli utenti hanno selezionato un’opzione da ciascuna delle caselle di selezione in modo facile e veloce. Ma in seguito ci siamo resi conto che il test non rifletteva realmente il modo in cui l’interfaccia avrebbe effettivamente funzionato.

In realtà, le caselle di selezione si sarebbero dovute aggiornare dinamicamente con AJAX, che rallenterebbe drasticamente le cose e influenzerebbe l’esperienza complessiva. Servirebbe anche un modo per indicare che qualcosa si sta caricando, come uno spinner di caricamento. Questo feedback dovrebbe anche essere percepibile agli utenti ipovedenti che si affidano a uno screen reader.

Non è tutto: ogni casella di selezione dovrebbe avere un pulsante di submit perché inviare una form onchange è un anti-pattern di inclusive design. Ciò riguarderebbe anche scenari in cui è presente un errore JavaScript, altrimenti gli utenti resterebbero con un’interfaccia non funzionante. Detto questo, non eravamo entusiasti all’idea di aggiungere più pulsanti di submit. Una sola call to action spesso è più semplice e più chiara.

Come accennato in precedenza, l’ordine in cui gli utenti selezionano le opzioni è importante, perché il completamento di ogni passaggio comporta l’aggiornamento dei passaggi successivi. Per la produzione, se l’utente ha selezionato le opzioni nell’ordine sbagliato, le cose potrebbero rompersi. Tuttavia, il prototipo non riflette affatto questo: gli utenti possono selezionare qualsiasi cosa, in qualsiasi ordine, e procedere indipendentemente.

Gli utenti adoravano il prototipo, ma non era qualcosa che potevamo effettivamente dare loro alla fine. Per testarlo in modo corretto e realistico, avevamo bisogno di fare molto lavoro extra. Ciò che sembrava innocentemente un semplice prototipo ci ha dato dei risultati fuorvianti.

La nostra iterazione successiva ha seguito il pattern One Thing Per Page: abbiamo diviso ogni campo della form in una schermata separata. Non c’era bisogno di AJAX e ogni pagina aveva un solo pulsante di submit. Ciò ha inoltre impedito agli utenti di rispondere alle domande nell’ordine sbagliato. Dato che non c’era più bisogno di AJAX, anche le relative considerazioni sull’accessibilità sono sparite.

Screenshot che mostra un'app per prenotare appuntamenti suddivisi su tre schermi

La seconda iterazione della journey di prenotazione, con una pagina separata per ogni step.

Abbiamo testato questa cosa davvero bene. La differenza era che sapevamo che il prototipo era realistico, nel senso che gli utenti avrebbero avuto un’esperienza simile quando la funzionalità sarebbe andata in produzione.

Visualizzazione degli appuntamenti del giorno#section2

Dovevamo offrire agli utenti un modo per visualizzare il loro calendario. Abbiamo disposto gli appuntamenti in una tabella, dove ogni riga rappresentava un appuntamento. Ogni ora disponibile era stata demarcata dalla parola “Disponibile”. Gli appuntamenti erano collegati, ma le ore disponibili non lo erano.

Screenshot di una vista app per visualizzare gli appuntamenti del giorno

La pagina di pianificazione per visualizzare gli appuntamenti del giorno.

Nel primo round di ricerche, abbiamo chiesto agli utenti di guardare lo schermo e dare un feedback. Ci hanno detto cosa gli piaceva, cosa non gli piaceva e cosa avrebbero cambiato. Alcuni partecipanti ci hanno detto che volevano che la loro disponibilità risaltasse di più. Altri hanno detto che volevano i tipi di appuntamento codificati con dei colori. Un partecipante ha anche detto che la schermata sembrava noiosa.

Durante il debriefing, ci siamo resi conto che volevano appuntamenti codificati con dei colori perché BookingBug (a cui si erano abituati) li aveva. Tuttavia, il motivo per cui BookingBug utilizzava il colore per gli appuntamenti era che il layout del sistema comprimeva così tante informazioni sullo schermo che era difficile ricavarne informazioni utili altrimenti.

Non eravamo convinti che il feedback fosse prezioso. Accogliere questi cambiamenti avrebbe significato rompere i pattern esistenti, che era qualcosa che non volevamo fare senza esserne sicuri.

Inoltre, non eravamo contenti di rendere la disponibilità più importante, poiché ciò avrebbe reso gli appuntamenti visivamente più deboli. Cioè, risolvere questo problema potrebbe inavvertitamente finire con la creazione di un altro problema dello stesso peso. Al contrario, volevamo che fosse il contenuto a eseguire il lavoro.

Il vero problema, pensavamo, era chiedere agli utenti la loro opinione prima, invece di dare loro dei task da completare. Le persone possono opporre resistenza al cambiamento e le domande che avevamo posto erano sulla loro opinione, non su come fare quello che dovevano. Chiedete a qualcuno la sua opinione e ne avrà una. Come i test sul gusto Coca-Cola e Pepsi, ciò che le persone sentono e dicono durante la user research può essere molto diverso dal comportamento nella vita reale.

Quindi abbiamo testato di nuovo lo stesso design. Ma questa volta, abbiamo iniziato ogni sessione ponendo agli utenti domande a cui la pagina della pianificazione dovrebbe essere in grado di rispondere. Per esempio, abbiamo chiesto “Puoi dirmi quando sarai disponibile successivamente?” e “Che appuntamento hai alle 16?”.

Gli utenti hanno guardato lo schermo e risposto ad ogni domanda all’istante. Solo in seguito abbiamo chiesto agli utenti come si sentivano a riguardo. Naturalmente, erano felici e non fecero commenti che richiedessero grandi cambiamenti. Piuttosto con ilarità, questa volta un partecipante ha dichiarato che desiderava che la loro disponibilità fosse meno prominente perché non voleva che il suo manager vedesse che aveva del tempo libero.

Se non avessimo cambiato il nostro approccio alla ricerca, avremmo potuto passare molto tempo a progettare qualcosa di nuovo che non avrebbe avuto alcun valore per gli utenti.

Annullare un appuntamento#section3

L’ultima funzione prevedeva la possibilità per gli utenti di cancellare un appuntamento. Dal momento che ci stavamo allontanando dall’uso di BookingBug, c’era una situazione in cui un appuntamento poteva essere prenotato sia su BookingBug sia sull’applicazione, i cui dettagli non sono davvero importanti. Ciò che importa è che abbiamo chiesto agli utenti di confermare di aver capito cosa dovevano fare.

Screenshot che mostra una pagina dell'app per confermare una cancellazione

La pagina di conferma della cancellazione.

La prima sessione di ricerca aveva cinque partecipanti. Uno di questi partecipanti ha letto il prompt ma ha mancato la checkbox e ha inoltrato la form. A quel punto, l’utente è stato portato alla schermata successiva.

Avremmo potuto seguire la tentazione di esplorare dei modi per rendere la checkbox più prominente, il che in teoria avrebbe ridotto la possibilità che gli utenti la mancassero. Ma poi di nuovo, il pattern checkbox era stato usato per tutto il servizio ed era passato attraverso molti round di test di usabilità e accessibilità: sapevamo che il design visuale della checkbox non era esente da errori.

Il problema era che il prototipo non aveva la form validation. In produzione, gli utenti avrebbero visto un messaggio di errore, che avrebbe impedito loro di procedere. Avremmo potuto passare del tempo ad aggiungere la form validation, ma occorre bilanciare la velocità a cui si vuole creare un prototipo “usa e getta” e il fatto che il prototipo fornisca risultati accurati e utili.

Riepilogo#section4

La Coca-Cola voleva che la sua cola di fama mondiale avesse un sapore migliore della Pepsi. Non appena i test hanno dimostrato che la gente preferiva la sua nuova formula, Coca-Cola l’ha usata. Ma proprio come il design della pagina di pianificazione, non era il prodotto ad essere sbagliato, ma la ricerca.

Anche se non rischiavamo di fare l’epic fail del secolo del settore marketing, il design dei nostri test avrebbe potuto influenzare la nostra interpretazione dei risultati in una maniera che avrebbe creato molto più lavoro per un ritorno negativo. Un sacco di tempo sprecato e un sacco di soldi sprecati.

Il tempo con gli utenti è prezioso: dovremmo dedicare tanto impegno e riflessione al modo in cui gestiamo le sessioni di ricerca come facciamo quando progettiamo l’esperienza. In questo modo gli utenti ottengono la migliore esperienza e evitiamo di fare lavori inutili.

Sull’autore

adamsilver

Adam Silver è un designer e interface developer di London, UK. Passa la maggior parte del suo tempo a combattere la complessità e a lavorare con gli altri per produrre servizi digitali e siti web semplici, umani ed inclusivi. Inoltre, Adam è l'autore di MaintainableCSS.

Nessun commento

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altro da ALA