Het ontwerpteam komt met een lijst van gebruikersbehoeften voor je product. Het engineeringteam komt aan tafel met een andere set functies. Het managementteam wil alleen die functies waarmee het bedrijf geld kan verdienen. Het support team ziet hele andere features die gerepareerd moeten worden. Hoe weet een productteam welke kant het op moet gaan?
Als ontwerponderzoekers vertrouwen we op wat klanten zeggen en doen om dieper te lezen en te ontdekken wat ze willen. Velen van ons hebben echter vaak geworsteld met nieuwe manieren om die behoeften op een effectieve manier te kwantificeren en te visualiseren, zodat deze teams op één lijn kunnen komen. Klanten kunnen zeker stemmen op functies en deze rangschikken, wat een geweldig overzicht geeft, maar niet altijd dat diepere begrip geeft van wat de must-haves zijn boven wat al wordt verwacht.
Enter het Kano-model.
Het Kano-model is een theorie over productontwikkeling en klanttevredenheid die in de jaren tachtig is ontwikkeld door professor Noriaki Kano, die de voorkeuren van klanten indeelt in vijf categorieën. Het biedt technieken om de kijk van klanten op productkenmerken te begrijpen door voor elk kenmerk twee maatstaven aan te leggen: de tevredenheid en het sentiment. De antwoorden op deze twee metingen vallen in een van de vijf categorieën: Aantrekkelijk, Prestatie, Onverschillig, Must-Be, Ongewenst.
Hoe te gebruiken
Stel een vragenlijst op met elke feature afzonderlijk vermeld. Idealiter demonstreert u voor elke functie wat de functie kan doen door middel van een prototype of interactief wireframe, indien mogelijk. Besteed niet veel tijd aan prototyping: het is gewoon een prototype om het idee over te brengen. Sommige mensen kunnen zelfs in prototypes erg verstrikt raken in de details, omdat ze het idee misschien wel goed vinden, maar niet hoe het is geïmplementeerd.
Als het niet mogelijk is om de functies te demonstreren, werkt een verklarende tekstbeschrijving ook goed.
Pro-tip: In discussie met andere IBM-onderzoekers, testten degenen die meer succes hadden 15-20 features. Degenen die minder succesvol waren, testten er 30-40. Meer dan 20 features testen leverde een overweldigende hoeveelheid gegevens op, zowel voor de klanten als voor de onderzoekers om te analyseren.
Na elke feature te hebben gezien, selecteren gebruikers hun antwoord op de Kano-vragenlijst:
- Als u (feature) had, hoe voelt u zich?
- Als u (feature) niet had, hoe voelt u zich?
(Daniel Zacarias heeft een aantal uitstekende tips over hoe u deze vragen op een duidelijke manier kunt schrijven)
De standaardantwoorden op de Kano-vragenlijst op beide bovenstaande vragen zijn:
- Ik vind het leuk
- Ik verwacht het
- Ik ben neutraal
- Ik kan het verdragen
- Ik vind het niet leuk
Daniel Zacarias biedt ook enkele andere opties voor de antwoordverzameling voor deze antwoorden. Kortom, als je het Kano-model gaat proberen, lees dan zijn hele artikel. It’s amazing.
Jan Moorman beveelt ook aan een derde vraag toe te voegen: Hoe belangrijk is deze eigenschap? Zij beveelt aan een negen-punts Likert schaal te gebruiken van “Helemaal niet belangrijk” tot “Extreem belangrijk”. Maar als je de negen punten op de Likert-schaal voor belangrijkheid probeert te spellen, is dat … een beetje lastig. Het lijkt erop dat de zevenpunts Likert-schaal gemakkelijker is.
Als u de antwoorden eenmaal hebt, is er een analyseproces dat Daniel Zacarias zeer gedetailleerd beschrijft. Ik raad u ten zeerste aan dat eens door te lezen.
Eén probleem dat onderzoekers bij IBM ontdekten, was dat het hebben van deze cijfers geweldig was, maar de cijfers zelf vertelden niemand waarom, de onvermijdelijke vraag die we allemaal van onze managementteams zullen krijgen. Eén team gebruikte het Kano-model om zo’n 15 kwalitatieve interviews af te nemen. Een ander team voerde 5 kwalitatieve interviews uit nadat het van 40 mensen vragenlijsten had gekregen. Beide teams raadden sterk aan kwalitatieve interviews aan dit proces toe te voegen, omdat het het narratief toevoegde dat helpt de gegevens hun ontbrekende context te geven.
Hoe het NIET te gebruiken
Een van de IBM-teams die het Kano-model had gebruikt, aarzelde om het opnieuw te gebruiken. Dit team stelde de vragenlijst op met scenario’s waarvan zij dachten dat het de huidige manier van werken was om de functies te beschrijven. Naarmate het testen vorderde, werd het echter snel duidelijk dat de scenario’s van het ontwerpteam niet weergaven hoe klanten het product daadwerkelijk gebruikten, en het testen ontspoorde snel.
Het idee om scenario’s te gebruiken om de features te beschrijven is goed, maar toen we hun aanpak bespraken, werd het duidelijk dat scenario’s van tevoren moeten worden gevalideerd. De combinatie Kano + scenario’s zou krachtig zijn na generatief onderzoek dat de as-is situatie vaststelt.
Een ander advies was om het aantal te testen features te verminderen. Het team dat een lange lijst van 30-40 features voor zijn rekening nam, zei dat het een beetje te intensief was, en dat klanten aan het eind van de test overweldigd en uitgeput raakten.
Voordelen
Het Kano-model is heel goed in het prioriteren van features. Een theorie die ten grondslag ligt aan het Kano-model is wat Daniel Zacarias “het natuurlijke verval van verrukking” noemt. Innovatieve ideeën en producten evolueren van opwindend en nieuw, bovenaan de Kano-grafiek (aantrekkelijk), naar verwachte kenmerken, onderaan (in het beste geval must-haves, in het slechtste geval detractors).
Neem draadloos internet als voorbeeld*. Het is 2001, je bent op reis voor je werk en je hebt een topmodel laptop met een ethernetpoort en WiFi. Je bent in een hotel, en je verneemt dat ze ethernet poorten hebben voor je om verbinding te maken met het internet. Ze hebben geen draadloos internet inbegrepen in je kamerprijs, maar je kunt WiFi krijgen in hun business center. Je bent stoked! Het is geweldig! Wat een geweldige opties!
Vooruit in 2017. U reist voor uw werk en hebt een eenvoudige laptop met WiFi. Je bent in een hotel, en je ontdekt dat ze ethernetpoorten hebben om verbinding te maken met internet. Ze hebben geen draadloos internet inbegrepen in uw kamerprijs, maar u kunt WiFi krijgen in hun business center. Je bent razend! Van welke planeet komt dit hotel dat je extra moet betalen voor internet?! En wie gebruikt er nu nog zijn ethernet poort om verbinding te maken met het internet?
Wat begon als een aantrekkelijke feature (ethernet poorten in de kamer, en WiFi in het business center), is 16 jaar later veranderd in een ongewenste feature.
Als teams niet goed weten wat klanten willen, kunnen ze zich gaan richten op features die verwacht worden in plaats van aantrekkelijk. Een van de IBM-onderzoekers die het Kano-model had gebruikt, merkte dit in haar eigen team op: “Er waren enkele features waar het team erg enthousiast over was, en toen realiseerde het zich dat die table stakes waren.”
Aanvullend potentieel
Toen we het Kano-model bespraken, stelden we vast dat het ook voor een paar andere dingen potentieel heeft:
- Het meten van de diepte van pijnpunten
- Het baseren van kenmerken over een productlevenscyclus om het natuurlijke verval van vreugde in de loop van de tijd te beoordelen
Diepte van pijnpunten
Dit model zou kunnen helpen om te onthullen hoe erg bestaande pijnpunten zijn. De Kano-vragenlijst leent zich gemakkelijk voor onderzoek om dieper te graven en meer te weten te komen over waarom de pijnpunten zo erg zijn als ze zijn, en waarom deze kenmerken zo belangrijk zijn voor klanten. Het zou een aantal eerder niet geïdentificeerde behoeften aan het licht kunnen brengen en tot verdere innovatie kunnen leiden.
Baselining features
We bespraken het gebruik van het Kano-model om features op regelmatige basis te beoordelen om te observeren welke features degradeerden naar lagere categorieën. Dit type longitudinale testen, met een voldoende groot klantenbestand, kan trends en verwachtingen in de markt aangeven en helpen om de waarde van onderzoek in de loop van de tijd te blijven bewijzen. Het zou teams ook kunnen helpen om te weten wanneer hun product begint te plateau en zijn behoefte aan innovatieve ideeën om terug te keren naar een trend-setting status.
Open Vraag
Soms ontwerpteams bij IBM optreden als consultants voor projecten. Sommige ontwerpteams bij IBM worden gevraagd om op een project te komen om “de usability op te schonen” en het magische UX-stof over een product te strooien kort voor de lancering. Andere ontwerpteams worden tijdelijk ingebed in een breder productteam.
Aan het eind van onze discussie bleven we zitten met één open vraag: is het Kano-model nuttig als je het product niet kunt beïnvloeden? Het kan zijn dat je het product niet kunt beïnvloeden omdat het al in ontwikkeling is, vanwege tegenwerking van het management, omdat het ontwerpteam slechts tijdelijk deel uitmaakt van het productteam, enzovoort. Is het de moeite waard om het Kano-model te gebruiken?
Of is het misschien toch nuttig, zelfs als je het product niet kunt beïnvloeden?
Wat denk je?