Interview Alex Scherpens
23 Mei 2019
Last updated
Was this helpful?
23 Mei 2019
Last updated
Was this helpful?
Gesprek (uitleg), 23 Mei 2019, werking Kano Model
Alex Schepers (Growth Engineer)
Vandaag tijdens de lunch kwam ik in gesprek met Alex Schepers. Alex vroeg aan mij hoe het project vorderden en of ik nog hulp ergens bij nodig had. Tijdens het gesprek kwam aan bod of ik niet al gebruik had gemaakt van het Kano Model en of ik überhaupt wist wat het inhield. Na een korte uitleg leek het mij een goed idee om een afspraak in te plannen zodat hij mij hier nog meer over kon vertellen. Naast dat hij een goed artikel had doorgestuurd, hebben we even gebrainstormd over hoe nu verder, waar de focus moet liggen, wat het Kano Model inhoud en hoe ik dit kan toepassen in het project. Belangrijk voor mij was om te begrijpen op welk punt ik het model kan gaan toepassen en welke waarde de resultaten voor mij zullen hebben.
——————————
(Een deel van het interview is niet opgenomen. Het begint met dat Alex aan het vertellen is over het Kano Model).
Alex laat mij een voorbeeld zien van een Kano Model waar hij op dat moment mee bezig is. Hij verteld dat je uiteindelijk een lijstje krijgt. Je stelt een aantal vragen met meerkeuze antwoorden. Uit die antwoorden kan jij opmaken waar in het Kano Model jouw vraag komt. De vraag kan bijvoorbeeld over een functionaliteit gaan in een app of website die je aan het maken bent. Zo kom je er goed en snel achter welke functionaliteit voor de gebruiker een must zijn en welke je het beste kan schrappen. Als voorbeeld geeft Alex: (dit gaat over een project met het rijksmuseum) ’Stel je vind een museum leuk dan krijg je bijvoorbeeld in jouw chat een aanbeveling voor het rijksmuseum.’ Deze stelling ga je vervolgens 2 delig stellen. 1. Hoe zou je dit vinden als het (de functionaliteit) er wel in (in de app/website) zat. 2. Hoe erg zou je het vinden als dit niet kan. Dus hoe erg wil je dit hebben, maar hoe erg zou je het vinden als dit er niet is. Deze 2 deling is eigenlijk wat je elke keer maakt. En de antwoorden die je dan eigenlijk hebt zijn:
A. Dit verwacht ik gewoon B. Wil ik heel graag C. Boeit me niet zozeer D. Heb ik liever niet maar ik kan er mee leven E. Ik zou dit storend vinden
Uiteraard zijn de antwoorden niet precies zo geschreven, maar op deze manier kan je wel de essentie van3 elk antwoord eruit halen.
Deze antwoorden passen vervolgens in een grafiek, die correspondeert met een tabel.
“Hij laat zien waar de antwoorden passen binnen de grafiek“
A -> Must-Be (Rechtsboven) B -> Attractive (Rechtsboven) C -> Performance (Rechts) D -> Indifferent (Links) E -> Must-Be (Linksonder)
(De antwoorden tussen haakjes geeft aan waar op de lijnen de A-E passen.) Daarna kan je de antwoorden in de tabel plaatsen. De tabel is gevuld met cijfers zodat je precies weet waar het antwoord wat gegeven is past binnen de grafiek. Je ziet 2 kanten van het verhaal. Aan de verschillende letters zitten cijfers vast. Deze cijfers bepalen vervolgens wanneer je alles op een rijtje hebt gezet, welke functionaliteiten volgens jouw doelgroep/gebruiker als eerste naar gekeken moet worden.
Boven aan de lijn van Attractive heb je te maken met een extra. Het boeit hem namelijk niet dat het er niet is. Maar als het er wel is dan is dat mooi meegenomen, een extraatje dus. Je gaat deze functionaliteit niet per se missen in het design. Indifferent betekend dat het ze niet echt boeit of het er wel of niet in zit. Dit zijn de functionaliteit waar je geen focus op hoeft te leggen. Alex geeft aan dat voor mij de belangrijkste dingen zullen zijn (ook met het oog op tijd). Welke functionaliteiten zijn voor mij een must, welke een extraatje en welke zullen juist storend zijn als deze worden meegenomen in het design. Dit is het Kano Model, een privatisering van functionaliteiten die wij (als maker) jou (de gebruiker) voorschotelen. Met de vraag: welke van deze voorgeschotelde functionaliteiten vind jij belangrijk?
De Q in de tabel staat voor Questionable. De antwoorden die in deze categorie passen kun je eigenlijk weggooien. De antwoorden spreken elkaar tegen wat in principe niet kan gebeuren. Daarnaast heb je de R ofwel de Reversed. De Reversed: ik wil eigenlijk het tegenovergestelde van wat jij me hebt aangeboden. Bij een Q’tje is het hoogstwaarschijnlijk dat ze de vraag niet gesnapt hebben. Als voorbeeld. De functionaliteit die wij aanbieden is je hebt meerkeuze, het antwoord is: ik wil graag het als een open vraag beantwoorden. Je hebt dan waarschijnlijk het verkeerde voorgesteld. Hoe je dit kan oplossen is nog een Kano te maken met de vernieuwde vragen. Hierbij pak je de vragen waarop het antwoord R (Reversed) was, je draait deze om en kijkt je nu wel het gewenste antwoord eruit krijgt.
Stap voor stap is dit wat je doet. Je doet onderzoek naar de gebruiker van het product - je maakt het product - je maakt een aanname van de functionaliteiten in het product (deze zullen de gebruikers vast willen hebben) - je test je aannames dmv een enquête met 2 delige vragen - je stelt welke functionaliteiten je wel en welke je niet moet gaan gebruiken - je maakt het product - en vervolgens test je het product met zijn functionaliteiten bij de gebruiker om te zien of eruit is gekomen wat de gebruiker had verwacht.
Alex legt uit wanneer zo’n Kano binnen het proces aan bod komt. De Kano komt nadat je al een grondig onderzoek hebt gedaan naar de gebruiker. Door het doen van bijvoorbeeld interviews. Uit die interviews kan je vervolgens dingen halen die jij kan omzetten naar functionaliteiten voor jouw product/dienst. Wanneer je een aantal mensen hebt gesproken heb je een lijst van functionaliteiten. Iedereen die werkt op een andere manier. De functionaliteiten zijn voor de ene een must en voor de ander een extraatje. Om erachter te komen welke functionaliteiten voor de meeste mensen een must is en voor de meeste mensen een extraatje is, kan door het Kano Model toe te passen.
Alex geeft een aantal voorbeelden hoe verschillende de antwoorden kunnen zijn. Wat belangrijk is om in je achterhoofd te houden is dat het gaat om het gemiddelde. Er zullen altijd een aantal uitschieters zijn die een workshop o.i.d. net iets anders geven.
Er worden meerdere workshops gegeven die allemaal als einddoel iets anders hebben. Wat voor mij heel belangrijk is, is dat ik in eerste instantie moet achterhalen welke van deze workshops prioriteit hebben om aan te passen. Welke worden momenteel het vaakst gegeven en zal ik ook het snelst profijt hebben. Of welke workshops zijn zo outdated, die kan ik het meest aanpassen. Het handigste is om dit eerst te kaderen om mijn scope zo scherp mogelijk te houden.
Het belangrijkste wat naar voren komt is dat ik gewoon met veel mensen moet gaan spreken om te achterhalen wie, wat waar voor gebruikt. (kijken waar ik moet zitten, creativiteit workshops, kader workshops, impressie workshops) Deze 3 komen vaak naar voren en ik zal mij waarschijnlijk dan ook op 1 of 2 van deze 3 gaan focussen. Alex bepaalt zich zelf als een Growth Engineer. Hij houdt zich vooral bezig met hoe kan een product of dienst groeien en ontwikkelen. Waar zitten de pijnpunten.
Alex geeft aan dat het niet het meest belangrijk is dat het product ook daadwerkelijk werkt. Maar meer dat je kan aantonen dat de methode of manier wat je hebt gebruikt om bij dit product te komen, dat dat werkt.
Oke, maar waar past het Kano Model binnen de andere modellen en/of methodes. Wanneer kan ik deze gaan toepassen, of wat kan ik het beste ervoor nog doen?
Je kan dit vergelijken met een WPC (waardepropositie canvas). Dat is vooral kwalitatief, erg op detail en kost veel meer tijd. Het Kano Model zorgt dat je nog kwantitatief kijkt naar alle opties. De vragen kan je heel makkelijk in bulk versturen naar een grote groep, waarbij dit moeilijker kan met een WPC. Hierdoor kan je in een korte tijd veel informatie vergaren.
Het Kano Model komt aanbod wanneer je wel al een product hebt liggen. Je bent namelijk functionaliteiten aan het testen en deze komen niet ineens uit de lucht vallen. Eerst dus kijken in welk kader ga ik zitten (welke workshops). Vervolgens daaruit kijken dmv interviews hoe worden deze toegepast. Welke waardes zitten er allemaal aan deze workshops. Hier kan je functionaliteiten uit definiëren. Deze plaats je vervolgens in het Kano Model, dit ga je dus testen dmv de vragen lijst. En daaruit komen de functionaliteiten die het belangrijkste worden gevonden en die dus prioriteit moeten krijgen in het ontwerp.
Bron (afbeeldingen) - Daniel, Z. (z.d.). The Complete Guide to the Kano Model. Geraadpleegd op 23 Mei 2019, van
