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

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.

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.

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.

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.

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.