Kanomodel – måder at bruge den på og IKKE bruge den

Kano-modellen er en teori om produktudvikling og kundetilfredshed, der blev udviklet i 1980’erne af professor Noriaki Kano, og som inddeler kundernes præferencer i fem kategorier. Den indeholder teknikker, der hjælper os med at forstå kundernes synspunkter på produktfunktioner ved at vurdere to mål for hver funktion: tilfredshed og følelse. Svarene på disse to målinger vil falde ind under en af de fem kategorier: Attraktivt, Ydeevne, Ligegyldigt, Skal være, Uønsket.

Sådan bruger du det

Oprettér et spørgeskema, hvor hver funktion er opført separat. For hver funktion skal du ideelt set demonstrere, hvad funktionen kan gøre ved hjælp af en prototype eller en interaktiv wireframe, hvis det er muligt. Brug ikke meget tid på at lave prototyper til dette: det er bare en prototype for at få idéen frem. Nogle mennesker kan blive meget optaget af detaljerne selv i prototyper, fordi de måske kan lide ideen, men ikke hvordan den er implementeret.

Pro-tip: I diskussion med andre IBM-forskere har de, der havde størst succes, testet 15-20 funktioner. De, der havde mindre succes, testede 30-40. At teste mere end 20 funktioner var en overvældende mængde data, både for kunderne og for forskerne at analysere.

Når de har set hver funktion, vælger brugerne deres svar på Kano-spørgeskemaet:

1. Hvis du havde (funktion), hvordan har du det så?
2. Hvis du ikke havde (funktion), hvordan har du det så?

(Daniel Zacarias har nogle glimrende tips til, hvordan man skriver disse spørgsmål på en klar måde)

De standardiserede Kano-spørgeskemabesvarelser på begge de ovennævnte spørgsmål er:

1. Jeg kan lide det
2. Jeg forventer det
3. Jeg er neutral
4. Jeg kan tolerere det
5. Jeg kan ikke lide det

Daniel Zacarias tilbyder også nogle andre muligheder for svarsættet til disse svar. I bund og grund skal du læse hele hans artikel, hvis du vil prøve Kano-modellen. Den er fantastisk.

Jan Moorman anbefaler også, at man tilføjer et tredje spørgsmål: Hvor vigtig er denne funktion? Hun anbefaler, at man bruger en ni-punkts Likert-skala fra “Slet ikke vigtig” til “Ekstremt vigtig”. Men når man forsøger at stave de ni punkter på Likert-skalaen for vigtighed, er det … lidt tricky. Det ser ud til, at syvpunkts Likert-skalaen er nemmere.

Når man har svarene, er der en analyseproces, som Daniel Zacarias beskriver meget detaljeret. Jeg anbefaler på det kraftigste, at du læser den igennem.

Et problem, som forskerne hos IBM fandt, var, at det var godt at have disse tal, men at tallene i sig selv ikke fortalte nogen hvorfor, hvilket er det uundgåelige spørgsmål, som vi alle vil få fra vores ledelsesteams. Et hold brugte Kano-modellen til at gennemføre omkring 15 kvalitative interviews. Et andet hold gennemførte 5 kvalitative interviews efter at have fået spørgeskemaer fra 40 personer. Begge teams anbefalede kraftigt at tilføje kvalitative interviews til denne proces, da det tilføjede den fortælling, der er med til at give dataene den manglende kontekst.

Hvordan man IKKE bruger den

Et af de IBM-teams, der brugte Kano-modellen, var tøvende med hensyn til at bruge den igen. Dette hold opstillede spørgeskemaet ved hjælp af scenarier, som de mente var den nuværende måde, tingene fungerede på, for at beskrive funktionerne. Men efterhånden som testen skred frem, blev det meget hurtigt tydeligt, at designteamets scenarier ikke afspejlede, hvordan kunderne faktisk brugte produktet, og testen afsporede hurtigt.

Den idé at bruge scenarier til at beskrive funktionerne er god, men da vi diskuterede deres fremgangsmåde, blev det klart, at scenarierne skal valideres på forhånd. Kombinationen Kano + scenarier ville være effektiv efter generativ forskning, der fastlægger den nuværende situation.

Et andet råd var at nedskalere antallet af funktioner, der testes. Det hold, der tog sig af en lang liste med 30-40 funktioner, sagde, at det var lidt for intensivt, og at kunderne blev overvældet og udmattet ved slutningen af testen.

Fordele

Kano-modellen er meget god til at prioritere funktioner. En teori, der ligger til grund for Kano-modellen, er det, Daniel Zacarias kalder “the natural decay of delight”. Innovative idéer og produkter bevæger sig fra at være spændende og nye, øverst på Kano-diagrammet (Attraktivt) til forventede funktioner, nederst (I bedste fald must-haves, i værste fald detractors).

Tag trådløst internet som et eksempel*. Det er 2001, og du er på rejse i forbindelse med dit arbejde, og du har en topklasse bærbar computer med Ethernet-port og WiFi. Du er på et hotel, og du finder ud af, at de har ethernet-porte, så du kan oprette forbindelse til internettet. De har ikke trådløst internet inkluderet i værelsesprisen, men du kan få WiFi i deres businesscenter. Du er helt oppe at køre! Det er fantastisk! Sikke nogle fantastiske muligheder!

Fast forward til 2017. Du rejser på forretningsrejse og har en simpel bærbar computer med WiFi. Du er på et hotel, og du finder ud af, at de har ethernetporte, så du kan oprette forbindelse til internettet. De har ikke trådløst internet inkluderet i din værelsespris, men du kan få WiFi i deres businesscenter. Du er rasende! Hvilken planet er dette hotel fra, at du skal betale ekstra for internet?! Og hvem bruger stadig deres ethernet-port til at oprette forbindelse til internettet længere?

Det, der startede som en attraktiv funktion (ethernet-porte på værelset og WiFi i businesscentret), blev 16 år senere til en uønsket funktion.

Hvis teams ikke er klar over, hvad kunderne ønsker, kan de fokusere på funktioner, der er forventede i stedet for attraktive. En af de IBM-forskere, der havde brugt Kano-modellen, bemærkede dette på sit eget team: “Der var nogle funktioner, som holdet var meget begejstrede for, og så indså de, at de var en slags bordspil.”

Endnu et potentiale

Da vi diskuterede Kano-modellen, teoretiserede vi, at den også har potentiale til et par andre ting:

1. Måling af dybden af smertepunkter
2. Basering af funktioner over en produktlivscyklus for at vurdere det naturlige forfald af glæde over tid

Dybden af smertepunkter

Denne model kunne være med til at afsløre, hvor slemme eksisterende smertepunkter er. Kano spørgeskemaet egner sig nemt til at give mulighed for forskning til at grave dybere for at lære mere om, hvorfor smertepunkterne er så slemme, som de er, og hvorfor disse funktioner er så vigtige for kunderne. Det kunne afsløre nogle tidligere uidentificerede behov og føre til yderligere innovation.

Baselining af funktioner

Vi drøftede at bruge Kano-modellen til at vurdere funktioner regelmæssigt for at observere, hvilke funktioner der blev nedgraderet til lavere kategorier. Denne form for langsgående testning, med et tilstrækkeligt stort kundegrundlag, kunne indikere markedstendenser og forventninger og bidrage til fortsat at bevise forskningens værdi over tid. Det kunne også hjælpe teams til at vide, hvornår deres produkt er begyndt at plateauere og har brug for innovative ideer for at vende tilbage til en trendsættende status.

Offentligt spørgsmål

Sommetider fungerer designteams hos IBM som konsulenter for projekter. Nogle designteams hos IBM bliver bedt om at komme ind på et projekt for at “rydde op i brugervenligheden” og drysse det magiske UX-støv på et produkt kort før lanceringen. Andre designteams er midlertidigt indlejret i et bredere produktteam.

Vi stod tilbage med et åbent spørgsmål ved afslutningen af vores diskussion: Er Kano-modellen brugbar, hvis man ikke kan påvirke produktet? Du kan måske ikke påvirke produktet, fordi det allerede er under udvikling, på grund af ledelsens modstand, fordi designteamet kun midlertidigt er en del af produktteamet osv. Er det det værd at gøre sig umage med at bruge Kano-modellen?

Og måske er den stadig nyttig, selv om man ikke kan påvirke produktet?

Tanker?