L’équipe de conception arrive avec une liste de besoins des utilisateurs pour votre produit. L’équipe d’ingénierie arrive à la table avec un ensemble différent de fonctionnalités. L’équipe de gestion ne veut que les fonctionnalités qui feront gagner de l’argent à l’entreprise. L’équipe de support voit des fonctionnalités totalement différentes qui doivent être corrigées. Comment une équipe produit peut-elle savoir dans quelle direction aller ?
En tant que chercheurs en conception, nous nous appuyons sur ce que les clients disent et font pour lire plus profondément et découvrir ce qu’ils veulent. Cependant, beaucoup d’entre nous ont souvent lutté avec de nouvelles façons de quantifier et de visualiser ces besoins de manière efficace pour que ces équipes s’alignent. Les clients peuvent certainement voter et classer les fonctionnalités, ce qui donne un excellent aperçu, mais ne donne pas toujours cette compréhension plus profonde de ce que sont les must-haves par rapport à ce qui est déjà attendu.
Entrez dans le modèle de Kano.
Le modèle de Kano est une théorie du développement de produits et de la satisfaction client développée dans les années 1980 par le professeur Noriaki Kano, qui classe les préférences des clients en cinq catégories. Il fournit des techniques pour nous aider à comprendre le point de vue des clients sur les caractéristiques du produit en évaluant deux mesures pour chaque caractéristique : la satisfaction et le sentiment. Les réponses à ces deux mesures seront classées dans l’une des cinq catégories : Attractif, Performant, Indifférent, Indispensable, Non désiré.
Comment l’utiliser
Créer un questionnaire avec chaque fonctionnalité listée séparément. Pour chaque fonctionnalité, idéalement vous démontrez ce que la fonctionnalité peut faire à travers un prototype ou un wireframe interactif, si possible. Ne passez pas beaucoup de temps à prototyper pour cela : c’est juste un prototype pour faire passer l’idée. Certaines personnes peuvent vraiment s’attacher aux détails, même dans les prototypes, car elles peuvent aimer l’idée, mais pas la façon dont elle a été mise en œuvre.
S’il n’est pas possible de faire une démonstration des fonctionnalités, une description textuelle explicative fonctionne également bien.
Pro-tip : En discutant avec d’autres chercheurs d’IBM, ceux qui ont eu le plus de succès ont testé 15-20 fonctionnalités. Ceux qui ont moins bien réussi en ont testé 30 à 40. Tester plus de 20 fonctionnalités représentait une quantité écrasante de données, à la fois pour les clients, et pour les chercheurs à analyser.
Après avoir vu chaque fonctionnalité, les utilisateurs sélectionnent leur réponse au questionnaire de Kano :
- Si vous avez eu (fonctionnalité), comment vous sentez-vous ?
- Si vous n’avez pas eu (fonctionnalité), comment vous sentez-vous ?
(Daniel Zacarias a d’excellents conseils pour rédiger ces questions de manière claire)
Les réponses standard du questionnaire Kano aux deux questions ci-dessus sont :
- J’aime ça
- Je m’y attends
- Je suis neutre
- Je peux le tolérer
- Je n’aime pas ça
Daniel Zacarias propose également d’autres options pour le jeu de réponses pour ces réponses. En gros, si vous voulez essayer le modèle de Kano, lisez tout son article. C’est étonnant.
Jan Moorman recommande également d’ajouter une troisième question : Quelle est l’importance de cette fonctionnalité ? Elle recommande d’utiliser une échelle de Likert en neuf points allant de « Pas du tout important » à « Extrêmement important ». Cependant, lorsqu’on essaie d’expliciter les neuf points de l’échelle de Likert pour l’importance, c’est… un peu délicat. Il semble que l’échelle de Likert en sept points soit plus facile.
Une fois que vous avez les réponses, il y a un processus d’analyse que Daniel Zacarias décrit en détail. Je vous suggère fortement d’aller le lire.
Un problème que les chercheurs d’IBM ont découvert est que le fait d’avoir ces chiffres était formidable, mais les chiffres eux-mêmes ne disaient à personne pourquoi, la question inévitable que nous aurons tous de nos équipes de gestion. Une équipe a utilisé le modèle de Kano pour mener une quinzaine d’entretiens qualitatifs. Une autre équipe a mené 5 entretiens qualitatifs après avoir reçu les questionnaires de 40 personnes. Les deux équipes ont fortement recommandé d’ajouter des entretiens qualitatifs à ce processus, car cela a ajouté le récit qui permet de donner aux données le contexte qui leur manque.
Comment NE PAS l’utiliser
L’une des équipes d’IBM qui a utilisé le modèle de Kano a hésité à l’utiliser à nouveau. Cette équipe a mis en place le questionnaire en utilisant des scénarios qu’ils croyaient être la façon actuelle dont les choses fonctionnaient pour décrire les fonctionnalités. Cependant, au fur et à mesure que les tests progressaient, il est devenu très vite évident que les scénarios de l’équipe de conception ne reflétaient pas la façon dont les clients utilisaient réellement le produit, et les tests ont rapidement déraillé.
L’idée d’utiliser des scénarios pour décrire les fonctionnalités est bonne, mais lorsque nous avons discuté de leur approche, il est devenu clair que les scénarios doivent être validés au préalable. La combinaison Kano + scénarios serait puissante après une recherche générative qui établit la situation telle qu’elle est.
Un autre conseil était de réduire le nombre de fonctionnalités testées. L’équipe qui s’est chargée d’une longue liste de 30 à 40 fonctionnalités a déclaré que c’était un peu trop intensif et que les clients étaient submergés et épuisés à la fin du test.
Bénéfices
Le modèle de Kano est très bon pour hiérarchiser les fonctionnalités. Une théorie qui sous-tend le modèle de Kano est ce que Daniel Zacarias appelle « la décroissance naturelle du plaisir. » Les idées et les produits innovants passent du statut d’excitation et de nouveauté, en haut du tableau de Kano (Attractif), aux fonctionnalités attendues, en bas (Les incontournables, au mieux, les détracteurs, au pire).
Prenez l’Internet sans fil comme exemple*. Nous sommes en 2001, et vous voyagez pour le travail, et vous avez un ordinateur portable haut de gamme qui a un port Ethernet et le WiFi. Vous êtes dans un hôtel et vous apprenez qu’il dispose de ports Ethernet pour vous connecter à l’Internet. L’Internet sans fil n’est pas compris dans le prix de la chambre, mais vous pouvez obtenir le WiFi dans le centre d’affaires. Vous êtes enthousiaste ! C’est génial ! Quelles belles options!
Allons de l’avant en 2017. Vous voyagez pour le travail et vous avez un ordinateur portable de base qui a le WiFi. Vous êtes dans un hôtel et vous apprenez qu’ils ont des ports Ethernet pour vous permettre de vous connecter à Internet. L’Internet sans fil n’est pas compris dans le prix de la chambre, mais vous pouvez obtenir le WiFi dans le centre d’affaires. Vous êtes furieux ! De quelle planète vient cet hôtel pour que vous deviez payer un supplément pour l’Internet ! Et qui utilise encore son port Ethernet pour se connecter à Internet ?
Ce qui était au départ une fonctionnalité attrayante (ports Ethernet dans la chambre, et WiFi dans le centre d’affaires), s’est transformé 16 ans plus tard en une fonctionnalité indésirable.
Si les équipes ne sont pas au courant de ce que veulent les clients, elles pourraient se concentrer sur des fonctionnalités attendues plutôt qu’attrayantes. L’un des chercheurs d’IBM qui avait utilisé le modèle de Kano l’a constaté dans sa propre équipe : » L’équipe était très enthousiaste à l’égard de certaines fonctionnalités, puis elle a réalisé qu’il s’agissait d’enjeux de table. »
Potentiel additionnel
En discutant du modèle de Kano, nous avons théorisé qu’il avait le potentiel pour quelques autres choses, aussi :
- Jauger la profondeur des points de douleur
- Spécifier les caractéristiques sur le cycle de vie d’un produit pour évaluer la décroissance naturelle du plaisir au fil du temps
Depth of pain points
Ce modèle pourrait aider à révéler à quel point les points de douleur existants sont importants. Le questionnaire de Kano se prête facilement à permettre à la recherche de creuser plus profondément pour en savoir plus sur les raisons pour lesquelles les points de douleur sont aussi mauvais qu’ils le sont, et pourquoi ces fonctionnalités sont si importantes pour les clients. Cela pourrait dévoiler certains besoins non identifiés auparavant et conduire à de nouvelles innovations.
Baselining features
Nous avons discuté de l’utilisation du modèle de Kano pour évaluer les fonctionnalités sur une base régulière afin d’observer quelles fonctionnalités rétrogradaient dans des catégories inférieures. Ce type de test longitudinal, avec une base de clients suffisamment importante, pourrait indiquer les tendances et les attentes du marché et aider à continuer à prouver la valeur de la recherche au fil du temps. Il pourrait également aider les équipes à savoir quand leur produit commence à plafonner et a besoin d’idées innovantes pour revenir à un statut de créateur de tendances.
Question ouverte
Parfois, les équipes de conception chez IBM agissent en tant que consultants pour des projets. On demande à certaines équipes de conception chez IBM de venir sur un projet pour « nettoyer l’utilisabilité » et saupoudrer la poussière magique de l’UX sur un produit peu avant son lancement. D’autres équipes de conception sont temporairement intégrées à une équipe produit plus large.
Il nous restait une question ouverte à la fin de notre discussion : le modèle de Kano est-il utile si vous ne pouvez pas avoir d’impact sur le produit ? Il se peut que vous ne puissiez pas avoir d’impact sur le produit parce qu’il est déjà en cours de développement, à cause des réticences de la direction, parce que l’équipe de conception ne fait que temporairement partie de l’équipe produit, etc. Est-ce que l’effort d’utiliser le modèle de Kano en vaut la peine ?
Ou, peut-être est-il encore utile même si vous ne pouvez pas avoir d’impact sur le produit ?
Pensées ?