Zespół projektowy wymyśla listę potrzeb użytkowników dla twojego produktu. Zespół inżynierów przychodzi do stołu z innym zestawem funkcji. Zespół zarządzający chce tylko tych funkcji, które pozwolą firmie zarabiać pieniądze. Zespół wsparcia technicznego widzi zupełnie inne cechy, które trzeba naprawić. Skąd zespół produktowy ma wiedzieć, w jakim kierunku podążać?
Jako badacze wzornictwa, polegamy na tym, co mówią i robią klienci, aby czytać głębiej i odkrywać, czego chcą. Jednak wielu z nas często zmagało się z nowymi sposobami kwantyfikacji i wizualizacji tych potrzeb w skuteczny sposób, aby te zespoły mogły dojść do porozumienia. Klienci z pewnością mogą głosować i oceniać funkcje, co daje świetny przegląd, ale nie zawsze daje głębsze zrozumienie tego, co jest niezbędne w stosunku do tego, co jest już oczekiwane.
Wejdź do Modelu Kano.
Model Kano to teoria rozwoju produktu i satysfakcji klienta opracowana w latach 80-tych przez profesora Noriaki Kano, która klasyfikuje preferencje klientów na pięć kategorii. Dostarcza technik, które pomagają nam zrozumieć punkt widzenia klientów na cechy produktu poprzez ocenę dwóch miar dla każdej cechy: satysfakcji i sentymentu. Odpowiedzi na te dwie miary będą należeć do jednej z pięciu kategorii: Atrakcyjna, Wydajność, Obojętna, Musi być, Niepożądana.
Jak z niej korzystać
Przygotuj kwestionariusz z każdą cechą wymienioną osobno. Dla każdej z cech, najlepiej zademonstruj, co dana cecha może zrobić poprzez prototyp lub interaktywny szkielet, jeśli to możliwe. Nie spędzaj zbyt wiele czasu na prototypowaniu: to tylko prototyp, aby przedstawić ideę. Niektórzy ludzie mogą się zaplątać w szczegóły nawet w prototypach, ponieważ może im się podobać pomysł, ale nie to jak został zaimplementowany.
Jeśli nie jest możliwe zademonstrowanie funkcji, opis tekstowy również działa dobrze.
Pro-tip: Z dyskusji z innymi badaczami IBM wynika, że ci, którzy odnieśli większy sukces, testowali 15-20 funkcji. Ci, którzy odnosili mniejsze sukcesy, testowali 30-40. Testowanie więcej niż 20 cech było przytłaczającą ilością danych, zarówno dla klientów, jak i dla badaczy do przeanalizowania.
Po obejrzeniu każdej cechy, użytkownicy wybierali swoją odpowiedź w kwestionariuszu Kano:
- Jeśli miałeś (cecha), jak się czujesz?
- Jeśli nie miałeś (cecha), jak się czujesz?
(Daniel Zacarias ma kilka doskonałych wskazówek, jak napisać te pytania w jasny sposób)
Standardowe odpowiedzi kwestionariusza Kano na oba powyższe pytania to:
- I like it
- I expect it
- I’m neutral
- I can tolerate it
- I dislike it
Daniel Zacarias oferuje również kilka innych opcji zestawu odpowiedzi dla tych odpowiedzi. Zasadniczo, jeśli masz zamiar spróbować modelu Kano, przeczytaj cały jego artykuł. To jest niesamowite.
Jan Moorman zaleca również dodanie trzeciego pytania: Jak ważna jest ta cecha? Zaleca użycie dziewięciopunktowej skali Likerta od „Wcale nie ważne” do „Niezwykle ważne”. Jednakże, kiedy próbujemy określić dziewięć punktów w skali Likerta dla ważności, jest to … trochę skomplikowane. Wydaje się, że siedmiopunktowa skala Likerta jest łatwiejsza.
Gdy masz już odpowiedzi, istnieje proces analizy, który Daniel Zacarias opisuje bardzo szczegółowo. Gorąco zachęcam do zapoznania się z nim.
Jedną z kwestii, którą odkryli badacze z IBM było to, że posiadanie tych liczb było świetne, ale same liczby nie mówiły nikomu dlaczego, nieuniknione pytanie, które wszyscy otrzymamy od naszych zespołów zarządzających. Jeden zespół wykorzystał model Kano do przeprowadzenia około 15 wywiadów jakościowych. Inny zespół przeprowadził 5 wywiadów jakościowych po otrzymaniu kwestionariuszy od 40 osób. Oba zespoły zdecydowanie zalecały dodanie wywiadów jakościowych do tego procesu, ponieważ dodawały one narrację, która pomaga nadać danym brakujący kontekst.
Jak go NIE używać
Jeden z zespołów IBM, który używał modelu Kano, wahał się, czy użyć go ponownie. Zespół ten skonfigurował kwestionariusz, używając do opisu funkcji scenariuszy, które uważał za obecny sposób funkcjonowania rzeczy. Jednakże, w miarę postępu testów, bardzo szybko stało się oczywiste, że scenariusze zespołu projektowego nie odzwierciedlały tego, jak klienci faktycznie korzystali z produktu i testy szybko się zatrzymały.
Pomysł wykorzystania scenariuszy do opisania cech jest dobry, ale kiedy dyskutowaliśmy o ich podejściu, stało się jasne, że scenariusze muszą być wcześniej zweryfikowane. Kombinacja Kano + scenariusze byłaby potężna po przeprowadzeniu badań generatywnych, które ustaliłyby sytuację obecną.
Inną radą było zmniejszenie liczby testowanych cech. Zespół, który zajął się długą listą 30-40 cech, stwierdził, że było to trochę zbyt intensywne, a klienci byli przytłoczeni i zmęczeni pod koniec testu.
Korzyści
Model Kano jest bardzo dobry w ustalaniu priorytetów cech. Teoria, która leży u podstaw modelu Kano, to coś, co Daniel Zacarias nazywa „naturalnym rozpadem zachwytu”. Innowacyjne pomysły i produkty przechodzą od bycia ekscytującymi i nowymi, na górze wykresu Kano (Atrakcyjne) do oczekiwanych funkcji, na dole (Must-haves w najlepszym przypadku, detractors, w najgorszym).
Przykładem może być bezprzewodowy Internet*. Jest rok 2001, podróżujesz służbowo i masz laptopa z najwyższej półki, który ma port ethernetowy i WiFi. Jesteś w hotelu i dowiadujesz się, że mają porty ethernetowe, abyś mógł podłączyć się do Internetu. Oni nie mają bezprzewodowy Internet wliczone w cenę pokoju, ale można uzyskać WiFi w ich centrum biznesowym. Jesteś podekscytowany! To jest niesamowite! Jakie wspaniałe opcje!
Przód do przodu do 2017 roku. Podróżujesz do pracy i masz podstawowy laptop, który ma WiFi. Jesteś w hotelu i dowiadujesz się, że mają porty ethernetowe, dzięki którym możesz podłączyć się do Internetu. Oni nie mają bezprzewodowy Internet wliczony w cenę pokoju, ale można uzyskać WiFi w ich centrum biznesowym. Jesteś wściekły! Z jakiej planety jest ten hotel, że musisz płacić dodatkowo za Internet?! A kto nadal używa portu ethernet do łączenia się z Internetem już?
Co zaczęło się jako atrakcyjna cecha (porty ethernet w pokoju, i WiFi w centrum biznesowym), 16 lat później zamieniło się w niepożądaną cechę.
Jeśli zespoły nie są zorientowane w tym, czego chcą klienci, mogą być skoncentrowane na cechach, które są oczekiwane, a nie atrakcyjne. Jeden z badaczy IBM, który stosował model Kano, zauważył to w swoim własnym zespole: „Było kilka funkcji, którymi zespół był bardzo podekscytowany, a potem zdał sobie sprawę, że to były stawki stołowe.”
Dodatkowy potencjał
Podczas dyskusji nad modelem Kano, teoretyzowaliśmy, że ma on potencjał także dla kilku innych rzeczy:
- Ocena głębokości punktów bólu
- Bazowanie cech w cyklu życia produktu w celu oceny naturalnego spadku zachwytu w czasie
Głębokość punktów bólu
Ten model mógłby pomóc ujawnić, jak poważne są istniejące punkty bólu. Kwestionariusz Kano łatwo nadaje się do tego, aby umożliwić badania, które pozwolą sięgnąć głębiej, aby dowiedzieć się więcej o tym, dlaczego punkty bólu są tak złe, jak są i dlaczego te cechy są tak ważne dla klientów. Może to ujawnić pewne wcześniej niezidentyfikowane potrzeby i doprowadzić do dalszych innowacji.
Podstawianie cech
Przedyskutowaliśmy wykorzystanie modelu Kano do regularnej oceny cech, aby zaobserwować, które z nich zostały zdegradowane do niższych kategorii. Ten rodzaj testów podłużnych, z wystarczająco dużą bazą klientów, mógłby wskazać trendy rynkowe i oczekiwania oraz pomóc w dalszym udowadnianiu wartości badań w czasie. Mogłoby to również pomóc zespołom zorientować się, kiedy ich produkt zaczyna osiągać plateau i potrzebują innowacyjnych pomysłów, aby powrócić do statusu wyznaczającego trendy.
Pytanie otwarte
Czasami zespoły projektowe w IBM działają jako konsultanci przy projektach. Niektóre zespoły projektowe w IBM są proszone o włączenie się do projektu, aby „wyczyścić użyteczność” i posypać magicznym pyłem UX produkt na krótko przed wprowadzeniem go na rynek. Inne zespoły projektowe są tymczasowo osadzone w szerszym zespole produktowym.
Na koniec naszej dyskusji pozostało jedno otwarte pytanie: czy model Kano jest przydatny, jeśli nie możesz wpłynąć na produkt? Możesz nie być w stanie wpłynąć na produkt, ponieważ jest on już w fazie rozwoju, z powodu nacisków ze strony kierownictwa, ponieważ zespół projektowy jest tylko tymczasowo częścią zespołu produktowego, itp. Czy warto podejmować wysiłek stosowania modelu Kano?
A może jest on nadal przydatny, nawet jeśli nie można wpłynąć na produkt?
Pomysły?