Le modèle de KANO: si précieux pour …

Comprendre les besoins de vos utilisateurs
Cerner les usages
Prioriser vos développements
Piloter votre stratégie (par exemple au travers de votre backlog Scrum)

Ou tout simplement CONNAITRE votre produit.

Pourtant le modèle de Kano a presque 25 ans…
mais vous pouvez toujours aussi facilement l’appliquer, à vos propres réalisations, comme aux nouvelles applications en ligne de Google ou à tout autre service ou produit IT.

Les clés de son succès : sa simplicité, et surtout le recours aux UTILISATEURS qui font de ce modèle d’aide à la décision un pur outil de Conception Centrée Utilisateurs, utilisable notamment par l’ergonome ou les chefs de produit.

En bref, le modèle de KANO se propose de mettre en relation satisfaction des exigences (réponse aux besoins) et satisfaction Client, en distinguant notamment 3 types d’exigences, véritables piliers stratégiques, dont le degré de mise en oeuvre influencera différemment le degré de satisfaction du Client.

Exigences obligatoires (« Basic needs », « Must Have »)

Ces exigences basiques ne sont pas toujours exprimées; elles sont pourtant évidentes pour le Client et doivent être impérativement satisfaites. Ce n’est pas un levier de satisfaction , en revanche si vous les avez pas, « vous êtes mort ! » Elles ne sont pas forcément prioritaires en terme de développement mais devront être là le jour J.
(ex: Freins d’une voiture; un lit dans une chambre d’hôtel …)

Exigences exprimées, linaires (« Performance needs », « Linear »)

Le besoin est exprimé et la satisfaction du client est proportionnelle au niveau de performance (et de qualité) de ce qui est implémenté. C’est un fort levier de satisfaction Client et un axe prioritaire pour le Développement, à faire valider très vite par les Utilisateurs.
(ex: la taille d’une chambre d’hôtel…).

Exigences latentes, attractives (« Exciters », Delighters »)

Ces exigences correspondent à un besoin pas forcément exprimé, parfois inconscient. C’est l’heureuse surprise qui peut faire la différence, source de satisfaction importante parfois à peu de frais ! En revanche, l’absence de cette fonctionnalité ne sera pas source d’insatisfaction, de frustration. En terme de développement, elles ne sont donc pas prioritaires (sauf stratégie produit spécifique).
(ex: la coupe de champagne à l’arrivée, le wifi dans l’avion …).
C’est aussi le levier de l’innovation par excellence.

Évidemment une fois établi, le modèle n’est pas figé et telle ou telle fonction aura tendance à descendre (vers le Must have) au bout de quelques temps. Regardez ce qui se passe dans l’univers mobile.

AU FAIT, COMMENT CA MARCHE ?

C’est très simple, sélectionnez un panel d’utilisateurs représentatif (20…30), passez leur un questionnaire, analysez les réponses et prenez les bonnes décisions.

Temps 1: Consultation des utilisateurs (par questionnaires principalement) sur chaque fonction par l’intermédiaire d’une paire de questions (fonctionnelle et dysfonctionnelle)

Temps 2: Analyse des réponses pour chaque fonction et pour chaque utilisateur interrogé : au final 6 catégories possibles (I= Indifférente; Q=Incertaine; R=Inversée, et les 3 principales)

Temps 3 : Distribution et résultat final de chaque fonction.

La fonction x est un « Must Have »
La fonction y est un besoin exprimé « Linear »
La fonction z est une exigence attractive « Exciter »

La synthèse vous apportera entre autres de précieux éléments pour définir l’ordre d’implémentation des exigences.
Alors Convaincus ?

2 Comments

  1. Jeff Patton propose une décomposition similaire, orientée utilisateurs mais un peu plus proche du fonctionnel dans les termes : il s’agit de décomposer les tâches utilisateur en fonctionnalités suivant 4 catégories : Indispensable / Flexibilité / Sécurité / Confort.

    "Indispensable" parle d’elle-même. "Flexibilité" correspond à l’idée des options sur une voiture, c’est quand même mieux de les avoir si on peut. "Sécurité" porte son nom (identification, etc.). Et "Confort" correspond à l’efficacité et le plaisir d’utilisation.

    Pour planifier les itérations, on essaie donc de réaliser un petit peu de chaque catégorie. De cette façon en cas de retard sur une release, on ne livrera pas 4 fonctionnalités sur 5 avec la 5ème qui possédait une part d’indispensable pour pouvoir utiliser l’outil, mais plutôt les 5 avec un degré de confort différent. Sachant que l’Agilité consiste à ne pas sacrifier la qualité, surtout sur les fonctionnalités indispensables.

    Pour en savoir plus, tout est dans cette excellente présentation de Jeff Patton : http://www.agileproductdesign.co...

    Note: Patton parle de classifier les tâches elle-mêmes dans ces catégories, et non une décomposition. Pour moi c’est le principe qui est intéressant, quelquesoit ce à quoi on l’applique.

  2. Merci pour ta réponse.
    Je ne connais pas la décomposition de Jeff Patton et le mode de planification qui en découle, mais disons que l’un des intèrêts du modèle de KANO (par rapport à d’autres) est qu’il repose sur le feedback d’utilisateurs représentatifs. Ceux-ci sont en effet intérrogés (questionnaires la plupart du temps, ou entretiens).

    Donner les priorités aux exigences est une vraie bonne pratique désormais répandue… Reste à savoir sur quels critères on fixe les priorités, et comment on procède.

    Le modèle de Karl Wieger, décrit dans son bouquin "Software Requirements" est aussi trés utilisé. Il se base sur le coût, la valeur et le risque mais n’implique pas forcément les utilisateurs (même si indirectement cela doit être le cas). L’IEEE propose encore un modéle plus simple (essential/ conditional / optional) …

    La question du risque me paraît importante : elle ne doit pas être sous estimée.
    Pour simplifier, je dirais les priorités peuvent se jouer sur la valeur pour le client (principe fort de l’Agilité) et à la capacité de lever des risques (eux mêmes liés en partie à la valeur … dans l’esprit UP). Dans ce cadre là, le modèle de Kano fournit un éclairage précieux.

Les commentaires sont fermés.