A tervezőcsapat összeállít egy listát a felhasználói igényekről a termékével kapcsolatban. A mérnöki csapat a funkciók egy másik sorával áll az asztalhoz. A menedzsment csapat csak azokat a funkciókat akarja, amelyek pénzt hoznak a vállalatnak. A támogató csapat teljesen más funkciókat lát, amelyeket meg kell javítani. Honnan tudhatja egy termékcsapat, hogy milyen irányba menjen?
Tervezési kutatóként arra támaszkodunk, amit az ügyfelek mondanak és tesznek, hogy mélyebben beleolvassunk, és felfedezzük, mit akarnak. Azonban sokan közülünk gyakran küszködtek új módszerekkel, hogy számszerűsítsék és vizualizálják ezeket az igényeket hatékony módon, hogy ezek a csapatok összhangba kerüljenek. Az ügyfelek természetesen szavazhatnak a funkciókról és rangsorolhatják azokat, ami nagyszerű áttekintést ad, de nem mindig adja meg azt a mélyebb megértést, hogy melyek a “must-have”-ek a már elvártakkal szemben.
Elérkezik a Kano modell.
A Kano-modell a termékfejlesztés és a vevői elégedettség elmélete, amelyet az 1980-as években Noriaki Kano professzor dolgozott ki, és amely öt kategóriába sorolja a vevői preferenciákat. Olyan technikákat kínál, amelyek segítenek megérteni a vásárlók termékjellemzőkkel kapcsolatos nézeteit azáltal, hogy minden egyes termékjellemzőhöz két mérőszámot mérnek: az elégedettséget és az érzelmeket. Az e két mérőszámra adott válaszok az öt kategória egyikébe tartoznak: Vonzó, Teljesítmény, Közömbös, Muszáj, Nemkívánatos.
Hogyan kell használni
Készítsen egy kérdőívet, amelyben minden tulajdonság külön-külön szerepel. Ideális esetben minden egyes funkció esetében mutassa be, hogy mit tud az adott funkció egy prototípuson vagy interaktív drótvázon keresztül, ha lehetséges. Ne töltsön sok időt prototípus készítéssel erre: ez csak egy prototípus, hogy átadhassa az ötletet. Vannak, akiket még a prototípusoknál is nagyon le tudnak kötni a részletek, mert lehet, hogy az ötlet tetszik nekik, de az nem, ahogyan megvalósították.
Ha a funkciókat nem lehet demózni, egy magyarázó szöveges leírás is jól működik.
Protipp: Más IBM-kutatókkal folytatott beszélgetések alapján azok, akik sikeresebbek voltak, 15-20 funkciót teszteltek. Akik kevésbé voltak sikeresek, azok 30-40 funkciót teszteltek. A 20-nál több funkció tesztelése túl nagy mennyiségű adatot jelentett mind az ügyfelek számára, mind a kutatók számára az elemzéshez.
Az egyes funkciók megtekintése után a felhasználók kiválasztják válaszukat a Kano kérdőívre:
- Ha volt (funkció), hogyan érzi magát?
- Ha nem volt (funkció), hogyan érzi magát?
(Daniel Zacariasnak van néhány kiváló tanácsa arra vonatkozóan, hogyan kell ezeket a kérdéseket érthetően megfogalmazni)
A fenti két kérdésre a Kano-kérdőív standard válaszai a következők:
- szeretem
- elvárom
- semleges vagyok
- tűröm
- nem tetszik
- nem tetszik
Daniel Zacarias néhány más lehetőséget is kínál ezen válaszok válaszkészletére. Alapvetően, ha ki akarod próbálni a Kano modellt, olvasd el az egész cikkét. Elképesztő.
Jan Moorman egy harmadik kérdés hozzáadását is javasolja: Mennyire fontos ez a funkció? Azt javasolja, hogy egy kilencfokozatú Likert-skálát használjunk a “Egyáltalán nem fontos” és a “Rendkívül fontos” között. Ha azonban megpróbáljuk a Likert-skála kilenc pontját a fontosságra vonatkozóan leírni, az … egy kicsit trükkös. Úgy tűnik, hogy a hétpontos Likert-skála egyszerűbb.”
Ha már megvannak a válaszok, következik egy elemzési folyamat, amelyet Daniel Zacarias nagyon részletesen leír. Erősen ajánlom, hogy olvassa végig.
Az IBM kutatói azt találták, hogy ezek a számok nagyszerűek voltak, de maguk a számok nem mondták el senkinek, hogy miért, az elkerülhetetlen kérdést, amit mindannyian megkapunk a vezetői csapatainktól. Az egyik csapat a Kano-modell segítségével mintegy 15 kvalitatív interjút készített. Egy másik csapat 5 kvalitatív interjút készített, miután 40 embertől kapott kérdőíveket. Mindkét csapat erősen ajánlotta a kvalitatív interjúk hozzáadását ehhez a folyamathoz, mivel ez hozzáadta a narratívát, amely segít megadni az adatoknak a hiányzó kontextust.
Hogyan NEM használjuk
A Kano-modellt használó IBM-csapatok egyike hezitált, hogy újra használja-e azt. Ez a csapat úgy állította össze a kérdőívet, hogy a funkciók leírásához olyan forgatókönyveket használt, amelyekről úgy vélték, hogy a dolgok jelenleg így működnek. A tesztelés előrehaladtával azonban nagyon hamar nyilvánvalóvá vált, hogy a tervezőcsapat forgatókönyvei nem tükrözik azt, ahogyan az ügyfelek ténylegesen használják a terméket, és a tesztelés gyorsan kisiklott.
Az ötlet, hogy forgatókönyveket használjanak a funkciók leírására, jó, de ahogyan megvitattuk a megközelítésüket, világossá vált, hogy a forgatókönyveket előzetesen validálni kell. A Kano + forgatókönyvek kombináció erőteljes lenne a generatív kutatást követően, amely megállapítja a jelenlegi helyzetet.
A másik tanács az volt, hogy csökkentsük a tesztelt funkciók számát. Az a csapat, amelyik 30-40 funkciót tartalmazó hosszú listát vállalt, azt mondta, hogy ez túl intenzív volt, és hogy az ügyfelek a tesztelés végére túlterheltek és kimerültek.
Enyereségek
A Kano-modell nagyon jó a funkciók rangsorolásában. A Kano-modell alapjául szolgáló elmélet az, amit Daniel Zacarias “az öröm természetes hanyatlásának” nevez. Az innovatív ötletek és termékek az izgalmas és újdonságoktól, amelyek a Kano-táblázat tetején állnak (Vonzó), az elvárt funkciókig, amelyek az alján helyezkednek el (legjobb esetben kötelező, legrosszabb esetben visszatetsző).
Vegyük példának a vezeték nélküli internetet*. 2001-et írunk, Ön munkába utazik, és van egy csúcsminőségű laptopja, amely ethernet-porttal és WiFi-vel rendelkezik. Egy szállodában vagy, és megtudod, hogy van ethernet-portjuk, amin keresztül csatlakozhatsz az internetre. A szobaár nem tartalmazza a vezeték nélküli internetet, de az üzleti központban van WiFi. Nagyon örülsz! Ez csodálatos! Micsoda nagyszerű lehetőségek!
Gyorsan előre 2017-be. Munka miatt utazol, és van egy egyszerű laptopod, amiben van WiFi. Egy szállodában vagy, és megtudod, hogy van ethernet portjuk, amin keresztül csatlakozhatsz az internetre. A szobaárban nincs benne a vezeték nélküli internet, de az üzleti központban kaphatsz wifit. Dühös vagy! Melyik bolygóról származik ez a szálloda, hogy külön kell fizetned az internetért?! És ki használja még mindig az ethernet portot az internethez való csatlakozáshoz?
Az, ami vonzó funkciónak indult (ethernet portok a szobában és WiFi az üzleti központban), 16 évvel később nemkívánatos funkcióvá vált.
Ha a csapatok nincsenek tisztában azzal, hogy mit akarnak az ügyfelek, akkor a vonzó helyett az elvárt funkciókra összpontosíthatnak. Az IBM egyik kutatója, aki a Kano-modellt használta, ezt a saját csapatánál is megjegyezte: “Voltak olyan funkciók, amelyekért a csapat nagyon izgatott volt, aztán rájöttek, hogy ezek már csak tétnek számítanak.”
További lehetőségek
Amint megvitattuk a Kano modellt, felvetettük, hogy néhány más dologra is van benne potenciál:
- A fájdalompontok mélységének felmérése
- A termék életciklusa során a funkciók alapjául szolgáló funkciók felmérése az idő múlásával bekövetkező természetes örömcsökkenés értékeléséhez
Fájdalompontok mélysége
Ez a modell segíthet feltárni, hogy a meglévő fájdalompontok mennyire súlyosak. A Kano-kérdőív könnyen alkalmas arra, hogy a kutatás segítségével mélyebbre ássunk, hogy többet tudjunk meg arról, miért olyan rosszak a fájdalompontok, amilyenek, és miért olyan fontosak ezek a funkciók az ügyfelek számára. Ez feltárhat néhány korábban nem azonosított igényt, és további innovációhoz vezethet.
A funkciók alapértelmezése
Megbeszéltük, hogy a Kano-modell segítségével rendszeresen értékeljük a funkciókat, hogy megfigyeljük, mely funkciók sorolódnak vissza alacsonyabb kategóriákba. Ez a fajta longitudinális tesztelés, kellően nagy vásárlói bázissal, jelezheti a piaci trendeket és elvárásokat, és segíthet a kutatás értékének folyamatos bizonyításában az idő múlásával. Segíthet a csapatoknak abban is, hogy tudják, mikor kezd a termékük stagnálni, és mikor van szükségük innovatív ötletekre ahhoz, hogy visszatérjenek a trendteremtő státuszba.
Nyitott kérdés
Az IBM-nél a tervezőcsapatok néha tanácsadóként működnek a projektekhez. Néhány tervezőcsapatot az IBM-nél arra kérnek fel, hogy jöjjenek be egy projektbe, hogy “megtisztítsák a használhatóságot”, és szórják a varázslatos UX port egy termékre nem sokkal a bevezetés előtt. Más tervezőcsapatokat ideiglenesen beágyaznak egy szélesebb körű termékcsapatba.
A beszélgetésünk végén egy nyitott kérdés maradt: hasznos-e a Kano-modell, ha nem tudunk hatást gyakorolni a termékre? Előfordulhat, hogy nem tudod befolyásolni a terméket, mert az már fejlesztés alatt áll, mert a vezetőség ellenkezik, mert a tervezőcsapat csak ideiglenesen a termékcsapat része, stb. Megéri a Kano-modell használatának fáradozása?
Vagy talán akkor is hasznos, ha nem tudja befolyásolni a terméket?
Gondolatok?