Comment évaluer si les clients utiliseraient une fonctionnalité avancée
Je travaille sur un nouveau design de rapprochement bancaire dans un logiciel de comptabilité. Nous avons identifié les flux de travail existants de nos utilisateurs et les problèmes liés à notre conception actuelle lors d'une précédente série d'entretiens clients.
Quelques suggestions de fonctionnalités supplémentaires pour le rapprochement bancaire sont venues de notre équipe en fonction des autres besoins des utilisateurs qu'ils ont vus dans le passé. Un exemple est la possibilité de joindre des notes et des fichiers à un rapprochement bancaire. Je ne sais pas dans quelle mesure nos utilisateurs utiliseraient réellement ces fonctionnalités (ce n'étaient pas des besoins essentiels que nous avons trouvés dans les interviews précédentes), et je ne veux pas augmenter le temps de développement et encombrer l'écran avec ces bonus si il n'y a pas de grande valeur en eux pour nos utilisateurs.
Je prévois d'utiliser un outil d'enquête à distance tel que Vérifier pour étudier cela. Je pourrais poser la question de deux manières différentes:
- Dans quelle mesure seriez-vous susceptible d'utiliser [fonctionnalité] sur une échelle de 1 à 10?
- Dans quelle mesure seriez-vous susceptible de recommander [fonctionnalité] à un collègue sur une échelle de 1 à 10?
- Auriez-vous une utilisation de [fonctionnalité] dans votre processus habituel (oui ou non)?
Quelle est la meilleure façon de poser la question et d'interpréter les résultats afin d'obtenir une évaluation précise de la large utilisation de ces fonctionnalités bonus? Je ne veux pas biaiser les résultats parce que les répondants sont d'accord.
Cela revient en fait beaucoup dans ma propre pratique, principalement parce que la parité des fonctionnalités est souvent très appréciée par les parties prenantes internes. Si vous avez déjà défini les flux de travail des entretiens et que cela ne s'est pas produit, vous devez probablement faire deux choses: 1) assurez-vous que les fonctionnalités sont/ne sont pas nécessaires et 2) annulez l'appel pour la fonctionnalité.
Pour vérifier que la fonctionnalité est/n'est pas nécessaire, testez votre conception sous quelque forme que ce soit, en basse ou haute fidélité. (Cela n'a pas besoin d'être beaucoup de gens, 7-10 devrait le faire.) L'objectif principal est de tester les objectifs et les tâches que vous avez déjà définis et de vous assurer que vos conceptions les abordent correctement en premier. Ensuite, explorez les utilisateurs pour de nouvelles fonctionnalités en posant des questions comme:
- Que pouvez-vous pas faire ici?
- Comment cela rendrait-il votre travail plus difficile?
- Qu'est-ce qui manque à cela?
Je propose ce type de questionnement (questions ouvertes) pour susciter une réponse négative car les utilisateurs sont notoirement trompeurs, bien que inconsciemment, lorsqu'ils répondent à des questions d'auto-évaluation comme "qui utiliserait ..." et "recommanderiez-vous ..." (fermé des questions). Voici un bref résumé des questions ouvertes et fermées:
Les questions ouvertes sollicitent des informations supplémentaires de la part du demandeur .
Avantages : développer la confiance, perçue comme moins menaçante, permettre une réponse libre ou libre, peut être plus utile avec des utilisateurs articulés.
Inconvénients : peut prendre beaucoup de temps, peut entraîner des informations inutiles et peut nécessiter plus d'efforts de la part de l'utilisateur.
Les questions fermées sont les questions auxquelles il est possible de répondre de manière définitive par "oui" ou "non". [ou à partir d'un ensemble fini d'options]
Avantages : Rapides et nécessitent peu d'investissement en temps, juste la réponse.
Inconvénients : Les réponses incomplètes, nécessitent plus de temps avec des utilisateurs inarticulés, peuvent être à la tête et donc irritantes ou même menaçantes pour l'utilisateur, peuvent entraîner des hypothèses/conclusions trompeuses sur le besoin d'information de l'utilisateur et décourage la divulgation.
http://polaris.gseis.ucla.edu/jrichardson/dis220/openclosed.htm
Espérons que le besoin (ou l'absence de besoin) de cette fonctionnalité sera découvert lors de ce type de questionnement.
L'interdiction de l'appel pour la fonctionnalité peut être plus difficile, mais vous pouvez commencer à quelques endroits:
- réaffirmez avec vos recherches que cette fonction n'est jamais apparue.
- consultez l'analyse de la version précédente pour voir le% de personnes qui ont utilisé la fonctionnalité.
- réaffirmez votre mvp (peut-être que si cette fonctionnalité est vraiment nécessaire, elle peut être effectuée dans une itération ultérieure).
Pour tester vos hypothèses, je considérerais un prototype MVP (produit minimum viable) au lieu d'une enquête.
Par exemple, au lieu d'implémenter l'intégralité de la fonction de pièce jointe de rapprochement bancaire, vous pouvez avoir un lien ou un bouton indiquant "Joindre des notes ou des fichiers". Ensuite, vous pouvez mesurer le nombre de clics sur le lien. Cela vous aidera à déterminer s'il s'agit d'une fonctionnalité que les gens utiliseraient.
Le problème avec les MVP prototypes est que l'utilisateur se retrouve alors avec un besoin non satisfait. Une fois que l'utilisateur a cliqué sur le lien, vous devez lui expliquer qu'il vient de voter pour cette fonctionnalité dans une prochaine version et qu'il peut vous envoyer un e-mail s'il a d'autres commentaires.
Avant de créer votre prototype MVP, je documenterais vos hypothèses. Vous devez expliquer pourquoi vous pensez que la fonctionnalité doit exister et la recherche à l'appui.
Je serais d'accord avec la réponse de @ Andrew et construirais un prototype d'une sorte et testerais vos hypothèses avec cela.
Il ne doit même pas nécessairement être quelque chose dans le produit principal - un prototype en papier ou une autre maquette devrait suffire pour vous permettre de valider que la fonctionnalité répond à un besoin réel du client.
J'ajouterais que le style de questions que vous avez proposé ...
Dans quelle mesure seriez-vous susceptible d'utiliser [fonctionnalité] sur une échelle de 1 à 10?
Dans quelle mesure seriez-vous susceptible de recommander [fonctionnalité] à un collègue sur une échelle de 1 à 10?
Auriez-vous une utilisation de [fonctionnalité] dans votre processus habituel (oui ou non)?
... sont, selon mon expérience, vraiment inefficaces.
Tout d'abord, sans le contexte de la fonctionnalité et du workflow réels, le client doit imaginer son contexte réel. Deuxièmement, vous avez déjà posé une question directrice en discutant et en décrivant la fonctionnalité. Ces deux éléments combinés ont tendance à produire des réponses peu liées à la façon dont la fonctionnalité est réellement utilisée.
Le prototypage - et les interviews dans le contexte de travail - sont beaucoup plus efficaces
Ayez une conversation avec un couple pour commencer, puis faites une enquête. Quoi qu'il en soit, découvrez comment ils gèrent les notes et les fichiers (pièces jointes):
- fichiers papier
- disque dur local et/ou réseau
- clé USB
- Service tiers comme Dropbox ou Evernote
Sont-ils chargés de créer des structures de dossiers complexes pour "faire correspondre" les informations de votre application?
Préfèrent-ils la flexibilité et les capacités de partage de certaines des applications tierces et préféreraient-elles que votre application fonctionne avec elles?
Le maillage avec d'autres services peut également être un moyen de promouvoir votre produit. Discutez avec vos utilisateurs. Répondre "oui" aux nouvelles fonctionnalités ne coûte rien et je ne pense pas que vous comprendrez mieux comment votre application s'intègre à tous leurs besoins. En fin de compte, vous voulez qu'ils disent: "Vous savez ce qui pourrait vraiment aider?"
Vous dites que ces fonctionnalités proviennent de "notre équipe, en fonction des autres besoins des utilisateurs qu'ils ont vus dans le passé". Cela a du sens, trouver des solutions aux problèmes dont quelqu'un a été témoin, plutôt que des solutions aux problèmes que quelqu'un imagine. Ou, pire encore, des fonctionnalités qui semblent cool.
Si c'était moi, je vérifierais que ces problèmes existent en observant les utilisateurs lorsqu'ils effectuent leurs tâches de réconciliation. Cependant, ils le font - avec votre outil, avec l'outil d'un concurrent, avec un stylo et du papier, ... ajoutent-ils des notes au fur et à mesure? Pendant que vous observez, vous pouvez demander des détails sur ce qu'ils font au fur et à mesure et se poser des questions immédiatement après. "Quelle a été la partie la plus difficile?" "Existe-t-il un moyen de faciliter cette étape?"
C'est ce que je ferais car je fais plus confiance à l'observation qu'aux sondages et interviews.