Quand j’ai l’opportunité d’utiliser une méthode UX que je n’ai jamais utilisé avant, c’est toujours la même chose : d’abord l’euphorie « Heeey, cette méthode semble répondre exactement à mon problème, ça va être trop bien ! », ensuite l’excitation « Hiiii, je vais pouvoir interroger des vrais gens, j’adore ça ! » ensuite la désillusion quand il faut vraiment s’y mettre : « Hein, mais attend, comment je suis supposer formuler ça de manière claire et concise ? ».
Bref, tout ça pour dire : voilà quelques notes à propos de la méthode Kano, ça pourra servir à mon moi futur ou à quelqu’un qui passe par là.
La méthode Kano
En quelques mots, le modèle de Kano permet d’évaluer l’impact d’une fonctionnalité sur la satisfaction de l’utilisateur.
Vous avez déjà entendu le dicton qui dit que “ Plus un produit propose de fonctionnalités, mieux c’est ! ”. Si oui, changez de boîte ! Si non, vous pouvez continuer à lire 😅.
Le modèle de Kano est une méthode qui permet de hiérarchiser les fonctionnalités pour ne garder que celles qui apportent du sens et de la satisfaction utilisateur.
Cette méthode propose donc de faire évaluer à des utilisateurs l’interêt d’un ensemble de fonctionnalités pour les classer en différentes catégories :
- Les fonctionnalités indispensables : leur présence n’augmente pas la satisfaction utilisateur mais leur absence à un impact très négatif.
- Les fonctionnalités performantes : ces fonctionnalités ont un lien direct avec la satisfaction utilisateur. Ainsi, leur présence augmente la satisfaction utilisateur quand leur absence diminue la satisfaction utilisateur.
- Les fonctionnalités attractives : Les utilisateurs sont contents d’avoir cette fonctionnalité mais son absence n’engendre aucun problème.
- Les fonctionnalités quelconques : elles n’apportent rien de positif ni négatif sur la satisfaction des utilisateurs.
- Les fonctionnalités répulsives : Leur présence a un impact négatif sur la satisfaction des utilisateurs. Ils pourront être amenés à payer pour s’en débarrasser, ou à aller voir le produit concurrent.
Évidemment, le modèle de Kano est un modèle mouvant : une fonctionnalité peut changer de catégorie avec le temps. Par exemple, une fonctionnalité peut passer d’attractive à indispensable avec le temps et l’évolution de la concurrence. Enfin, cette catégorisation est aussi dépendante de l’utilisateur : il peut donc être intéressant de travailler sur des sous groupes, basés sur des personas par exemple.
En classant chaque fonctionnalité dans une catégorie, on peut alors construire une backlog en priorisant certaines catégories sur d’autres :
Quand utiliser le modèle de Kano
Il se trouve que depuis quelques mois, je note dans un coin des tas d’idées de fonctionnalités qui me sont remontées par des utilisateurs ou par des collègues en interne, mais sans trop savoir où donner de la tête. Certaines me parlent beaucoup, certaines ont l’air chouette, d’autres ne m’émeuvent pas mais parlent énormément à des utilisateurs.
La méthode de Kano me semblait donc la réponse idéale pour m’aider à faire le tri et pouvoir travailler de pair avec notre Product Owner pour construire une backlog cohérente pour notre produit.
Mettre en place le modèle de Kano
Avant toute chose, il est important de choisir les fonctionnalités que l’on va faire évaluer aux utilisateurs : dans le cadre de mon projet, j’ai rassemblé les retours venant du Services Clients, des influenceurs testant nos produits et enfin venant de notre équipe en interne. À partir de cette liste, j’ai d’abord écarté toutes les évolutions ou corrections de bug pour ne choisir que des fonctionnalités nouvelles, que j’ai ensuite limité à 10.
J’ai ensuite pu passer à la rédaction du questionnaire. Le principe de base du modèle de Kano est d’interroger l’utilisateur sur l’absence puis la présence de la fonctionnalité :
Que ressentez-vous si la fonctionnalité est présente ?
- Je suis content·e.
- C’est normal (“Je m’y attendais”).
- Je suis neutre (“Et alors?”).
- Je fais avec (“J’ai pas vraiment le choix…”).
- Je suis mécontent·e.
Que ressentez-vous si la fonctionnalité est absente ?
- Je suis content·e.
- C’est normal (“Je m’y attendais”).
- Je suis neutre (“Et alors?”).
- Je fais avec (“J’ai pas vraiment le choix…”).
- Je suis mécontent·e.
Bon, ça c’est la théorie. Car dans la pratique, j’ai bien galéré à écrire un questionnaire qui aie du sens. Ici, les tests en interne m’ont été très utile pour valider la bonne compréhension de mon questionnaire. En vrac, voici quelques questions que je me suis posées :
- À quel point faut-il rentrer dans les détails pour présenter une fonctionnalité ? Est-ce qu’un titre est suffisamment clair ou faut-il décrire la fonctionnalité en une phrase ou plus ?
- Comment formuler les questions ? Dans mon cas, le produit existe déjà. La question « Que ressentez-vous si la fonctionnalité est absente ? » n’a pas de sens (c’est le cas aujourd’hui mais on envisage de la rajouter). Devrais-je plutôt dire « Que ressentiriez-vous si la fonctionnalité était présente ? » et « Que ressentez-vous à propos du manque de cette fonctionnalité ? ».
- Les questions ne seraient-elle pas plus claires si les fonctionnalités étaient rappelées dans l’intitulé des questions ?
- Mais au fait, à quel temps conjuguer mes questions : « Si vous pouvez visualiser vos statistiques de lecture, que ressentez-vous ? » ou plutôt « Si vous pouviez visualiser vos statistiques de lecture, que ressentiriez-vous ? » ?
- Et les réponses proposées, on en parle ? Certains personnes en interne m’ont remonté ne pas bien comprendre la nuance entre « C’est normal » et « Je fais avec ». Faut-il rajouter une explication ? comme par exemple « C’est normal, je m’y attendais”.
Finalement, après mures réflexions et nombreux tests, j’ai choisi de rédiger mon questionnaire de cette manière :
J’ai donc arbitré de la manière suivante :
- Re-décrire la fonctionnalité dans la question, pour plus de clarté : « Si vous pouvez visualiser vos statistiques de lecture, que ressentez-vous ? » et « Si vous n’avez pas d’informations sur vos statistiques de lecture, que ressentez-vous ? ».
- Simplifier au maximum les réponses proposées, même si certaines réponses sont parfois mal comprises (c’est un problème connu qui ne semble pas déranger l’analyse des résultats d’après Daniel Zacarias qui le mentionne dans son guide complet).
- Préférer le présent au subjonctif.
- Utiliser l’écriture inclusive, parce que vive l’inclusion.
Analyser les résultats
Super, le questionnaire est écrit, les utilisateurs identifiés et prêt à être contactés ! Il n’y a plus qu’à envoyer tout ça, et analyser les résultats.
J’aurais aimé trouver un outil équivalent à kano.plus en français, mais j’ai fait chou blanc. Je suis tombée sur le Kano Model Calculator through Google Sheets mais j’ai abandonné l’idée de le tester : j’ai toujours du mal avec l’idée d’autoriser des obscures applications trouvées sur Internet à accéder à tout mon Google Drive 🤔.
J’ai donc retroussé mes manches pour envoyer le questionnaire par mes propres moyens (ça c’était facile, les outils de questionnaires en ligne ne manquent pas) puis pour analyser moi-même les résultats (et là, ce fut une autre paire de manche !). Mais rien de tel pour mieux comprendre les résultats, non ?
En m’appuyant sur le fichier Excel conçu par Daniel Zacarias (voir le guide complet) puis en bidouillant entre Numbers et Libre Office, j’ai pu réussir à faire fonctionner les formules permettant de calculer le score de chacune des fonctionnalités.
Ensuite, oh joie, il n’y avait plus qu’à placer chacune de mes fonctionnalités sur un graphique pour faire ressortir les catégorisations :
Sur ce graphique (anonymisé pour ce blog), vous noterez que :
- Aucune fonctionnalité indispensable n’est dans notre scope : c’est plutôt bon signe, sachant que notre produit est en ligne depuis un moment déjà !
- Plusieurs fonctionnalités performantes et attractives en vue : youpi, ce sont donc celles là que nous avons tout intérêt à pousser vers le haut de la backlog !
- Une fonctionnalité jugée comme répulsive est identifiée : Oups ! Cette fonctionnalité là devra nécessiter de sérieux arguments de la part de nos équipes marketing pour valoir le coût (aussi bien coût de développement que coût en satisfaction utilisateur !)
Bon, et bien maintenant, il n’y a plus qu’à implémenter tout ça !
Notes 
Coucou, en plein travail pour la certification APICS avec un chapitre (petit) sur les avantages qualifiants et gagnants, j’ai apprécié la lecture et l’éclairage apporté. Merci!
J’aimeJ’aime