Er zijn onnoembaar veel manieren om te achterhalen wat er allemaal in een toekomstig ding (product of dienst) moet zitten. Op mijn werk doen we dat meestal met een combinatie van

• wat denkt de klant dat er allemaal in moet zitten?
• wat wordt er in vergelijkbare situaties gedaan?
• wat doen de eindgebruikers nu, wat zijn hun al dan niet uitgesproken wensen en verzuchtingen? (die we achterhalen via observaties, gesprekken, interviews, workshops, etc. etc.)
• wat denken experten (wijzelf, bijvoorbeeld, haha) dat er zou moeten in zitten?

Ik kwam een tijdje geleden het Kano-model tegen, en ik was gecharmeerd. Noriaki Kano werkte in de jaren 1980 een model uit waarbij hij de (on)tevredenheid van een gebruiker uitzet ten opzichte van het al dan niet aanwezig of goed uitgewerkt zijn van iets — en op basis van de verhouding tussen die twee, verschillende types requirements identificeerde.

Stel dat we een voordeur willen:

• Een deur die niet op slot kan, is onaanvaardbaar. Een deur die wel op slot kan, is normaal.
• Een deur die slecht isoleert, is minder aanvaardbaar dan een deur die beter isoleert. En een deur die uitstekend isoleert, is nog beter.
• Een deurslot met een sleutel die bij verlies van op afstand kan onbruikbaar gemaakt worden is fantastisch, maar als dat er niet is, is het geen breekpunt.

Dat zijn de volgende types requirements:

• Basic requirements: moeten er absoluut zijn, en iedereen verwacht dat ze er zijn. Niemand zegt er iets over, tenzij ze er niet zijn.
• Performance requirements: typisch de dingen die mensen vragen. Hoe beter de vraag vervuld wordt, hoe beter de mensen het vinden.
• Excitement requirements: mensen vragen er niet noodzakelijk om, maar vinden het wel fantastisch vinden als ze er zijn. Als ze er niet zijn, is er niets aan de hand.

Van het deurvoorbeeld is het al duidelijk dat die dingen in de tijd verschuiven: wat nu voor veel mensen een excitement requirement is (een deurbel deurbel met een ingebouwde camera die op uw telefoon aanbelt), is binnenkort wellicht iets dat meer en meer mensen gaan vragen, en wie weet wordt het ooit een basic requirement.

Of neem betalen door een QR-code te scannen: jaren geleden een onverwacht fijne extra, maar nu hard op weg om bijzonder vervelend te zijn als het er niét is bij pakweg een doktersbezoek.

Schematisch wordt dat zoiets:

• Hoe beter aan een basic requirement voldaan wordt, hoe minder ontevreden mensen zijn. Maar het gaat mensen niet speciaal tevreden maken.
• Performance requirement: hoe beter er aan voldaan wordt, hoe meer tevreden de mensen zijn. Hoe slechter, hoe meer ontevreden.
• Niemand wordt ontevreden als een bepaalde excitement requirement er niet is, maar hoe beter er aan voldaan wordt, hoe meer content de mensen.

Het leutige is dat het relatief eenvoudig is om te achterhalen wat voor soort requirement een bepaald iets is. Voor elk ding dat moet onderzocht worden, stelt men twee vragen: één keer positief en één keer negatief. Dus voor dat betalen bijvoorbeeld:

1. Als ge bij de huisarts zoudt kunnen betalen met uw online banking app, door zo’n QR-code in te scannen, hoe zoudt ge u daarbij voelen?
2. Als het niet mogelijk zou zijn om te betalen met uw online banking app bij de huisarts door zo’n QR-code in te scannen, hoe zoudt ge u daarbij voelen?

De modelijke antwoorden zijn telkens dezelfde:

1. Ik zou dat graag hebben.
2. Zo zou het moeten zijn.
3. Het kan mij niet echt schelen.
4. Tja. Ik zou er mee kunnen leven.
5. Het zou niét zo mogen zijn.

…en dan moeten gewoon de antwoorden op de positieve vorm en de negatieve vorm naast elkaar gelegd worden, en kunnen we er dit tabelletje bij halen, waar nog een aantal nieuwe soorten requirements in staan:

		Positief
		Graag	Moet	Neutraal	Tja	Nee!
Negatief	Graag	Questionable	Reversed	Reversed	Reversed	Reversed
	Moet	Excitement	Indifferent	Indifferent	Indifferent	Reversed
	Neutraal	Excitement	Indifferent	Indifferent	Indifferent	Reversed
	Tja	Excitement	Indifferent	Indifferent	Indifferent	Reversed
	Nee!	Performance	Basic	Basic	Basic	Questionable

• Questionable requirements: tegenstrijdigheden. Ik kan niet tegelijk zeggen dat ik graag zou hebben dat ik is kan én graag zou hebben dat ik het niet kan. Dat wil meestal zeggen dat de persoon die de vraag beantwoordde de vraag niet begrepen heeft. En/of dat de vraag verkeerd gesteld is.
• Indifferent requirements, in het midden van de tabel, zijn dingen die het verschil niet gaan maken. Mensen worden er noch warm noch koud van. Als ik vind dat ik bij een dokter eigenlijk zou moeten kunnen betalen met een QR code (“zo zou het moeten zijn”), maar ik zou er mee kunnen leven als het niet zou kunnen, dan kan het mij eigenlijk al met al niet zeer hard schelen.
• Reversed requirements: dingen die mensen niét willen. Bijvoorbeeld reclame die mijn Youtubefilmkes onderbreekt.

Wel leutig, ja.