Il team di progettazione arriva con una lista di esigenze degli utenti per il tuo prodotto. Il team di ingegneria arriva al tavolo con una serie diversa di caratteristiche. Il team di gestione vuole solo le caratteristiche che faranno fare soldi all’azienda. Il team di supporto vede caratteristiche completamente diverse che devono essere sistemate. Come fa un team di prodotto a sapere in che direzione andare?
Come ricercatori di design, ci basiamo su ciò che i clienti dicono e fanno per leggere più a fondo e scoprire cosa vogliono. Tuttavia, molti di noi hanno spesso lottato con nuovi modi per quantificare e visualizzare queste esigenze in modo efficace per questi team per arrivare all’allineamento. I clienti possono certamente votare e classificare le caratteristiche, il che dà una grande visione d’insieme, ma non sempre dà quella comprensione più profonda di quelli che sono i must-have rispetto a ciò che è già previsto.
Entrare il modello Kano.
Il modello Kano è una teoria dello sviluppo del prodotto e della soddisfazione del cliente sviluppata negli anni 80 dal professor Noriaki Kano, che classifica le preferenze dei clienti in cinque categorie. Fornisce tecniche per aiutarci a capire le prospettive dei clienti sulle caratteristiche del prodotto valutando due misure per ogni caratteristica: la soddisfazione e il sentimento. Le risposte a queste due misure cadranno in una delle cinque categorie: Attraente, Prestazione, Indifferente, Necessario, Non desiderato.
Come usarlo
Elabora un questionario con ogni caratteristica elencata separatamente. Per ogni caratteristica, idealmente dimostrate ciò che la caratteristica può fare attraverso un prototipo o un wireframe interattivo, quando possibile. Non spendete molto tempo in prototipi per questo: è solo un prototipo per far passare l’idea. Alcune persone possono rimanere molto legate ai dettagli anche nei prototipi, perché può piacere l’idea, ma non come è stata implementata.
Se non è possibile dimostrare le caratteristiche, anche una descrizione di testo esplicativa funziona bene.
Pro-tip: Nella discussione con altri ricercatori IBM, quelli che hanno avuto più successo hanno testato 15-20 caratteristiche. Quelli che hanno avuto meno successo ne hanno testate 30-40. Testare più di 20 caratteristiche era una quantità schiacciante di dati, sia per i clienti che per i ricercatori da analizzare.
Dopo aver visto ogni caratteristica, gli utenti selezionano la loro risposta al questionario Kano:
- Se hai avuto (caratteristica), come ti senti?
- Se non hai avuto (caratteristica), come ti senti?
(Daniel Zacarias ha alcune eccellenti indicazioni su come scrivere queste domande in modo chiaro)
Le risposte standard del questionario Kano ad entrambe le domande di cui sopra sono:
- Mi piace
- Me lo aspetto
- Sono neutrale
- Posso tollerarlo
- Non mi piace
Daniel Zacarias offre anche alcune altre opzioni per il set di risposte per queste risposte. Fondamentalmente, se avete intenzione di provare il modello Kano leggete tutto il suo articolo. È incredibile.
Jan Moorman raccomanda anche di aggiungere una terza domanda: Quanto è importante questa caratteristica? Raccomanda di usare una scala Likert a nove punti da “Per niente importante” a “Estremamente importante”. Tuttavia, quando si cerca di scrivere i nove punti della scala Likert per l’importanza, è … un po’ difficile. Sembra che la scala Likert a sette punti sia più facile.
Una volta che avete le risposte, c’è un processo di analisi che Daniel Zacarias descrive in grande dettaglio. Vi suggerisco vivamente di leggerlo.
Un problema che i ricercatori di IBM hanno trovato è che avere questi numeri è fantastico, ma i numeri stessi non dicono a nessuno il perché, l’inevitabile domanda che tutti avremo dai nostri team di gestione. Un team ha usato il modello Kano per condurre circa 15 interviste qualitative. Un altro team ha condotto 5 interviste qualitative dopo aver ricevuto i questionari da 40 persone. Entrambi i team hanno fortemente raccomandato di aggiungere interviste qualitative a questo processo, in quanto ha aggiunto la narrazione che aiuta a dare ai dati il contesto mancante.
Come NON usarlo
Uno dei team IBM che ha usato il modello Kano era titubante sull’usarlo di nuovo. Questo team ha impostato il questionario usando scenari che credevano essere il modo attuale in cui le cose funzionavano per descrivere le caratteristiche. Tuttavia, mentre i test progredivano, divenne ovvio molto rapidamente che gli scenari del team di progettazione non riflettevano il modo in cui i clienti usavano effettivamente il prodotto, e i test deragliarono rapidamente.
L’idea di usare scenari per descrivere le caratteristiche è buona, ma mentre discutevamo il loro approccio, divenne chiaro che gli scenari devono essere convalidati in anticipo. La combinazione Kano + scenari sarebbe potente dopo una ricerca generativa che stabilisce la situazione as-is.
Un altro consiglio è stato quello di ridurre il numero di caratteristiche da testare. Il team che ha preso una lunga lista di 30-40 caratteristiche ha detto che era un po’ troppo intenso, e che i clienti sono stati sopraffatti ed esausti alla fine del test.
Benefici
Il modello Kano è molto buono nel dare priorità alle caratteristiche. Una teoria che sta alla base del modello Kano è quella che Daniel Zacarias chiama “il decadimento naturale del piacere”. Le idee e i prodotti innovativi passano dall’essere eccitanti e nuovi, in cima al grafico di Kano (Attraente) alle caratteristiche attese, in fondo (Must-have nel migliore dei casi, detrattori, nel peggiore).
Prendiamo Internet wireless come esempio*. È il 2001, e stai viaggiando per lavoro, e hai un computer portatile top di gamma che ha una porta ethernet e WiFi. Sei in un hotel e scopri che hanno delle porte ethernet per connetterti a Internet. Non hanno Internet senza fili incluso nel prezzo della camera, ma puoi avere il WiFi nel loro business center. Sei entusiasta! È fantastico! Che grandi opzioni!
Passiamo al 2017. Stai viaggiando per lavoro e hai un portatile di base che ha il WiFi. Sei in un hotel e scopri che hanno delle porte ethernet per connetterti a Internet. Non hanno Internet senza fili incluso nella tariffa della camera, ma puoi ottenere il WiFi nel loro business center. Sei furioso! Da quale pianeta proviene questo hotel che devi pagare un extra per Internet? E chi usa ancora la sua porta ethernet per connettersi a Internet?
Quella che era iniziata come una caratteristica attraente (porte ethernet in camera e WiFi nel business center), 16 anni dopo si è trasformata in una caratteristica indesiderata.
Se i team non sono informati su ciò che i clienti vogliono, potrebbero concentrarsi su caratteristiche che sono attese invece che attraenti. Uno dei ricercatori IBM che ha usato il modello Kano ha notato questo nel suo team: “C’erano alcune caratteristiche per le quali il team era molto eccitato, e poi si è reso conto che quelle erano delle scommesse.”
Potenziale aggiuntivo
Discutendo il modello Kano, abbiamo teorizzato che ha il potenziale anche per alcune altre cose:
- Misurare la profondità dei punti di dolore
- Basare le caratteristiche su un ciclo di vita del prodotto per valutare il decadimento naturale del piacere nel tempo
Profondità dei punti di dolore
Questo modello potrebbe aiutare a rivelare quanto siano gravi i punti di dolore esistenti. Il questionario Kano si presta facilmente a permettere una ricerca per scavare più a fondo per imparare di più sul perché i punti di dolore sono così cattivi come sono, e perché queste caratteristiche sono così importanti per i clienti. Potrebbe svelare alcuni bisogni non identificati in precedenza e portare a ulteriori innovazioni.
Funzioni di base
Abbiamo discusso l’uso del modello Kano per valutare le caratteristiche su base regolare per osservare quali caratteristiche stavano retrocedendo a categorie inferiori. Questo tipo di test longitudinale, con una base abbastanza grande di clienti, potrebbe indicare le tendenze e le aspettative del mercato e aiutare a continuare a provare il valore della ricerca nel tempo. Potrebbe anche aiutare i team a sapere quando il loro prodotto sta iniziando a stabilizzarsi e hanno bisogno di idee innovative per ritornare ad uno stato di tendenza.
Domanda aperta
A volte i team di design di IBM agiscono come consulenti per progetti. Ad alcuni team di design di IBM viene chiesto di entrare in un progetto per “pulire l’usabilità” e spargere la magica polvere UX su un prodotto poco prima del lancio. Altri team di design sono temporaneamente incorporati in un team di prodotto più ampio.
Siamo rimasti con una domanda aperta alla fine della nostra discussione: il modello Kano è utile se non puoi avere un impatto sul prodotto? Potresti non essere in grado di avere un impatto sul prodotto perché è già in fase di sviluppo, a causa del pushback del management, perché il team di progettazione è solo temporaneamente parte del team di prodotto, ecc. Vale la pena fare lo sforzo di usare il modello Kano?
O, forse è ancora utile anche se non puoi avere un impatto sul prodotto?
Pensieri?