Model Kano – Analiza Satysfakcji Klienta
Definicja
Model Kano to narzędzie opracowane w latach 80. przez profesora Noriaki Kano. Służy ono do zrozumienia, że nie wszystkie funkcjonalności produktu są postrzegane przez użytkowników w ten sam sposób. Niektóre cechy są traktowane jako oczywiste, inne budzą zachwyt, a jeszcze inne mogą być obojętne. Model ten pomaga Analitykom Biznesowym i Product Ownerom zdecydować, w które funkcje warto inwestować, by realnie wyróżnić się na rynku.
Kategorie wymagań według Kano
Model klasyfikuje cechy produktu na pięć głównych grup:
1. Cechy Podstawowe (Must-be / Threshold)
To funkcje, których użytkownik po prostu oczekuje. Ich obecność nie zwiększa satysfakcji (jest ona neutralna), ale ich brak powoduje skrajne niezadowolenie.
- Przykład: Możliwość wykonania połączenia w smartfonie lub czysta pościel w hotelu.
2. Cechy Liniowe (Performance / One-dimensional)
Satysfakcja użytkownika rośnie proporcjonalnie do stopnia dopracowania tej cechy. Im lepiej działa, tym bardziej klient jest zadowolony.
- Przykład: Czas pracy baterii w laptopie lub szybkość ładowania strony internetowej.
3. Cechy Ekscytujące (Attractive / Delighters)
Funkcje, których użytkownik się nie spodziewa. Ich brak nie powoduje niezadowolenia (bo nikt ich nie oczekiwał), ale ich obecność wywołuje efekt “wow” i buduje lojalność.
- Przykład: Darmowy deser w restauracji lub innowacyjna funkcja AI w edytorze tekstu.
4. Cechy Obojętne (Indifferent)
Cechy, na które użytkownik nie zwraca uwagi. Ich obecność lub brak nie zmienia poziomu satysfakcji. Inwestowanie w nie jest marnotrawstwem zasobów.
5. Cechy Odwrotne (Reverse)
Funkcje, których obecność irytuje użytkowników. Im więcej ich jest, tym mniejsza satysfakcja.
- Przykład: Nadmiar skomplikowanych ustawień w prostym narzędziu do notatek.
Kwestionariusz Kano: Jak zbierać dane?
Aby przypisać funkcję do odpowiedniej kategorii, Model Kano wykorzystuje specyficzny rodzaj ankiety. Dla każdej funkcji zadaje się dwa pytania:
- Pytanie funkcjonalne: Jak byś się czuł, gdyby ta funkcja była dostępna?
- Pytanie dysfunkcjonalne: Jak byś się czuł, gdyby tej funkcji nie było?
Użytkownik odpowiada na skali: Lubię to, Oczekuję tego, Jest mi to obojętne, Mogę z tym żyć, Nie lubię tego.
Dynamika czasu – degradacja zachwytu
Kluczowym spostrzeżeniem profesora Kano jest to, że wymagania zmieniają się w czasie. To, co dziś jest Eksytujące (np. Wi-Fi w pociągu 10 lat temu), z czasem staje się Liniowe, a ostatecznie staje się Podstawowe (dziś brak Wi-Fi w pociągu budzi irytację). Oznacza to, że produkt musi być stale rozwijany, by utrzymać ten sam poziom satysfakcji klienta.
Zastosowanie Modelu Kano w Agile
- Budowa MVP: Skupiamy się na dostarczeniu wszystkich cech Podstawowych oraz minimum jednej lub dwóch cech Liniowych i Ekscytujących.
- Priorytetyzacja Backlogu: Pomaga usunąć z backlogu cechy Obojętne i uniknąć wdrażania cech Odwrotnych.
- Analiza UX: Pozwala projektantom skupić się na funkcjach, które faktycznie budują relację z marką.
Typowe błędy
- ❌ Skupienie tylko na “Delighters” – Dodawanie innowacyjnych gadżetów przy jednoczesnym zaniedbaniu stabilności systemu (cechy podstawowe).
- ❌ Ignorowanie ankiet – Przypisywanie kategorii “na oko” przez zespół, zamiast zapytania realnych użytkowników.
- ❌ Zbyt rzadka analiza – Zapominanie, że konkurencja czyni Twoje unikalne cechy standardem rynkowym.
Podsumowanie
Model Kano uczy pokory wobec potrzeb użytkownika. Przypomina, że satysfakcja nie jest wynikiem prostej sumy funkcji, ale ich jakości i dopasowania do psychologii klienta. Dla analityka jest to potężne narzędzie do argumentacji, dlaczego warto zainwestować w wydajność systemu zamiast w kolejny zbędny przycisk w menu.
Powiązane pojęcia:
Kliknij w pojęcie, aby przejść do jego definicji w słowniku
Inne pojęcia ze słownika
Modelowanie Danych (ERD – Entity Relationship Diagram)
Wizualna reprezentacja struktury bazy danych, pokazująca relacje między encjami (obiektami), ich atrybuty oraz liczebność powiązań.
Czytaj więcej →Narzędzia CASE
Zbiór programów i metodologii wspomagających automatyzację procesów wytwórczych oprogramowania, od analizy po testowanie i utrzymanie.
Czytaj więcej →Product Backlog
Uporządkowana i dynamiczna lista wszystkiego, co może być potrzebne w produkcie; jedyne źródło wymagań dla zespołu.
Czytaj więcej →
Latarnia Analizy