Diszfunkcionális funkcióértékelés — A Kano-módszertan
Avagy mérsékelten sikeres — de mindenképpen tanulságos — első találkozásunk története a Kano-modellel.
A Mito tanácsadó divíziójában havi rendszerességgel próbálunk beiktatni az ügyfeleknek készülő projektek mellé valamilyen workshopot vagy prezentációt, ami a csapat inspirálódását és szakmai épülését szolgálja. Ennek keretében merült fel az ötlet, hogy teszteljük le a gyakorlatban a Kano-elemzést.
Kaizen, Kanban — Kano
A módszertan Japánból származik; a 80-as években fejlesztette ki Noriaki Kano professzor a fogyasztói elégedettség modellezésére. Kano meggyőződése volt, hogy a fogyasztók szemében nem minden termékfunkció vagy szolgáltatásjellemző egyenlő: némelyik magas lojalitáshoz vezet, míg mások nem növelik az elégedettséget, hiába fordítunk erőforrásokat a fejlesztésükre. Kidolgozott tehát egy elemzést annak feltárására, hogy az egyes funkciók milyen hatással vannak a fogyasztók — vagy ami az esetünkben még érdekesebb: a felhasználók — elégedettségére.
A Kano-modell ugyanis digitális termékek vagy felületek tervezésénél is hasznos lehet. Az ilyen projekteknél jellemzően több érdek és elképzelés feszül egymásnak, miközben sem a büdzsé, sem a józan belátás nem engedi, hogy ezek közül minden (és egyszerre) megvalósuljon. Össze kellene állítani egy életképes roadmapet, de hogyan szűkítsük le az igényeket? A Kano-elemzés a felhasználók szemszögéből segít prioritásokat felállítani a tervezett funkciók között, de akár a meglévő funkcionalitás tesztelésére és értékelésére is alkalmas lehet — ez utóbbiról bővebben később.
(Amire viszont nem alkalmas a módszer, és ezt fontos leszögezni már az elején, az az ötletgenerálás: a Kano-elemzés segítségével csak azokról a funkciókról fogunk ismereteket szerezni, amiket explicit módon tesztelünk vele.)
A modell alapvetően három feltételezésre épül:
- A felhasználói elégedettség az egyes funkciók meglétének szintjétől és minőségétől függ.
- Az egyes funkciók meghatározott kategóriákba sorolhatók a felhasználók elvárásainak és preferenciáinak megfelelően.
- A felhasználók elvárásai megismerhetők egy egyszerű kérdőív segítségével. Oh, about that…
Elméletileg…
Kano két dimenziót vizsgál minden funkcióval kapcsolatban, ezek szerint sorolja be őket kategóriákba: felhasználói elégedettség és funkcionalitás.
Az elégedettség dimenziójának két végpontja van: maximális elégedettség (delight, excitement), illetve teljes elégedetlenség (frustration). A funkcionalitás (vagy: investment, sophistication, implementation) azt jelzi, hogy az egyes funkciók milyen szinten és milyen minőségben elérhetők a felhasználók számára, azaz mennyi erőforrást fektettünk a fejlesztésükbe. Két végpontja az adott funkció teljes hiánya, illetve lehető legjobb megvalósítása (vagy másképp: az elvárásoktól elmaradó, illetve azokon felüli teljesülése).
A két dimenzió öt kategóriát határoz meg, amikbe az egyes funkciók tartozhatnak aszerint, hogy implementációjuk szintje milyen hatással van a felhasználók elégedettségére:
Hang in there, mindjárt értelme is lesz ennek az ábrának… A nyilak az öt Kano-kategóriát jelölik:
Required Features (Threshold, Basic, Must-be)
Ezek az alapelvárások közé tartozó funkciók: a hiányuk fájó, de a meglétük nem növeli a végtelenségig az elégedettséget. Gyakran annyira magától értetődő az igényük, hogy a felhasználók nem is tudják könnyen megfogalmazni, mely funkciók tartoznak ide.
Legyen például ágy a nyaralásra foglalt Airbnb-ben vagy jelölje olvasatlannak a Gmail az új emaileket.
Az elvárt funkciók nélkül nincsenek elégedett felhasználók, így mielőtt a szexibb fícsörökre koncentrálunk, érdemes ezeket rendbe tenni — de csak addig a szintig, amíg az elvárások teljesülnek.
Performance Features (Desired, Linear, One-dimensional)
A teljesítményfunkcióktól dorombolnak vagy dühöngenek csak igazán a felhasználók: minél több van ezekből a funkciókból, és minél jobban vannak implementálva, annál elégedettebbek.
Ilyen tulajdonság lehet egy mobil akksijának élettartama vagy az ingyenes Dropbox-tárhely mérete.
Ezekbe a funkciókba jellemzően érdemes energiát fektetni, mert a felhasználók bevonzásának és megtartásának, valamint a versenyelőny kialakításának is fontos elemei.
Excitement Features (Delightful, Attractive)
Az izgalmat kiváltó funkciók. Olyan tulajdonságok ezek, amiknek a meglétére a felhasználók nem számítanak — cserébe nagyon örülnek nekik.
Példa lehet a főcím átugrásának lehetősége Netflixen vagy <wink> ha a Központban megismert helyes grafikusról kiderül, hogy még az obskurusnak hitt hobbinkban is osztozik </wink>.
Ezek a funkciók azonban csak akkor tudnak elégedettséget növelni, ha az alapok már jól működnek; ezek rovására tehát nem érdemes fejleszteni őket.
Indifferent Features
Vannak vagy nincsenek — a felhasználók véleményét ezek a funkciók nem igazán befolyásolják. A fejlesztésükbe emiatt nem biztos, hogy érdemes erőforrásokat fektetni, hiszen azok nem fognak felhasználói elégedettségben megtérülni.
Reverse Features (Anti-, Undesired)
A felhasználók által kifejezetten elutasított funkciók tartoznak ide. Nem is önálló Kano kategória igazán; a teljesítményfunkciók tükörképe.
Felszisszenős példák lehetnek a Microsoft Clippy-je *sigh* és a viccmesélős taxisofőrök.
“Unlike diamonds, Kano categories are not forever”
A Kano-kategóriák élettartama gyakran véges: a korábban izgalmat jelentő funkciók idővel elvárttá válhatnak, mert vagy lemásolják őket a versenytársak, vagy egyszerűen beépülnek a felhasználók elvárásai közé. Emiatt lehet longitudinális tesztelésre is használni a modellt, vagyis időről időre megvizsgálni, hogyan változtak a felhasználói elvárások, van-e szükség további termékfejlesztésre, új funkciók bevezetésére vagy az erőforrások áthelyezésére.
Eddig csodás. De hogyan is működik mindez a gyakorlatban?
Enter: Kano-kérdőív
A felhasználókból egyszerű (khm) kérdőíves módszerrel csalogatjuk ki a véleményüket: egy rövid leírást (vagy vizuális szemléltetést, pl. mockupot) követően minden funkció kapcsán felteszünk nekik két kérdést.
A funkcionális kérdés azt vizsgálja, hogyan éreznek a felhasználók, ha elérhető a funkció.
A diszfunkcionális kérdés pedig azt, hogyan éreznek a felhasználók, ha hiányzik a funkció.
Egy példán keresztül:
- Ha a piros gombot megnyomva visszanyernéd a cikk olvasásába eddig fektetett időd, hogyan éreznél?
- Ha a piros gombot megnyomva nem nyernéd vissza a cikk olvasásába eddig fektetett időd, hogyan éreznél?
A páros kérdésfeltevés elméleti oka, hogy az emberek nem mindig ügyesek az elvárásaik önálló megfogalmazásában. Gondoljunk csak a kilincsekre az irodai mosdók ajtaján: nem biztos, hogy felismerjük, milyen fontosak számunkra — amíg el nem kell gondolkoznunk azon, mit éreznénk, ha egy költözés után raptorkarmokkal kellene kapaszkodnunk a helyükön tátongó lyukba minden alkalommal, amikor megválaszoljuk a természet hívását. (Sohasem történt ilyen az új irodánkban.) A kettős kérdezés segít tehát feltérképezni például a nehezen megfogalmazható elvárt funkciókat.
Fontos, hogy a diszfunkcionális kérdés nem mindig a funkcionális ellentéte — az adott feature hiányát kell jelölnie csupán. Vagyis, ha a funkcionális kérdésünk ez:
- Ha az alkalmazáson keresztül beküldött minden biztosítási követelést egy munkanapon belül elbírálnának, hogyan éreznél? — Azaz garantált az egy napon belüli elbírálás.
Akkor a diszfunkcionális kérdés nem feltétlenül ez:
- Ha az alkalmazáson keresztül beküldött biztosítási követeléseket nem bírálnák el egy munkanapon belül, hogyan éreznél? — Vagyis sosincs egy napon belüli elbírálás.
Hanem inkább ez:
- Ha az alkalmazáson keresztül beküldött biztosítási követelések közül nem mindet bírálnák el egy munkanapon belül, hogyan éreznél? — Azaz nem garantált az egy napon belüli elbírálás.
Érdemes még néhány szempontot figyelembe venni a tesztelendő funkciók kiválasztásánál és a kérdések megfogalmazásánál:
- Egy kérdés egy funkcióra vonatkozzon. Ha a funkció összetett vagy többlépcsős, bontsuk több kérdésre (különben nem fogjuk tudni, melyik aspektusát értékelték a válaszadók).
- A felhasználónak közvetlenül hasznos funkciókat teszteljünk, ne a technikai vagy üzleti szempontból felmerülő (esetleg emiatt egyébként is biztosan implementálandó) igényeket.
- Maximum 15–20 funkciót teszteljünk. Ennél többet értékelni időben és figyelemben is megterhelő a válaszadók számára — erős incentíva nélkül el fogják hagyni a kérdőívünket.
A Kano-kérdőív kérdései zártak, a válaszlehetőségek mind a funkcionális, mind a diszfunkcionális kérdésnél megegyeznek:
- I like it
- I expect it
- I’m neutral
- I can tolerate it
- I dislike it
A kérdéspár kiegészülhet egy harmadik kérdéssel is, ahol a válaszadóknak 7 vagy 9 fokú skálán kell jelölniük, milyen fontos számukra az adott funkció. Ez a súlyozás később a priorizálásban segít.
Így néz ki mindez élesben — legalábbis a módszertani tesztünk első iterációjában így nézett ki:
Hogyan értékelünk?
A funkcionális és diszfunkcionális kérdésre adott válaszok metszete jelöli ki, hogy egy-egy válaszadó véleményének megfelelően melyik Kano-kategóriába esik az adott funkció:
Az egymásnak ellentmondó válaszok a kérdéses (questionable) kategóriába sorolhatók. Ha sokan adtak ilyen választ egy funkció kapcsán, akkor feltehető, hogy a kérdésfeltevéssel volt probléma (például nem voltunk eléggé egyértelműek).
Ez a táblázat azonban még csak egy-egy felhasználó értékelését mutatja az adott funkció kapcsán. Hogyan tudjuk összesíteni a válaszokat? Két megközelítés létezik erre: a diszkrét és a folytonos elemzés. Ebben a posztban csak az előbbivel foglalkozunk, de Daniel Zacarias írása szuperül levezeti a folytonos elemzés menetét is (meg úgy általában az egész Kano-módszertant).
A diszkrét elemzés menete egészen egyszerű (eskü, tényleg):
- Az egyes válaszadók adott funkciókra vonatkozó válaszait kategorizáljuk a táblázat szerint.
- A funkciókra vonatkozó kategorizálásokat összesítjük, vagyis: hány válaszadó (vagy megfelelő nagyságú minta esetén: hány százalékuk) sorolta az adott funkciót az egyes kategóriákba?
- A funkciókat besoroljuk a leggyakoribb kategóriába. Ha egy funkciót egyenlő számban soroltak több kategóriába is, akkor ebben a sorrendben dönthető el a végleges: required — performance — excitement — indifferent. (Azaz a lenti példában szereplő N-ik funkció a performance kategóriába kerül.)
- Végül minden funkcióhoz kiszámoljuk a skálás fontossági értékelések átlagát.
Az összesített eredmények táblázatos formában megjelenítve így festenek:
Ami az erőforrások és a figyelem elosztását illeti, az általános hüvelykujjszabály szerint először mindig az elvárt funkciókat érdemes rendbe tenni, mert ha ezek hiányosak, a teljesítmény- és az izgalmi funkciók sem tudnak valódi elégedettséget generálni.
Hogy az egyes kategóriákon belül hogyan érdemes kialakítani a prioritásokat, abban a fontosság átlaga segíthet.
Ha van rá lehetőség, érdemes azt is megnézni, hogy az egyes válaszadói csoportok (például célcsoportot vagy perszónákat definiáló kritériumok szerint felosztva) hogyan értékelték a funkciókat. Markánsan eltérhet például a meglévő felhasználók véleménye arról, hogy mi tartozik az elvárt funkciók közé azokétól, akik még nem találkoztak a termékünkkel.
A diszkrét elemzés egyszerű, de emiatt nem is tökéletes. A válaszok összesítése során elveszik minden olyan felhasználónak a véleménye, aki nem a leggyakoribb kategóriába sorolta az adott funkciót. Emellett egyenlő súlyt kapnak a “puha” és a “kemény” válaszok, azaz nem tudjuk például, hogy egy adott elvárt funkció kifejezett alapelvárás a felhasználóknak, vagy a többségnek inkább semleges a megléte — “I expect it” versus “I’m neutral” válaszok a funkcionális kérdésre.
A folytonos analízis szerencsére kezelni tudja ezeket a problémákat. (Kevésbé szerencse, hogy azzal most nem foglalkozunk.)
Minden nagyon jó lesz
Ezekkel az ismeretekkel felvértezve, és hatalmas lelkesedéssel vágtunk bele tehát a Kano-modell tesztelésébe.
Kerestünk egy, még release előtt álló belső fejlesztést, ahol úgy gondoltuk, gyakorlati haszna lehet a kutatási eredményeknek. A választás egy tervezett e-learning rendszerre esett, ami támogatja majd az információátadást az onboarding során, és a meglévő mitósok számára is lehetőséget biztosít a szakmai továbbfejlődésre. Kísérleti egérnek tökéletes volt a projekt, mert a csapat nem volt még biztos abban, hogy a lehetséges funkciók közül mit lenne érdemes megvalósítani, és elég mitóst is érintett ahhoz a fejlesztés, hogy a méreteinkhez viszonyítva nagy mintán tudjuk megfuttatni a kérdőívet.
Egy workshop keretében bemutattuk tehát a Kano-modellt a projektcsapatnak, közösen kiválasztottuk a vizsgálandó funkciókat és a teszt szempontjából releváns divíziókat, illetve átültettük magyarra a kérdőívet. És az első problémákba is itt futottunk bele.
Bár több verzió is felkerült a whiteboardra, no brainernek tűnt a válaszlehetőségek első körben kiválasztott fordítása:
- I like it = Nagyon örülnék neki
- I expect it = Alapelvárás számomra
- I’m neutral = Mindegy
- I can tolerate it = Meglennék nélküle
- I dislike it = Nem lenne jó
A kérdőívet interjúhelyzetben tesztelve kiderült azonban, hogy az “Alapelvárás számomra” megfogalmazás túl erős, és nehezen értelmezhető, hogy miben különbözik a “Nagyon örülnék neki” lehetőségtől. Látszott, hogy a válaszadók skálaként tekintenek a válaszlehetőségekre, ráadásul alapelvárásaikat az örömöt okozó funkciók fölé helyeznék. Kiderült az is, hogy bizonyos funkciók kontextusért kiáltanak: a válaszadók az értékeléshez tudni szeretnék, milyen más funkciókkal járnak majd együtt vagy mi helyettesítené őket, ha hiányoznának.
A funkciók sorrendjét a könnyebb értelmezést segítendő átalakítottuk tehát, a problémás leírásokat és a válaszlehetőséget pedig átfogalmaztuk:
- Nagyon örülnék neki
- Erre számítanék
- Mindegy
- Meglennék nélküle
- Nem lenne jó
A kérdőívet kiküldtük négy divíziónak, majd ötven válaszadó után ismét összedugtuk a fejünket egy második workshop keretében, hogy feldolgozzuk, és értelmezzük az eredményeket, illetve interjút készítsünk az egyik kitöltőnkkel arról, hogy mi alapján válaszolta meg a kérdéseket.
Az elemzés megmutatta, amire az elmélet figyelmeztetett: a diszkrét analízisben sok információ elveszik, a folytonos elemzés pontosabban követi a válaszok arányainak alakulását.
A kérdőívvel viszont további problémákba ütköztünk:
- A válaszadók hajlamosak arra, hogy a funkcionális és diszfunkcionális kérdést megpróbálják önellentmondás nélkül megválaszolni, tehát a (skálának értelmezett) válaszlehetőségek közül ellentéteseket vagy a két “Mindegy” opciót választani. Ez a teljesítmény- és indifferens funkciók a valóságosnál nagyobb súlyához vezethet az eredményekben; jellemzően az elvárt funkciók kárára.
- A diszfunkcionális kérdés értelmezése a tagadó megfogalmazás miatt kognitív erőfeszítést igényel — ezen pedig a további logikai csavart jelentő “Meglennék nélküle” válaszlehetőség sem segített.
Úgy döntöttünk tehát, hogy futunk még egy kört a módszertan tesztelésével. Az eredmények és a visszajelzések alapján tovább finomítottunk a válaszlehetőségek megfogalmazásán:
- Kifejezetten örülnék is neki, ha így lenne
- Erre számítanék, így várom el
- Mindegy, nem számít nekem
- Nem örülnék neki, de el tudnám fogadni
- Nagyon rossz lenne, ne így legyen
Emellett kipróbáltunk egy olyan megközelítést is, ahol egyetlen kérdéssel teszteltük a funkciókat — Ha X funkció elérhető lenne, mit gondolnál? — , már a válaszlehetőségekben megfogalmazva az öt Kano-kategóriát:
- Elvárom, hogy így legyen, és kifejezetten bosszantana, ha nem (required)
- Nagyon örülnék neki, ha így lenne, és kifejezetten bosszantana, ha nem (performance)
- Örülnék neki, ha így lenne, de nem bosszantana, ha nem (excitement)
- Mindegy lenne, ez nem számít nekem (indifferent)
- Kifejezetten bosszantana, ha így lenne, és örülnék neki, ha nem (reverse)
Ettől a megoldástól azt vártuk, hogy mérsékelni tudja a válaszlehetőségek skálaként való értelmezését, emellett a tagadó kérdés kivételével csökkenti a válaszadók kognitív terhelését. Bónusz öröm volt, hogy a megválaszolandó kérdések mennyisége is jelentősen csökkent így.
Az egykérdéses opció csúnyán elbukott a teszten: a válaszadók inkonzisztensen és aránytalanul a performance kategória felé húzva értékelték a funkciókat. A funkcionális és diszfunkcionális kérdéseket megtartó, sokadik körben iterált válaszlehetőségekkel operáló megközelítés jobban szerepelt, de az elvárt funkciók feltárása továbbra is problémásnak tűnik. (Kontrollként betettünk egy egyértelműen required — azaz kifejezett elégedettséget nem okozó, de alapelvárás — funkciót a kérdőívbe, ami csak egy hajszál híján kerülte el a performance besorolást.)
Diszfunkcionális funkcióértékelés
Szóval hogyan is állunk most a Kano-elemzéssel? Röviden: az elméletet megszerettük, a módszertant kevésbé.
1. Az elvárt funkciók feltárását több probléma is hátráltatja a kérdőíves megoldásban.
A válaszadók skálaként értelmezik a válaszlehetőségeket, az elvárás és az öröm egymáshoz képesti hierarchiája pedig nem egyértelmű.
Arra is törekszenek emellett, hogy a funkcionális és diszfunkcionális kérdést konzisztensen válaszolják meg, így bizonyos kategóriák kisebb eséllyel jelennek meg az eredmények között.
2. A diszfunkcionális kérdés értelmezése a tagadás miatt nehézkes, különösen, ha szintén tagadó válaszlehetőséggel párosul.
Bizonyos funkciók esetén ki lehet küszöbölni a tagadó kérdésfeltevést a funkció hiányának más megfogalmazásával, ez azonban nem mindig lehetséges:
Funkcionális: Ha elvégezhetnéd más divíziók kurzusait, hogy éreznél?
Nem tagadó diszfunkcionális: Ha csak a saját divíziód kurzusait végezhetnéd el, hogy éreznél?Funkcionális: Ha a tananyagokhoz kapcsolódóan lenne kommentelési lehetőség, hogy éreznél?
Nem tagadó diszfunkcionális: ¯\_(ツ)_/¯
3. A hagyományos Kano-kérdőív nem tudja kontextusban értelmezni a funkciókat, pedig azok valós megítélése sok esetben attól is függ, hogy milyen más funkciók kísérik őket.
Emellett relevanciát sem vizsgál, vagyis nem tudjuk, mik a felhasználók szokásai és ismeretei, amikhez viszonyítva megítélik a funkciókat. Ez persze részben (de nem teljesen) kezelhető a kérdőív további kérdésekkel való kiegészítésével.
Long story short, eredeti formájában egy ideig még biztosan nem fogjuk használni a módszertant, de arra kíváncsiak vagyunk, és tervezzük is kipróbálni, hogy kvalitatív interjú keretében — ahol a választás mögött meghúzódó okok jobban feltárhatók, és az értelmezési kérdések is kezelhetők — , akár kártyarendezéssel párosítva hogyan működne.
A Kano-kategóriák pedig mindenképpen hasznosak abban, hogy emlékeztessenek rá, nem érdemes binárisan gondolkozni, ha egy termék funkcióinak felhasználói elégedettségére gyakorolt hatására vagyunk kíváncsiak.
Kíváncsiak vagyunk arra is, másoknak milyen tapasztalataik vannak a Kano-elemzéssel (vagy egyéb funkcióértékelési módszertanokkal). Szóval ha kikívánkozna belőled bármilyen hozzászólás, azt így várjuk: (ノ^ヮ^)ノ*:・゚✧
Rólunk
A Mito kreatív és digitális ügynökség, és az ügynökségi munkák mellett komoly fejlesztéseket is végzünk, büszkék vagyunk rá, hogy többek közt az OTP Bank, a Magyar Telekom, a Deutsche Telekom, a WIZZ Air, a Szerencsejáték Zrt., valamint az izlandi lottótársaság számára szállíthatunk webes és mobil megoldásokat.