Kano Model
Last updated
Was this helpful?
Last updated
Was this helpful?
Het Kano Model
Bron - Daniel, Z. (z.d.). The Complete Guide to the Kano Model. Geraadpleegd op 23 Mei 2019, van
Dit artikel is gemaakt door Daniel, Z. Gebaseerd op veel research heeft hij geprobeerd het Kano Model inzichtelijk te maken. Aan te geven waar het voor bedoelt is en hoe je het model moet toepassen in jouw eigen onderzoek. Het model is mij allereerst voorgedragen door Alex Scherpens. Ik heb met hem een interview gedaan waarbij hij me in zijn woorden heeft uitgelegd hoe hij het gebruikt en waar het voor dient. Daarbij gebruikt hij dit artikel als voorbeeld.
Het Kano Model is oorspronkelijk gemaakt door Noraki Kano. Een Japanse researcher en consultant die in 1984 een paper heeft geschreven, over methodes hoe je de behoeftes van een gebruiker door middel van features kan aantonen.
Het Kano Model is gebaseerd op de volgende 3 aannames:
Het gebruik van een feature is gebaseerd op de functionaliteit van de feature
Features kunnen in 4 categorieën geplaatst worden
Je kan middels een enquête aantonen hoe gebruikers zich voelen bij een feature.
Het begint met de Customer Satisfaction, hoe fijn vindt een gebruik iets om te gebruiken. Hier heeft Kano een grafiek gemaakt die gaat van total satisfaction (Delight & Excitement) naar total dissatisfaction (Frustration)
Daar tegenover heb je de grafiek van Functionaliteit (Investment, Sophistication of Implementation). Deze gaat van ‘geen functionaliteit’ tot ‘beste functionaliteit’. Deze 2 grafieken zijn de basis voor het Kano Model en bepalen waar in het spectrum een gebruik zich bevindt.
De features kunnen worden onderverdeeld in 4 categorieën. Samen met de functionaliteit en customer satisfaction vormen zij het Kano Model.
1. Performance
Sommige product features werken zoals we denken. Hoe meer we toevoegen aan een product hoe beter hij wordt ervaren. Omdat dit proportioneel met elkaar verbonden is wordt deze lijn ook wel Linear of One-Dimensional genoemd. Elke toevoeging van een feature leidt tot een betere customer satisfaction. Ook moet je er rekening mee houden, dat elke feature een nieuw prijskaartje met zich mee brengt, de investement gaat dus ook omhoog.
2. Must-Be
Andere product features worden gewoon verwacht van een gebruiker, dit zijn Must-Be’s of Basic Expectations. Als deze features er niet zijn wordt het product als niet compleet beschouwt of slecht. Door het toevoegen van deze features zorg je ervoor dat de gebruiker het product niet ‘nog minder’ gaat vinden, maar just zorgt dat hij/zij het product kan gaan gebruiken. De lijn is zoals te zien bij Performance niet linear. Hij draait steeds meer naar een betere functionaliteit maar zal hier nooit overheen gaan. De features die hier in vallen zullen nooit voor een betere satisfaction kunnen zorgen bij de gebruiker.
3. Attractive
Features die hier onder vallen zijn niet verwachte features, onaangename verrassingen die een positieve reactie geven op de gebruiker. Deze categorie wordt ook wel Exciters of Delighters genoemd. Dit zijn extraatjes waar je als gebruiker blij van wordt. Denk eraan dat de features in deze categorie je niet letterlijk hoeven weg te blazen. Het is al genoeg als je bij deze feature denkt over “oh dat is fijn”. Zoals je ziet kan een klein beetje extra functionaliteit voor een enorme boost geven in attractiveness. Wel moet je oppassen dat je niet teveel toevoegt. Dan kan dit weer als irritant worden ervaren.
4. Indifferent
Deze features vallen onder de categorie ‘meh’. Deze product features laten ons warm noch koud, het maakt niet uit als ze er zijn en het valt ons niet op als als er niet zijn. Het zal de de customer satisfaction niet verbeteren. Het is dus belangrijk om te kijken welke features dit zijn en hier niet te veel aandacht en geld in te investeren.
Deze 4 categorieën maken samen het Kano Model, met als 2 assen de Customer Satisfaction en Feature Functionality. Houd er wel rekening mee dat features kunnen veranderen over tijd. Denk bijvoorbeeld aan een revolutionair touchscreen van iPhone in 2007. Dit werd toen gezien als een WOW. Echter wordt dit nu gezien als een Must. Zonder touchscreen kan je hedendaags niet meer de markt op. De conclusies die getrokken worden uit het Kano Model zijn moment opnames. Als je hetzelfde onderzoek met dezelfde vragen een paar jaar later zou doen, dan krijg je waarschijnlijk hele verschillende antwoorden. Dit heeft naast technologische ontwikkeling ook te maken met concurrenten.
Nu het Kano Model is uitgelegd en je weet waar alles voor staat, wil je deze gaan toepassen. Om de input te krijgen voor het model maak je gebruik van de Kano questionnaire. Hierin maak je een tweedeling. Enerzijds vraag je: hoe zou je het vinden als deze feature er wel zou zijn. Anderzijds: hoe zou je het vinden als deze feature er niet zou zijn. Deze kan je opvatten als open vragen, maar om het gemakkelijk toe te passen in het Kano Model is het verstandig de antwoorden zo op te stellen:
I like it
I expect it
I am neutral
I can tolerate it
I dislike it
Nadat je alle features hebt gevraagd met aan allebei de kanten deze 5 meerkeuze, kan je de antwoorden gaan categoriseren.
De antwoorden laten aan een gebruiker zowel zien hoe graag ze iets willen als hoe graag ze iets niet willen. Alles komt later in dezelfde tabel te staan. Elk antwoord op de tweedelige vraag lijdt tot een vakje in deze tabel. Waardoor je later een goeie volgorde kan maken van prioriteit.
Omdat we het product van 2 kanten benaderen krijg je ook van beide kanten een antwoord. We kunnen uit de antwoorden dit concluderen: Iemand heeft de vraag niet begrepen of begrijpt de voorgestelde feature niet of wat we aanbieden is eigenlijk precies het tegenovergestelde van wat ze willen. Dit zijn 2 nieuwe categorieën die aanbod komen in de tabel. Als een gebruiker aangeeft dat hij de functionaliteit van een feature die er is haat en op hetzelfde moment de functionaliteit van een feature wat er niet is van houdt, kan je ervan uitgaan dat de gebruiker precies het tegenovergestelde wilt van wat jij hebt aangeboden. Deze categorie wordt ook wel de Reverse (R) genoemd. Als je 2 dezelfde antwoorden krijgt op de verschillende vragen. Vinden ze het fijn als een feature er niet is en vinden ze het ook fijn als de feature er wel is, dan kan je er bijna vanuit gaan dat ze de vraag niet goed begrepen hebben. Deze features vallen in de Questionable (Q) categorie. Hier hoef je eigenlijk niets mee te doen, echter krijg je veel Q antwoorden dan is er waarschijnlijk iets fout aan de manier waarop je iets vraagt.
Performance (P) staat voor een feature wat fijn is om te hebben en het vervelend vinden als het er niet is. Must-be (M) features zijn features die worden verwacht door de gebruiker. Ze vinden het vervelend als deze er niet zijn, ze vinden het niet fijn als ze er wel zijn maar ze verwachten dat deze er zijn. Attractiveness (A) zijn de features met het WOW effect. Hier wordt de gebruiker onaangenaam verrast met goeie features waar de gebruiker eerst niet eens aan had gedacht. Je kan goed zien wanneer de Reverse van toepassing is en dat dit waarschijnlijk het tegenovergestelde is van wat de gebruiker wilt.
Door goeie vragen te stellen kan je kijken waar welke product feature bij hoort. Hier kan je een punten systeem aan toevoegen om te achterhalen waar de feature in valt. Hieronder een voorbeeld:
Door het testen bij meerdere gebruikers kan je achterhalen waar deze feature bij hoort en of de vraag goed is gesteld. Door alles in een categorie te zetten kan je vervolgens voor jezelf een lijst maken met features die prioriteit moeten krijgen boven andere features.
Het artikel gaat verder over hoe je het Kano Model kan toepassen en hoe je deze kan testen bij je gebruiker. Hier ga ik verder niet op in.
