Histoires d'utilisateurs - comment les valider avec des recherches réelles?
Mon PM a une liste d'histoires d'utilisateurs. Nous voulons savoir si elles sont "vraies" - en gros, si ces histoires d'utilisateurs ont des preuves pour les soutenir, ou non.
Nous extrayons déjà des données d'utilisation. Je vais également parler à notre équipe de support client pour glaner des tickets/notes de support client à partir des appels de support client (pour voir si nos clients ont, en fait, exprimé un besoin pour notre nouvelle fonctionnalité).
Avez-vous utilisé des entretiens pour valider (ou réfuter) les témoignages d'utilisateurs? Si oui, comment avez-vous mené une bonne interview sans poser de questions directrices? (ou pire, le très inutile "Utiliseriez-vous cette fonctionnalité?")
D'autres méthodes qualitatives pour rechercher des user stories?
Des idées?
Il est très courant pour les chefs de projet et les propriétaires de produits d'avoir à l'avance une liste de User Stories, qu'ils utilisent pour déterminer la direction du développement de produits. Ces histoires préconçues sont hypothèses .
Votre tâche consiste à valider ces hypothèses.
Bon à savoir que dans un premier temps, vous avez une équipe de support qui peut vous fournir des données de retour client. Mais vous devez être un peu prudent parce que -
- Les commentaires des clients ne sont pas nécessairement des commentaires liés à l'expérience utilisateur, il vous faudra donc beaucoup de temps pour parcourir les données pour trouver les résultats pertinents.
- Les commentaires des clients peuvent être historiques et obsolètes - et après un certain temps, les données peuvent ne plus être pertinentes car les besoins des utilisateurs peuvent changer avec le temps
Cependant, vous trouverez peut-être plus utile et plus fructueux de mener vos propres recherches sur les utilisateurs. Il existe certaines méthodes que vous pourriez utiliser pour mener vos recherches, mais cela dépend du temps/budget dont vous disposez -
Entretiens non dirigés - C'est bien lorsque vous ne voulez pas leur poser directement des questions spécifiques à des fonctionnalités. Cela vous sera utile car vous souhaitez tester des hypothèses. Par exemple, au lieu de demander "utiliseriez-vous cette fonctionnalité?", Vous pouvez demander "Pouvez-vous parler un peu de la façon dont vous passez votre journée?" . Votre objectif principal est de comprendre les comportements, les habitudes, les attentes, l'environnement, les antécédents culturels, etc. de l'utilisateur, ce qui aide vraiment à comprendre les besoins de l'utilisateur. Expliquez clairement au participant que l'entretien ne vise pas à tester ses connaissances mais à vous aider à améliorer le produit.
Sondage largement distribué - Cela vous aide lorsque vous avez moins de temps, une très grande base d'utilisateurs et que vous devez valider vos hypothèses rapidement. Vous pouvez mélanger les questions pour qu'elles soient spécifiques et non spécifiques et obtenir un aperçu rapide de nombreux utilisateurs. Cependant, vous pouvez manquer la touche humaine que les entretiens ont à offrir, et il est également difficile de faire un suivi si vous avez besoin de mieux comprendre les besoins de vos utilisateurs.
Dans un environnement contraint par le temps, vous vous retrouverez à faire un peu des deux, et c'est très bien aussi, tant que vous avez suffisamment d'informations de vos utilisateurs.
Cette approche semble être un peu en arrière et est sans aucun doute dirigée vers vous par votre PM. En règle générale, vous souhaitez utiliser la recherche pour découvrir les user stories existantes. Dans ce cas, je passerais en revue la recherche et trouverais quelles histoires d'utilisateurs il y a et leur fréquence. Vous aurez alors une liste assez concise et utile. Vous pouvez ensuite recouper la liste des histoires réelles avec ce que votre PM suggère.
Ce serait une meilleure approche que si vous deviez simplement analyser la recherche pour voir si elle existe. En effet, si vous découvrez que les user stories de votre PM n'existent pas dans la réalité, alors vous avez une liste de celles qui existent réellement. S'il y avait bien des correspondances et parce que vous auriez également marqué la fréquence, vous pourriez même dire à vos PM quelles histoires sont plus courantes parmi vos utilisateurs en plus de les informer de celles qui ne l'étaient pas conscient de.
J'ai trouvé ce modèle très efficace:
- Les équipes de direction définissent les buts et objectifs de l'entreprise. Ils sont utilisés pour formuler une stratégie d'entreprise et de produit
- Le PM aide à définir cette stratégie en identifiant et en validant les problèmes à résoudre.
- UI/UX identifie et valide les solutions à ces problèmes, du côté des utilisateurs
- DEV identifie et valide les solutions à ces problèmes, d'un point de vue technique
Si votre PM vous donne des exigences pour résoudre des problèmes qui n'existent pas réellement, vous verrez des signes. Lors des tests utilisateur, les utilisateurs diront des choses comme "ce n'est pas ce dont j'ai besoin" ou "c'est cool, mais ..."
Pour éviter de concevoir pour ces "faux" problèmes, je me concentre d'abord sur:
- Définition des "travaux à réaliser"
- Création d'une "carte d'empathie utilisateur"
Si les tâches que les utilisateurs tentent réellement d'accomplir ne correspondent pas aux problèmes que je résous, je demande la clarté au PM.
Enfin, si votre PM vous donne des solutions aux problèmes, alors il peut être hors de sa portée. Résoudre ce problème peut être un défi, mais cela peut être fait.