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:

  1. 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.
  2. Az egyes funkciók meghatározott kategóriákba sorolhatók a felhasználók elvárásainak és preferenciáinak megfelelően.
  3. A felhasználók elvárásai megismerhetők egy egyszerű kérdőív segítségével. Oh, about that…
Apró spoiler

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.

Látni fogjuk, hogy az elégedettség nem minden esetben mozog lineáris skálán.

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.

A felhasználó szempontjából lényegében vagy nincsenek ezek a funkciók (és akkor nagyon idegesek), vagy vannak (és akkor minden oké, de azért nagyon izgatottak nem lesznek tőlük).

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.

Az elvárt funkcióktól eltérően a felhasználók általában meg tudják fogalmazni, mely funkciók tartoznak ebbe a kategóriába.

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.

A teljesítményfunkciók mellett a versenyelőny alapjai, az élettartamuk viszont véges.

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.

Hasznos funkciók is tartozhatnak ebbe a kategóriába, ha a felhasználók számára nem egyértelmű az előnyük (pl. túlzott komplexitás miatt).

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.

Az energiát és erőforrásokat abba érdemes fektetni, hogy feltérképezzük és elkerüljük ezeket a funkciókat.

“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 gifekről írtam a szakdolgozatom 2016-ban. Azóta már nem lelkesedem értük — és lám, mégis…

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:

  1. 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).
  2. 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.
  3. 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:

Amikor még azt hittük, szuperkönnyű volt lefordítani a válaszlehetőségeket.

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):

  1. Az egyes válaszadók adott funkciókra vonatkozó válaszait kategorizáljuk a táblázat szerint.
  2. 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?
  3. 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.)
  4. 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 Mito Adu — teljesített kurzusokért szerezhető, mindenféle perkre beváltható virtuális kártyák — a diszkrét elemzés szerint indifferens funkció, pedig csaknem ugyanannyian sorolták az excitement kategóriába is, sokaknak pedig performance funkció volt. A folytonos elemzés korrigál: ott alacsony fontosságú excitement funkció lett.

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.

Call us Ann.

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.

A cikk eredetileg az alábbi címen jelent meg:
https://medium.com/mito/kano-5714e6d9bab3?source=rss—-33358fde64d4—4